Kubernetes 集群损坏：FailedSync 和 SandboxChanged答案

【问题标题】：Kubernetes cluster is broken: FailedSync and SandboxChangedKubernetes 集群损坏：FailedSync 和 SandboxChanged
【发布时间】：2018-04-11 00:42:40
【问题描述】：

我有一个 Kubernetes 1.7.5 集群，它不知何故进入了半损坏状态。在此集群上调度新部署部分失败：1/2 个 pod 正常启动，但第二个 pod 未启动。这些事件是：

default   2017-09-28 03:57:02 -0400 EDT   2017-09-28 03:57:02 -0400 EDT   1         hello-4059723819-8s35v   Pod       spec.containers{hello}   Normal    Pulled    kubelet, k8s-agentpool1-18117938-2   Successfully pulled image "myregistry.azurecr.io/mybiz/hello"
default   2017-09-28 03:57:02 -0400 EDT   2017-09-28 03:57:02 -0400 EDT   1         hello-4059723819-8s35v   Pod       spec.containers{hello}   Normal    Created   kubelet, k8s-agentpool1-18117938-2   Created container
default   2017-09-28 03:57:03 -0400 EDT   2017-09-28 03:57:03 -0400 EDT   1         hello-4059723819-8s35v   Pod       spec.containers{hello}   Normal    Started   kubelet, k8s-agentpool1-18117938-2   Started container
default   2017-09-28 03:57:13 -0400 EDT   2017-09-28 03:57:01 -0400 EDT   2         hello-4059723819-tj043   Pod                 Warning   FailedSync   kubelet, k8s-agentpool1-18117938-3   Error syncing pod
default   2017-09-28 03:57:13 -0400 EDT   2017-09-28 03:57:02 -0400 EDT   2         hello-4059723819-tj043   Pod                 Normal    SandboxChanged   kubelet, k8s-agentpool1-18117938-3   Pod sandbox changed, it will be killed and re-created.
default   2017-09-28 03:57:24 -0400 EDT   2017-09-28 03:57:01 -0400 EDT   3         hello-4059723819-tj043   Pod                 Warning   FailedSync   kubelet, k8s-agentpool1-18117938-3   Error syncing pod
default   2017-09-28 03:57:25 -0400 EDT   2017-09-28 03:57:02 -0400 EDT   3         hello-4059723819-tj043   Pod                 Normal    SandboxChanged   kubelet, k8s-agentpool1-18117938-3   Pod sandbox changed, it will be killed and re-created.
[...]

最后两条日志消息不断重复。

故障 pod 的仪表板显示：

最终仪表板显示错误：

Error: failed to start container "hello": Error response from daemon: {"message":"cannot join network of a non running container: 7e95918c6b546714ae20f12349efcc6b4b5b9c1e84b5505cf907807efd57525c"}

此集群使用 CNI Azure 网络插件在 Azure 上运行。直到我启用--runtime-config=batch/v2alpha1=true 以使用CronJob 功能后，一切都运行良好。现在，即使删除了那个 API 级别，并重新启动了 master，问题仍然存在。

节点上的kubelet日志显示无法分配IP地址：

E0928 20:54:01.733682    1750 pod_workers.go:182] Error syncing pod 65127a94-a425-11e7-8d64-000d3af4357e ("hello-4059723819-xx16n_default(65127a94-a425-11e7-8d64-000d3af4357e)"), skipping: failed to "CreatePodSandbox" for "hello-4059723819-xx16n_default(65127a94-a425-11e7-8d64-000d3af4357e)" with CreatePodSandboxError: "CreatePodSandbox for pod \"hello-4059723819-xx16n_default(65127a94-a425-11e7-8d64-000d3af4357e)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"hello-4059723819-xx16n_default\" network: Failed to allocate address: Failed to delegate: Failed to allocate address: No available addresses"

【问题讨论】：

标签： kubernetes

【解决方案1】：

这是一个错误，Azure CNI 并不总是正确地从终止的 pod 中回收 IP 地址。看到这个问题：https://github.com/Azure/azure-container-networking/issues/76。

在启用 CronJob 功能后发生这种情况的原因是 cronjob 容器（通常）是短暂的，并且每次运行时都会分配一个 IP。如果这些 IP 没有被底层网络系统（在本例中为 CNI）回收和重用，它们很快就会用完。

【讨论】：