為 Kubernetes 建置和維運的人所寫的指南

在生產環境運行 Kubernetes 的實用指南，從資源請求到 etcd 備份，以及那些在凌晨三點真正重要的頁面。

Kubernetes 教學教你如何部署 pod。沒有人教你當某個節點在凌晨三點無聲地掉出 Ready 狀態，而你的值班電話不停響起時該怎麼辦。這是關於第二部分的內容。

資源請求和限制不是選項

如果你在容器上跳過 resources.requests 和 resources.limits，排程器是在猜測，而 kubelet 在節點記憶體不足時完全不知道要先清除什麼。把請求設定為容器在正常負載下實際使用的量，而不是你希望它使用的量。把記憶體限制設定在接近請求的位置，因為 OOM-killed 的 pod 會乾淨地重啟，但 CPU 限制通常應該更寬鬆或不設定，除非你在對付吵鬧的鄰居，因為硬限制下的 CPU 節流會造成延遲尖峰，那是惡夢般難以除錯的。定期執行 kubectl top pods -n your-namespace 並與你宣告的內容進行比較。在擁有超過幾個服務的叢集中，不匹配會快速累積。

etcd 是整個叢集，要相應地對待它

Kubernetes 知道的一切都存在 etcd 中。失去它，你就失去了叢集狀態，不只是某些中繼資料。在排程上執行 etcdctl snapshot save /backup/etcd-snapshot.db，並至少在一個暫存叢集上實際測試過還原。我看過許多團隊有夜間備份，但三個月來一直是損壞的，因為沒有人驗證它們。如果你使用受管理的控制平面（EKS、GKE、AKS），你不直接管理 etcd，但你應該在需要之前（而不是在事故期間）了解你的提供商的備份和還原方案。

活躍度和就緒度探針有時需要不同意

常見的錯誤是對活躍度和就緒度探針使用相同的端點。活躍度應該回答

本文由 AI 協助撰寫，經 Michal Pilch（CISSP）審核並發佈，Korra Studio。