是什么让 Kubernetes 节点不健康？

Question

在过去的 1 个月中，我们的 GKE 集群上发生了 4 个 AUTO_REPAIR_NODES 事件（由命令 gcloud container operations list 显示）。 node-auto-repair 的后果是该节点被重新创建并附加一个新的外部 IP，而新的外部 IP 未被第三方服务列入白名单，最终导致在该新节点上运行的服务失败。

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

我的问题是：

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

Answer 1

这里的混淆在于当您运行 kubectl get nodes 时会显示“就绪”和“未就绪”状态，这些状态由 kube-apiserver 报告。但是这些是独立的，并且从文档中不清楚它们与here 描述的 kubelet 状态有何关系 您还可以在运行 kubectl describe nodes 时查看 kubelet 状态（在事件中）

回答部分问题：

1. 由 kube-apiserver 报告

   • Kubelet 向下
   • docker 或 containerd 或 crio down（取决于您使用的 shim）
   • kubelet 状态 - 不清楚。

2. 对于这些，kubelet 将开始驱逐或不调度除 Ready (https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/) 之外的 Pod。文档中不清楚这些是如何从 kubeapi-server 报告的。

3. • 您的集群上的节点可能未使用，您需要为使用付费。
   • 是的，k8s 会在某个就绪性探测失败后重新调度 Pod（可配置）。如果 kubelet 宕机或节点宕机，k8s 会认为 pod 宕机。
   • 假设您的节点出现故障，您最终的容量可能会少于您将工作负载安排到 k8s 所需的容量，但无论如何都无法安排它们。

希望对你有帮助！

Answer 2

不是我的答案，但这个关于 SF 的答案指向正确的方向，关于使用 NAT 网关并将该 IP 列入白名单 https://serverfault.com/a/930963/429795