☰

Kubernetes 更新导致 Pod 卡在终止状态

tag-icon • tag-icon amazon-web-services docker deployment kubernetes
Kubernetes 更新导致 Pod 卡在终止状态


我在 Kubernetes 部署方面遇到了问题。这可能是一个低质量的问题，对此我深感抱歉：我是服务器管理的新手，无法联系到最初设置服务器的人，所以我遇到了困难。
我的配置（在测试环境中）包括一个主节点和两个普通节点，每个节点托管一个 pod 的副本（总共两个 pod），其中包含一个运行 wildfly 服务器的 docker 映像。
我正在摆弄测试环境，因为我们曾经遇到过一个问题：有时在部署后（随机几分钟后或几分钟后）pod 会失败（活动探测超时）并进入 CrashLoopBackOff。我在代码中添加了一行，每次调用活动探测时都记录一条信息消息，以查看它是否被调用，然后我重新部署（部署配置不变）。由于问题随机出现，我花了一下午的时间每隔一小时左右重新部署一次（不做任何更改），并监控日志。但毫无进展。

那么，这里是出错的部分：
第 n 次部署后，我开始看到有关 FailedScheduling 的事件。查看 pod 状态，我可以看到旧副本集的两个 pod 中的一个卡在 Terminating 状态，而应该取代它的 pod 卡在 Pending 状态。我可以通过调用 来解决问题kubectl delete pod --force --grace-period=0 [pod name]，但每次部署时都会再次发生这种情况，所以当然这不是理想的情况。我还没有尝试在生产环境中部署。
以下是日志：
Pod 状态：https://pastebin.com/MHuWV2dM
事件：https://pastebin.com/8hvpg9n5
描述 Pod：https://pastebin.com/QFmkUQB3
提前感谢您提供的任何帮助。

答案1

这是由于有限的 CPU 资源和活性探测配置组合造成的。

由于 CPU 不足，Pod 部署失败，并且卡在待处理状态：

Events:
  Type     Reason                 Age                    From                                                  Message
  ----     ------                 ----                   ----                                                  -------
  Warning  FailedScheduling       10m                    default-scheduler                                     0/3 nodes are available: 1 PodToleratesNodeTaints, 2 Insufficient cpu.

活性探测：

Liveness:  http-get http://:8080/igoodi-rest/api/health delay=45s timeout=1s period=10s #success=1 #failure=6

它设置为在部署后 45 秒内捕获 http-get，超时时间仅为 1 秒。您的 pod 几乎立即就会失败，并最终被终止。

Pod 1：

Events:
  Type     Reason                 Age                    From                                                 Message
  ----     ------                 ----                   ----                                                 -------
...
  Normal   Created                10m                    kubelet, ip-172-20-46-26.eu-west-1.compute.internal  Created container
  Normal   Started                10m                    kubelet, ip-172-20-46-26.eu-west-1.compute.internal  Started container
  Warning  Unhealthy              9m11s (x2 over 9m21s)  kubelet, ip-172-20-46-26.eu-west-1.compute.internal  Liveness probe failed: Get http://100.96.2.247:8080/igoodi-rest/api/health: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

Pod 2：

Events:
  Type     Reason                 Age                    From                                                  Message
  ----     ------                 ----                   ----                                                  -------
...
  Normal   Created                10m                    kubelet, ip-172-20-32-139.eu-west-1.compute.internal  Created container
  Normal   Started                10m                    kubelet, ip-172-20-32-139.eu-west-1.compute.internal  Started container
  Warning  Unhealthy              9m14s (x3 over 9m34s)  kubelet, ip-172-20-32-139.eu-west-1.compute.internal  Liveness probe failed: Get http://100.96.1.253:8080/igoodi-rest/api/health: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

1. 确保活动性探测健康检查的 URL 正确。使用来自节点的 curl 查看是否可以访问。某些应用程序健康检查 URL 后缀有时是“healthz”而不是“health”。如果健康检查在正确的 URL 上仍然超时，请增加 1 秒的超时时间。

2. 确保可用资源充足。运行kubectl top nodes后查看资源使用情况。

3.检查kubelet日志。如何查看 kubelet 日志或者Amazon EKS 案例。

4. 研究 Kubernetes 终止生命周期，这可能会影响 Pod 终止所需的时间。阅读本指南。

更新：

根据kubernetes 文档

手动强制删除应谨慎进行，因为它可能会违反 StatefulSet 固有的最多一个语义。StatefulSet 可用于运行需要稳定网络身份和稳定存储的分布式和集群应用程序。这些应用程序的配置通常依赖于具有固定身份的固定数量成员的集合。拥有多个具有相同身份的成员可能会带来灾难性的后果，并可能导致数据丢失（例如，基于仲裁的系统中出现脑裂情况）。

一个或多个节点可能受此影响，需要重新启动。正在运行 kubectl delete pod --force --grace-period=0 [pod name]可能是造成这种情况的原因。

相关内容