原文連結：https://zhuanlan.zhihu.com/p/677522936
背景
在過去的三年裏，我穿越了管理Kubernetes集群的時而波瀾起伏的領域。這段充滿挑戰和發現的旅程讓我深刻理解了這一尖端的技術，以及眾多的其他方面。在這篇文章中，我想與您分享我作為Kubernetes集群管理員所學到的十個最有價值的教訓。
這些教訓涵蓋了各種主題，從管理底層基礎設施到最佳化部署流程，包括確保集群可延伸性和安全性的最佳實踐。無論您是初次接觸Kubernetes的新手還是經驗豐富的專家，這些建議都將為您提供如何有效管理Kubernetes集群的豐富視角。
讓我們一起深入探討這些教訓，這是三年經驗、成功和挑戰的結晶。
教訓1：使用雲裏的Kubernetes
除非有極端的約束，否則自己不要去管理Kubernetes底層基礎設施。您會花費時間偵錯那些對您的業務毫無價值的問題。成為kube-api、kube-apiserver、kubelet、etcd、kube-proxy等方面的專家是很棒的，但每天都要自己維護這些並不會創造任何業務價值。您無需成為這些概念的專家就能有效地管理集群。將這個低階任務委托給雲服務提供商（AWS、Azure、GCP、OVH等），他們比您做得更好。在HK-TECH，我們選擇了AWS和EKS集群（註意ECS不是Kubernetes！）。
教訓2：使用程式碼部署所有與Kubernetes相關的基礎設施
集群的任何部份都不應該在控制台上手動完成，甚至連一個簡單的標簽都不要加。特別是要避免「我先在控制台上快速修復了一下，稍後我就會更新程式碼」的思維方式。迷思：其實您永遠不會這樣做。
教訓3：避免過度使用您無法完全控制的Helm Charts
是的，它們很棒，工作迅速，您不必為編寫您自己的YAML而煩惱，除非有一天更新會導致一切都崩潰。如果您真的很懶或時間很緊，至少努力理解values.yaml檔中的每個變量，並避免使用預設值。在HK-Tech，規則是不使用Helm Chart；在最壞的情況下，我們會僅獲取樣版。
教訓4：Kubernetes不喜歡「lift and shift」。
因此，為了使用到 k8s，你需要從舊應用程式的雲遷移適配開始著手。不是讓K8s來適應您的應用程式，而是由應用程式適配 k8s。如果您沒有重新編寫應用程式的能力，也許最好還是堅持使用舊的虛擬機器執行的模式。
教訓5：Mesh還是不Mesh？
如果不需要，就不要安裝服務網格。那麽你怎麽才知道是否需要它？問自己兩個問題：我的集群中的應用程式是否相互通訊？我的集群中的應用程式之間的交換是否需要安全策略？如果兩者的答案都是肯定的，那麽安裝服務網格可能是有用的。我沒有具體的建議；通常各種 Mash 技術之間都很相似。
教訓 6：避免使用過多的工具
Kubernetes提供了大量的輔助工具，承諾為更好地管理您的集群提供山寨和奇跡：argocd、lens、k9s、keda、krew、kubectx、kubens、kail等等。避免將它們像集郵一般的收集起來，老實說：用kubectl就能滿足90%的需求。就個人而言，我僅限於使用到了kubectx、kubens和k9s，它們在集群管理上是有收益的。
教訓 7 ：必須為Pod定義資源限制（記憶體和CPU）
這將防止糟糕編碼或錯誤配置的應用程式吞噬掉您集群的所有資源，並由於一些貪婪的Pod而導致其他應用程式一個接一個地崩潰。這也是對Helm Chat保持警惕，並始終詳細檢查封裝背後的清單原始碼的原因之一。
教訓 8：考慮 無狀態
理想情況下，最好避免在Pod中儲存數據。如果由於某種原因無法避免，則最好使用NAS而不是磁盤直接掛載。否則，您可能會驚訝地發現部署中的一些Pod無法存取持久資源。是的，硬碟只能在一個節點上掛載，因此如果您的Pod分布在多個節點上，同一節點上的Pod將看到相同的數據，但其他節點上的Pod將看不到。使用像EFS這樣的NAS型別掛載，您就將能避免這個問題。
教訓 9：配置HPA（水平Pod自動縮放）
如果您既想停留在舊的工作方式中，又想從Kubernetes的強大之處中受益，那就需要根據需求自動的管理資源利用率，需要 在所有應用程式計畫上配置HPA。（Helm Chat的另一個限制，很不幸通常非常缺）。
教訓 10：不要害怕變革
平均而言，您應該計劃每年對集群進行三次版本升級，大約每四個月進行一次更新。某些更新是透明的，但通常會有帶來影響的變更。為了更好地準備這些更新，我建議閱讀、再閱讀和重新閱讀版本釋出說明，以及那些在您之前進行過版本更新的人的經驗。我建議，而且我們在HK-TECH已經實施的是：始終保持在最新版本的上一個版本（除非有安全修補程式）。
祝您愉快的Kubernetes之旅！
往期推薦
點亮，伺服器三年不宕機
