标签: readinessprobe

在 Spring-Boot 2.4 中，我在执行器运行状况端点和就绪探针方面遇到了这个问题。当我的自定义关键组件之一出现故障时，/health/readiness端点会显示DOWN，/health端点也会显示 ，但详细readinessState信息/health仍会显示UP。

为什么会这样呢？不也应该readinessState说DOWN吗？

我在网上找到的许多教程似乎都没有解决这个问题。

我的假设：这readinessState与准备情况无关，并暴露了另一条信息。我希望我错了，因为这毫无意义，而且我对代码的理解似乎表明情况并非如此。

有关我的配置的更多信息：

相关摘录自application.yml

management:
  endpoints:
    web:
      base-path: /
  endpoint:
    health:
      show-details: ALWAYS
      probes:
        enabled: true
      group:
        readiness:
          include: db, myCustom, diskSpace

当我执行myCustomgo时DOWN，会出现以下结果：

GET /health

{
    "status": "DOWN",
    "components": {
        ...,  // other components
        "myCustom": {
            "status": "DOWN"
        },
        "readinessState": {
            "status": "UP"  // here UP
        } …

在下面的 yaml 语法中：

      readinessProbe:
        httpGet:
          path: /index.html
          port: 80
        initialDelaySeconds: 3
        timeoutSeconds: 3
        periodSeconds: 10
        failureThreshold: 3

就绪探针在 Pod 的初始部署期间使用。

1. 为了推出新版本的应用程序，使用滚动部署策略，是否使用就绪探针进行滚动部署？

2. path&port字段允许输入特定服务的 url 和端口号，但不能输入依赖服务。如何验证依赖服务是否也准备好？

我对 k8s 很陌生，所以如果问题没有意义或者不正确/愚蠢，我深表歉意。

我为我的 pod 定义配置了一个活性探针，它只访问运行状况 API 并检查其响应状态以测试 pod 的活性。

我的问题是，虽然我了解活性/就绪探针的目的……它们到底是什么？它们是否只是另一种类型的 Pod，它们被旋转起来并尝试通过配置的 API 与我们的 Pod 进行通信？或者它们是某种轻量级进程，在 Pod 内部运行并尝试 API 调用？

另外，探针如何与 Pod 通信？我们是否需要为 Pod 配置一个服务，以便探针能够访问 API，或者它是一个内部进程，不需要额外的配置？

我是 stackoverflow 的新手，所以如果我没有遵循提出这个问题的所有规则，请原谅。

因此，我使用这个 Helm Chart： https: //github.com/helm/charts/tree/master/stable/mysql为我们的生产环境部署 mysql。事实上，我们在生产中运行了这个设置，但它只创建 1 个 mysql pod，而我需要运行 3 个 pod。我尝试在 helm 图表的values.yaml 文件中设置replicas=3 并重新部署该图表，但它不断失败并出现一些错误，错误是：

Events:
    Type     Reason            Age                    From                  Message
    ----     ------            ----                   ----                  -------
    Warning  FailedScheduling  4m58s                  default-scheduler     pod has unbound immediate PersistentVolumeClaims (repeated 4 times)
    Normal   Scheduled         4m58s                  default-scheduler     Successfully assigned test-helm/cluster-mysql-5bcdf87779-vdb2s to innolx12896
    Normal   Pulled            4m57s                  kubelet, innolx12896  Container image "busybox:1.29.3" already present on machine
    Normal   Created           4m56s                  kubelet, innolx12896  Created container
    Normal   Started           4m56s                  kubelet, innolx12896  Started container
    Warning …

我的 MySQL Pod 中有一个 sidecar 容器，它将使用 MySQL 套接字文件来访问数据库。

我想确保 MySQL 已成功启动，因此在此 sidecar 容器启动之前已创建套接字文件。

我尝试添加一个带有存在的readiness探针，但失败了：exec.commandtest -S /var/run/mysqld/mysqld.sock

Readiness probe failed: OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "test -S /var/run/mysqld/mysqld.sock": stat test -S /var/run/mysqld/mysqld.sock: no such file or directory: unknown

当我在 sidecar 容器中打开终端会话时，我可以看到ls套接字文件，它就在那里。

所以看起来我的test -S <path>命令在探测器的上下文中没有按预期工作。

如何编写探针，以便一旦套接字文件可用，我的 sidecar 容器就会启动？

有人可以告诉我用于部署的 yaml 文件有什么问题吗？当我删除就绪探针时，我可以看到我的部署kubectl get deployments可用。但使用就绪探针后，它仍然不可用，如下所示。

NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
neg-demo-app   1         1         1            0           2m33s

下面是我的yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec: # Deployment's specification
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: …

为了简单起见，我认为最好只检查 kubernetes 中 TCP 端口的活跃度和就绪情况，因为它不需要了解运行状况检查端点（HTTP 路径），而只需要端口号。非常感谢有关仅依赖 TCP 端口进行服务运行状况检查的缺点的任何指南，请假设 Pod 不是某些其他服务的代理，并且所有业务逻辑都在 Pod 本身中。

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

我正在使用 Exec 探针添加活性探针和就绪探针。
我的配置如下：

readinessProbe:
    exec:
      command: "/usr/bin/jps -l | grep QueueProcess"
    periodSeconds: 10 
    failureThreshold: 2
    successThreshold: 2

当上面的方法不起作用时。我对此进行了修改并尝试了：

readinessProbe:
     exec:
       command: ["/usr/bin/jps", "-l", "|", "grep","QueueProcess"]
     periodSeconds: 10 
     failureThreshold: 2
     successThreshold: 2

运行时kubectl describe pod，得到以下输出：

  Normal   Created           37s                  kubelet             Created container app1
  Normal   Started           37s                  kubelet             Started container app1
  Warning  Unhealthy         6s (x3 over 26s)     kubelet             Readiness probe failed: invalid argument count
usage: jps [-help]
       jps [-q] [-mlvV] [<hostid>]

Definitions:
    <hostid>:      <hostname>[:<port>]

我尝试了另一个应用程序，我正在其中运行grpcurl来调用运行状况检查：

readinessProbe:
    exec:
      command: …

当 Kubernetes 返回 false 时会发生什么readiness-probe？超时后 Kubernetes 是否会重新启动该 pod？Kubernetes 等待准备就绪需要多长时间？