在過去 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} 中的任何一個變成 true，那該節點是否會變成 NotReady？
- 禁用叢集中的「自動節點修復」後會產生什麼負面後果？我基本上想知道我們是否會遇到比自動修復節點和新連接的未列入白名單的 IP 更糟糕的情況。一旦停用“自動節點修復”，那麼對於在不健康節點上運行且已自動修復的 Pod，Kubernetes 是否會在其他節點上建立新的 Pod？
答案1
主節點本質上是對節點執行健康檢查。如果節點無法回應，或節點聲明自己未就緒，則會透過節點自動修復進行修復。 GKE 節點上還有一個節點問題偵測器，可以偵測作業系統上的問題。
任何提到的情況都可能導致節點進入“NotReady”狀態。還有一些其他可能的因素，例如作業系統層級的重複錯誤。
關閉節點自動修復可能會導致節點進入“未就緒”狀態並保持這種狀態。儘管在許多情況下，節點會嘗試透過終止 pod 或進程來解決問題，但節點有可能陷入 NotReady
由於白名單要求，我建議更改您的設置，而不是禁用節點自動修復。相反，您可以為所有出站 GKE 流量設定 NAT 網關;您可以為 NAT 指派靜態 IP，只需擔心將該 IP 列入白名單即可。您不必再擔心節點更改 IP 了。