设想一个场景:有三个工作节点的Kubernetes 集群,版本为 v1.19.0。发现在 worker 1 上运行的一些 pod 被驱逐了
从上图可以看出有很多pod被驱逐了,报错信息也很清楚。由于节点上存储资源不足,导致kubelet触发驱逐过程。
方法1:启用auto-scaler
- 向集群添加工作节点,要么部署cluster-autoscaler以根据配置的条件自动扩缩容。
- 只增加worker的本地存储空间,这涉及到虚拟机的扩容,会导致worker节点暂时不可用。
方法2:保护关键Pod
在资源清单中指定资源请求和限制,配置QoS (Quality of Service)。当kubelet触发驱逐时,将至少保证这些 pod 不受影响。
这种施在一定程度上保证了一些关键Pod的可用性。如果节点出现问题时 Pod 没有被驱逐,这将需要执行更多步骤来查找故障。
运行命令 kubectl get pods 结果显示很多 pod 处于 evicted 状态。检查结果将保存在节点的kubelet日志中。查找对应日志使用 cat /var/paas/sys/log/kubernetes/kubelet.log | grep -i Evicted -C3。
检查思路
查看Pod容忍度
当Pod故障无法连接或节点无法响应时,可以使用 tolerationSeconds 配置对应时长长短
tolerations:
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
如果集群中的节点数小于50,并且故障节点数超过总节点数的55%,则暂停 Pod 驱逐。在这种情况下,Kubernetes 将尝试驱逐故障节点的工作负载(运行在kubernetes中的APP)。
下属json描述了一个健康的节点
"conditions": [
{
"type": "Ready",
"status": "True",
"reason": "KubeletReady",
"message": "kubelet is posting ready status",
"lastHearbeatTime": "2023-10-23T18:38:35Z",
"lastTransitionTime": "2023-10-23T11:41:27Z"
}
]
如果就绪条件为 Unknown 或 False 的时间超过了 pod-eviction-timeout,node controller 将对分配给该节点上的所有 Pod 执行 API-initiated 类型驱逐。
检查Pod的已分配资源
Pod会根据节点的资源使用情况被逐出。被逐出的Pod将会根据分配给Pod的节点资源进行调度。
管理驱逐”和“调度”的条件由不同的规则组成。这种结果会导致,被逐出的容器可能会被重新安排到原始节点。
因此,要合理分配资源给每个容器。
检查Pod 是否定期失败
Pod 可以被驱逐多次。即如果在 Pod 被驱逐并调度到新节点后该节点中的 Pod 也被驱逐,则该 Pod 将再次被驱逐。
如果驱逐动作是由 kube-controller-manager 触发的,则保留处于 Terminating 状态的 Pod 。在节点恢复后,Pod将被 自动销毁。如果节点已经被删除或者其他原因无法恢复,可以强制删除Pod。
如果是由 kubelet 触发的驱逐,Pod 状态将保留为 Evicted 状态。仅用于后期故障定位,可直接删除。
删除被逐出的 Pod 命令为:
kubectl get pods | grep Evicted | awk ‘{print $1}’ | xargs kubectl delete pod
Notes:
- 被Kubernetes驱逐的Pod,不会被自动重新创建 pod。如果要重新创建Pod,需要使用replicationcontroller、replicaset和 deployment 机制,这也是上述提到的Kubernetes的工作负载。
- Pod控制器是协调一组Pod始终为理想状态的控制器,所以会删除后重建,也是Kubernetes 声明式API的特点。
如何监控被驱逐的Pod
使用Prometheus
kube_pod_status_reason{reason="Evicted"} > 0
使用 ContainIQ
ContainIQ 是为Kubernetes设计的可观测性工具,其中包含Kubernetes 事件仪表板,这就包括 Pod 驱逐事件