2

我有一个部署到 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.yamlreadiness包括数据库检查，这意味着每 30 秒readiness检查一次失败。当它失败 3 次时，failurethreshold会遇到并启动新的 pod。

重启策略默认为 Always。

问题：

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

2 回答 2

1
  1. 正如您对自己的回答，根据failureThreshold. 您可以将您的更改restartPolicy为OnFailure，仅当它失败或Never您不希望重新启动集群时，它才允许您重新启动作业。您可以在此处找到状态之间的区别。请注意：

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

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

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

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

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

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

于 2021-11-30T20:20:17.893 回答
0

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

于 2021-12-01T19:54:38.877 回答