☰

为什么在被抢占后重新创建的节点上的 pod 会卡在 ContainerCreating 状态？

tag-icon • tag-icon google-cloud-platform kubernetes google-kubernetes-engine
为什么在被抢占后重新创建的节点上的 pod 会卡在 ContainerCreating 状态？

我有一个由部署创建的 pod，该部署在 Google Kubernetes Engine 集群中的可抢占节点上运行。该节点被抢占并重新创建。有几个 FailedCreatePodSandBox 事件抱怨：

网络：stat /var/lib/calico/nodename：没有此文件或目录：检查 calico/node 容器是否正在运行并已挂载 /var/lib/calico/

上述事件似乎是暂时的，直到 Calico 网络在节点上完全运行。但是，“kubectl describe” 提到的最终事件条目有所不同：

警告 FailedCreatePodSandBox 95 秒（x3 超过 101 秒）kubelet，（由类似事件组合而成）：无法创建 pod 沙盒：rpc 错误：代码 = 未知 desc = 无法为 pod“pod_name”设置沙盒容器“a1afa2a61b7b2260997f4b4719b9c315698d0016af47902923c78e4594e0dc6b”网络：NetworkPlugin cni 无法设置 pod“pod_name”网络：Pod“pod_name”无效：规范：禁止：pod 更新不得更改除、或之外的字段spec.containers[*].image（仅限spec.initContainers[*].image对现有容忍度的补充）spec.activeDeadlineSecondsspec.tolerations

最后一个事件包括 JSON 格式的 Pod 的完整规范。Pod 保持 ContainerCreating 状态数小时，因此我认为它永远无法恢复。然后我手动删除了 Pod，部署立即创建了一个新 Pod，并在同一节点上快速启动。Pod 规范中的某些内容是否需要针对重新创建的节点进行更改？

我尝试通过重置节点来模拟抢占，但在这种情况下，pod 马上就恢复了。看来，虽然两种情况下节点名称都保持不变，但重新创建被抢占​​的实例和重置实例而不重新创建实例之间肯定存在一些本质区别。

我似乎遇到了一个错误，但我不确定它是在 Kubernetes 本身中，还是 GKE 版本的 Kubernetes 中，或者它是否是 Google Cloud Platform 抢占的特定问题。显然我不是唯一遇到这个问题的人，因为https://github.com/GoogleCloudPlatform/k8s-node-termination-handler存在。我现在正在使用 k8s-node-termination-handler，它确实解决了这个问题。也许它填补了 GKE 提供的功能空白？

答案1

遇到的问题可能出在 GKE 之外，也可能出在 Kubernetes 本身。在 Kubernetes github 问题页面中，我们看到“https://github.com/kubernetes/kubernetes/issues/62666#issue-314798540“这与 Pod 删除有关，但有与您收到的错误类似的错误：

 “ spec: Forbidden: pod updates may not change fields other than `spec.containers[].image`, `spec.initContainers[].image`, `spec.activeDeadlineSeconds` or `spec.tolerations` (only additions to existing tolerations)"

如果你再次遇到类似的问题，我建议你打开此处为私人问题在这里，并提供您可能遇到的完整错误、GKE 版本等。

顺便说一句，当一个节点被抢占时，该节点会被删除并重新创建，因此重置不会产生相同的影响。

相关内容