在过去的 1 个月中，我们的 GKE 集群经历了 4 次AUTO_REPAIR_NODES事件（由命令显示gcloud container operations list）。节点自动修复的后果是重新创建节点并附加新的外部 IP，而新的外部 IP 未被第三方服务列入白名单，最终导致在新节点上运行的服务失败。
我注意到我们有“自动节点修复“在我们的 Kubernetes 集群中启用了此功能，并且很想禁用它，但在这样做之前，我需要了解更多有关情况的信息。
我的问题是：
- 首先，导致节点不健康的常见原因有哪些？我知道这篇文章https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair#node_repair_process意思是“一个节点报告一个没有准备好超过给定时间阈值的连续检查中“状态”将触发自动修复。但什么可能导致节点变得没有准备好？
- 我也知道这篇文章https://kubernetes.io/docs/concepts/architecture/nodes/#node-status其中提到了节点状态的完整列表：{OutOfDisk、Ready、MemoryPressure、PIDPressure、DiskPressure、NetworkUnavailable、ConfigOK}。我想知道，如果某个节点的 {OutOfDisk、MemoryPressure、PIDPressure、DiskPressure、NetworkUnavailable} 中的任何一个变为真，该节点是否会变为 NotReady？
- 在集群中禁用“自动节点修复”后会产生什么负面后果？我基本上想知道我们是否会陷入比自动修复节点和新连接的未列入白名单的 IP 更糟糕的境地一旦“自动节点修复”被禁用，那么对于在不健康节点上运行且已自动修复的 pod，Kubernetes 会在其他节点上创建新的 pod 吗？
答案1
主节点本质上是对节点执行健康检查。如果节点无法响应，或者节点声明自身未就绪，则将通过节点自动修复进行修复。GKE 节点上还有一个节点问题检测器，可以检测操作系统上的问题。
上述任何一种情况都可能导致节点进入 NotReady 状态。还有一些其他可能的因素，例如在操作系统级别重复出现错误。
关闭节点自动修复可能会导致节点进入 NotReady 状态并保持这种状态。尽管在许多情况下，节点会尝试通过终止 Pod 或进程来解决问题，但节点可能会卡在 NotReady 状态
由于白名单要求，我建议你更改设置，而不是禁用节点自动修复。相反，你可以为所有出站 GKE 流量设置 NAT 网关；您可以为 NAT 分配一个静态 IP，只需担心将该 IP 列入白名单。您不必再担心节点更改 IP。