数据库和容器的 pod readinessprobe 问题

Question

我有一个应用程序部署到 Kubernetes。 这里是技术栈： Java 11、Spring Boot 2.3.x 或 2.5.x，使用 hikari 3.x 或 4.x

使用弹簧执行器进行健康检查。这是application.yaml中的liveness和readiness配置：

  endpoint:
    health:
      group:
        liveness:
          include: '*'
          exclude:
            - db
            - readinessState
        readiness:
          include: '*'

如果 DB 宕机了怎么办 -

1. 确保liveness 不会受到影响 - 意思是，应用程序 即使数据库中断，容器也应该继续运行。
2. readinesss 将受到影响，以确保不允许任何流量到达容器。

容器规范中的liveness 和readiness 配置：

livenessProbe:
  httpGet:
      path: actuator/health/liveness
      port: 8443
      scheme: HTTPS
  initialDelaySeconds: 30
  periodSeconds: 30
  timeoutSeconds: 5
readinessProbe:
  httpGet:
      path: actuator/health/readiness
      port: 8443
      scheme: HTTPS
  initialDelaySeconds: 30
  periodSeconds: 30
  timeoutSeconds: 20

我的应用程序已启动并正常运行了几个小时。

我做了什么：

我打倒了 DB。

问题通知：

当 DB 关闭时，90 多秒后，我看到另外 3 个 Pod 启动。描述 pod 时，我会看到如下状态和条件：

Status:       Running
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True

当我列出所有正在运行的 pod 时：

NAME                                                  READY   STATUS    RESTARTS   AGE
application-a-dev-deployment-success-5d86b4bcf4-7lsqx    0/1     Running   0          6h48m
application-a-dev-deployment-success-5d86b4bcf4-cmwd7    0/1     Running   0          49m
application-a-dev-deployment-success-5d86b4bcf4-flf7r    0/1     Running   0          48m
application-a-dev-deployment-success-5d86b4bcf4-m5nk7    0/1     Running   0          6h48m
application-a-dev-deployment-success-5d86b4bcf4-tx4rl    0/1     Running   0          49m

我的类比/发现：

每个 ReadinessProbe 配置：periodSeconds 设置为 30 秒，failurethreshold 默认为每个 k8s 文档 3 个。

每个 application.yaml readiness 包括数据库检查，这意味着每 30 秒后 readiness 检查失败。当它失败 3 次时，会遇到 failurethreshold 并启动新的 pod。

重启策略默认为 Always。

问题：

1. 为什么它会旋转新的 pod？
2. 为什么它只旋转 3 个豆荚，而不是 1 个或 2 个或 4 个或任何数量？
3. 这和restartpolicy有什么关系吗？

Answer 1

1. 正如您对自己的回答，根据failureThreshold，它在 3 次尝试后旋转了新的 pod。您可以将restartPolicy 更改为OnFailure，它只允许您在失败时重新启动作业，或者Never 如果您不想重新启动集群。您可以找到here 的状态之间的区别。请注意：

restartPolicy 适用于 Pod 中的所有容器。 restartPolicy 仅指 kubelet 在同一节点上 重新启动容器。在 Pod 中的容器退出后，kubelet 以指数回退延迟（10 秒、20 秒、40 秒……）重新启动它们，上限为 5 分钟。一旦容器执行了 10 分钟且没有任何问题，kubelet 会重置该容器的重启退避计时器。

1. 分享您的完整Deployment 文件，我想您已将replicas 号码设置为3。

2. 已在第 1 个问题的答案中回答。

还要注意这一点，如果这对你有用：

启动探测对于容器需要很长时间才能投入使用的 Pod 非常有用。您可以配置一个单独的配置来在容器启动时探测容器，而不是设置较长的活动间隔，从而允许比活动间隔允许的时间更长的时间。

如果您的容器通常在超过 initialDelaySeconds + failureThreshold × periodSeconds 的时间内启动，您应该指定一个启动探针来检查与 liveness 探针相同的端点。 periodSeconds 的默认值为 10 秒。然后，您应该将其 failureThreshold 设置得足够高以允许容器启动，而无需更改 liveness 探针的默认值。这有助于防止死锁。

Answer 2

关键在于 HPA。 准备就绪失败后 POD 的 CPU 利用率会上升，当它超过 70% 时，HPA 被触发并启动了这 3 个 pod。