以下是对这些探头的简要介绍：

Liveliness Probe用于Kubernetes了解工作量是否正常。它可以是在容器中执行的shell命令，也可以是应积极响应的简单tcp/http请求。

如果活动性检查在单元配置中指定的超时时间段后失败，Kubernetes将重新启动工作负载。
因此，如果您的工作负载正在执行耗时的进程，您可能需要为活动性探测器提供足够的时间，以确保单元不会无故重新启动。

Rediness Probe用于Kubernetes代理确定您的工作量是否已准备好使用流量。仅当Rediness Probe作出肯定响应时，流量才会发送到您的单元。因此，如果您的工作量需要更多时间处理单个请求，并且需要将其他请求转移到其他副本以便在此期间进行快速处理，则您可能需要为工作量给予稍高的Rediness间隔。

这些探测参数与副本数相结合可以确保应用程序快速健康地运行。了解每个探测所覆盖的区域以及可以调整它们的参数非常重要。
下面是一些这样写的：
https://blog.colinbreck.com/kubernetes-liveness-and-readiness-probes-how-to-avoid-shooting-yourself-in-the-foot/
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

假设您的问题是因为正在处理的工作线程正在使用队列消息，它不公开任何端口以进行检查。
在这种情况下，您可以定义livenessProbe和readinessProbe自定义命令，下面是文档中的示例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

此外，请记住您的进程处于活动状态并准备好调整initialDelaySeconds和periodSeconds的时间，以便在完全加载之前不杀死Pod。