作者 | Herve Khg
編譯 | 如煙
Kubernetes 作為雲計算領域的絕對主角，當仁不讓地坐上了容器技術領域的「頭把交椅」。它的精髓在於，你只要在 YAML 里描述清楚應用的樣子，剩下的一切都可以交給它來完成。
但這一切的前提是 K8s 集群的高效管理。
說起我管理 Kubernetes 集群這三年，真可謂是一波三折、跌宕起伏。在這段充滿挑戰的經歷中，我對這項技術有了更加深刻的了解，總結出十條我認為最有價值的經驗教訓，涵蓋的內容包括管理底層基礎設施、優化部署流程、確保集群的可擴展性和安全性的最佳實踐。
無論你是剛入門 Kubernetes 的新手，還是經驗豐富的專家，這些經驗都可以為管理 Kubernetes 集群提供更豐富的視角。
花費大量時間管理底層基礎設施，或許可以讓你成為kube-api、kube-apiserver、kubelet、etcd、kube-proxy 等領域的專家，但這對於業務而言可能是事倍功半。
想要更高效地管理 Kubernetes 集群，只要將這個任務交給合適的雲服務廠商就行。
不要在控制台上進行任何集群操作，特別是不要抱著「在操作台修復問題後，我馬上就更新代碼」的僥倖心理。
雖然Helm Chart 提供了一種更加簡單的方式來打包和分發 Kubernetes 應用，不需要為了編寫 YAML 絞盡腦汁。但也要注意，還是要理解 values.yaml 文件中的每個變量並避免使用默認值。
不要讓 Kubernetes 適應你的應用，而是要讓應用適應 Kubernetes。所以你需要重新調整舊的應用程式，確保能夠與雲兼容。如果無法重新編碼應用程式，也可以繼續使用舊的虛擬機。
非必要不安裝服務網格。那如何判斷是否需要安裝服務網格呢？可以問自己兩個問題：
一是集群中的應用程式可以相互通信嗎？
二是集群中的應用程式之間的交換是否需要被保護？
如果這兩個問題的答案都是肯定的，那麼就需要安裝服務網格。
Kubernetes 提供了大量的輔助工具，可以幫助你更好地管理集群，包括 argocd, lens, k9s, keda, krew, kubectx, kubens, kail等。但不要依賴太多工具，合適的 kubectl 就能滿足 90%的需求。
以我的經驗來說，一般只選擇 kubectx、kubens、k9s 這幾種工具，這樣管理集群的效率更高。
這樣做可以防止因某些 pod 過於貪婪致使編碼或配置不當的應用程式吞噬所有集群資源，最終導致應用程式一個接一個關閉的風險。這也是對 Helm Chart 保持警惕並始終檢查完美包裝背後的清單原始碼的原因之一。
如果確實難以實現，那麼最好安裝在 NAS上而不是磁碟上。否則你會發現部署中的某些 pod 無權訪問持久資源。
因為硬碟只能掛載在一個節點上，所以如果你的 pod 分布在多個節點上，同一節點上的 pod 會看到相同的數據，而其他節點上的 pod 則看不到數據。使用類似 EFS 這樣的 NAS 類型安裝，就能避免這個問題。
如果你想停止像以前那樣工作，並受益於Kubernetes根據需求自動管理資源利用率的能力，就需要在所有應用程式項目上配置HPA（水平 pod 自動縮放器）。
每四個月就應該升級一次集群版本，一年下來大概要升級三次。有些升級更新是透明的，但通常也會帶來一些影響。
為了做好更加充分的更新準備，我覺得你需要重新回顧一下發行說明並多參考一下其他專家的經驗。
本文主要分析了 K8s 集群管理必須要考慮的十大要點，主要包括底層基礎設施的部署和管理、Helm Chart 的使用、服務網格的安裝、Kubernetes 工具的選擇、 定義 pod 的資源限制等。但在實際工作中，往往可能需要同時管理多個集群，情況也更加複雜。所以有些要點在實際操作過程中是可以忽略的，但還有些「坑」是需要自己格外注意的。