是什么使kubernetes节点不健康?

时间:2018-09-13 02:23:09

标签: kubernetes google-cloud-platform google-kubernetes-engine

在过去1个月中,我们的GKE集群经历了4个AUTO_REPAIR_NODES事件(由命令gcloud container operations list透露)。节点自动修复的结果是重新创建该节点并附加了新的外部IP,并且第三方服务未将其列入白名单的新外部IP最终导致在该新节点上运行的服务失败。

我注意到我们在Kubernetes集群中启用了“ 自动节点修复”,并很想禁用它,但是在我这样做之前,我需要了解更多情况。

我的问题是:

  1. 首先导致节点运行不正常的一些常见原因是什么?我知道这篇文章https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair#node_repair_process说:“节点在给定的时间阈值内连续检查时报告 NotReady 状态”将触发自动修复。但是什么可能导致节点变为未就绪
  2. 我也知道这篇文章https://kubernetes.io/docs/concepts/architecture/nodes/#node-status,其中提到了节点状态的完整列表:{OutOfDisk,Ready,MemoryPressure,PIDPressure,DiskPressure,NetworkUnavailable,ConfigOK}。我想知道,如果某个节点的{OutOfDisk,MemoryPressure,PIDPressure,DiskPressure,NetworkUnavailable}中的任何一个变为真,该节点是否变为NotReady?
  3. 在群集中禁用“自动节点修复”后,我会得到什么负面影响? 我基本上想知道我们是否会比自动修复的节点和新加入但未列入白名单的IP更糟糕。一旦禁用了“自动节点修复”,那么对于在已经自动修复的不健康节点上运行的Pod,Kubernetes会在其他节点上创建新Pod吗?

1 个答案:

答案 0 :(得分:1)

这里的困惑在于,运行kubectl get nodes时会显示kup-apiserver报告的“就绪”和“未就绪”状态。但是这些是独立的,并且从文档中还不清楚,它们与所描述的here的kubelet状态有何关系 您还可以在运行kubectl describe nodes

时查看kubelet状态(在事件中)

要回答部分问题:

  1. 由kube-apiserver报告

    • 小腿向下
    • 泊坞窗或容器或crio down(取决于您使用的垫片)
    • 小方状态-不清楚。
  2. 对于这些,kubelet将开始逐出或不排定Pod(准备就绪(https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/)除外。从文档中还不清楚如何从kubeapi服务器中报告这些消息。

    • 您可能没有使用群集上的节点,而需要为此付费。
    • 是的,在某些准备就绪探针失败(可配置)之后,k8会重新安排Pod的时间。如果kubelet处于关闭状态,或者节点处于关闭状态,则k8s会认为吊舱处于关闭状态。
    • 假设您的节点出现故障,那么最终的容量可能会比将工作负载调度到k8所需要的容量要小得多。

希望有帮助!