Kubernetes Pod被驱逐故障排除过程

Kubernetes

全面的为您讲解Kubernetes的教程内容，请看下面详细的介绍。

设想一个场景：有三个工作节点的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 将再次被驱逐。