文章分析：《🚀 15 Kubernetes Traps Every DevOps Engineer Must Survive》

這篇文章以快問快答的形式，列出了 15 個在 Kubernetes 中常見但容易誤解的「陷阱」問題。這些問題涵蓋了 Pod 生命週期、儲存、網路、調度等多個方面，旨在揭示即使是經驗豐富的工程師也可能存在的知識盲區。

15 個陷阱問題的核心知識點總結

  1. initContainer 失敗 + restartPolicy: Never：Pod 狀態會變為 Failed。因為 initContainer 必須成功，主容器才能啟動。
  2. 刪除 StatefulSet 的 replica-1：K8s 只會重建 replica-1，其他副本的名稱（replica-2, replica-3）保持不變，維持了其身份的穩定性。
  3. DaemonSet 與 NoSchedule Taint：預設情況下，DaemonSet Pod 不會被調度到帶有 NoSchedule 污點的主節點上，除非該 DaemonSet 明確配置了對應的「容忍 (toleration)」。
  4. 在滾動更新中途更新 Deployment 鏡像：K8s 會取消當前的滾動更新，並立即以新的鏡像版本啟動一個全新的滾動更新。
  5. 節點 NotReady 後 Pod 的驅逐時間：預設是 300 秒（5 分鐘）。這個時間可以透過 --pod-eviction-timeout 參數進行全域配置。
  6. 同一 Pod 內多個容器共享端口：不可能。在一個 Pod 的網路命名空間內，端口是唯一的。
  7. ReadWriteOnce (RWO) 的 PVC：可以被同一節點上的多個 Pod 共享掛載。但不能被不同節點上的 Pod 同時掛載。
  8. HPA 的自訂指標伺服器宕機：自動擴縮容會停止工作。HPA 無法獲取指標，因此不會對 Pod 數量做任何調整。
  9. 對 CrashLoopBackOff 狀態的 Pod 進行端口轉發：不會成功。port-forward 需要一個正在運行的 Pod 來建立連接。
  10. 刪除正在被 Pod 使用的 ServiceAccount：已經掛載到 Pod 中的 Token 會繼續有效，直到它們過期（通常為 1 小時）。
  11. 過於嚴格的反親和性規則：是的，可能會導致調度死鎖，使 Pod 永遠處於 Pending 狀態。
  12. Job (並行度: 3) 中一個 Pod 失敗 (restartPolicy: Never)：Job 控制器會創建一個新的 Pod 來替代失敗的 Pod，以確保最終有 3 個 Pod 成功完成任務。
  13. 修改運行中 Pod 的資源請求：不可以直接修改。資源請求（requests）和限制（limits）是不可變的，必須刪除並重建 Pod。
  14. NetworkPolicy 中沒有 egress 規則：預設情況下，出站流量是被允許的。網路策略採用「預設允許，明確拒絕」的原則。
  15. PV 損壞對多個 PVC 的影響：是的，可能會發生級聯故障。如果多個 PVC 綁定到同一個損壞的 PV，所有使用這些 PVC 的 Pod 都會遇到錯誤。

整篇文章重點結論

這篇文章是一份高效的 Kubernetes 「自檢清單」，透過 15 個精心設計的問答，系統性地揭示了 Kubernetes 中容易被忽視或誤解的關鍵機制。其核心價值在於，它不僅僅是知識點的羅列，而是將這些知識點置於實際的、可能出錯的場景中，迫使讀者思考邊界條件和預設行為。

文章的主要結論和 takeaways 可以歸納為：

  1. 魔鬼在細節中：對 K8s 的掌握程度，體現在對其各種資源的生命週期、重試邏輯和預設行為的精確理解上。
  2. 預設行為很重要：了解 K8s 的預設設置（如驅逐超時、網路策略的預設規則）是避免生產事故的關鍵。
  3. 層級化控制：理解不同控制器（如 Job 控制器）如何管理其下屬資源（如 Pod）的行為至關重要。
  4. 不可變性原則：深入理解哪些資源屬性（如 Pod 的資源請求）是創建後不可變的，這對設計更新和發布策略至關重要。

總而言之，這份清單可以幫助 DevOps 工程師快速識別自己的知識弱點，加深對核心概念的理解，從而更好地駕馭這個複雜的系統。