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