自動化管理大規模生產級Kubernetes的七個方法
譯文【51CTO.com快譯】Kubernetes開源容器編排引擎不是一個管理平臺，也不應該被誤認為是一個管理平臺。編排的要點在于，可靠地讓自動化系統能夠便于大規模部署和管理應用程序，不需要在每個步驟都有人干預。如果你使用的面向Kubernetes的工具不支持自動化，那么你沒有真正利用編排的好處。
為此，這七個方法可以讓你自動管理生產環境的Kubernetes集群。
1.日志
任何Kubernetes生產環境都將高度依賴日志。在Kenzan，我們通常會努力將平臺日志與應用程序日志分開來。這可以通過全然不同的工具和應用程序來做到，甚至通過日志本身里面的過濾和標記來做到。與任何分布式系統一樣，日志為準確跟蹤特定的調用提供了重要的證據，即使它們針對不同的微服務，那樣就能查明根本原因。
2.自我修復
我們認為，要是沒有自我修復功能，你的系統幾乎不可能獲得很長的正常運行時間，尤其是在分布式環境中。Kubernetes可以定期監測pod和容器的健康狀況，立即采取措施解決遇到的問題。Kubernetes可直接識別的兩種對象類型是pod狀態(podstatus)和容器狀態(containerstatus)。
容器探針(livenessProbe和readinessProbe)讓你可以定義希望Kubernetes如何監測容器是否處于活動狀態且準備就緒。readiness probe(就緒探針)尤其有用，因為如果探針失效，它實際上會讓pod處于運行狀態，但并不傳送任何流量。
不過要注意，雖然每半小時重啟之類的自我修復功能很有用，但也可能會掩蓋應用程序的問題。你需要足夠強大，能夠發現出現的任何問題的監測和日志功能。
3.彈性測試
彈性測試應該是你平臺的一部分，這取決于你應用程序的要求(比如99.999%的正常運行時間)。應用程序任何級別的失效都應該可以恢復，那樣沒人會遇到任何停機時間。根據我們的經驗，如果開發團隊事先知道他們的開發工作會接受廣泛的彈性測試，才有可能開發出可靠的應用程序。
雖然你可以通過最簡單的手動方法進行一種彈性測試，比如手動關閉數據庫或隨機終結pod，但我們的經驗證明，這些方法在實現自動化后有效得多。雖然Netflix的Chaos Monkey是一種在亞馬遜網絡服務中運行的非常強大的、極其有用的彈性測試工具，但它不是為Kubernetes構建的。幸好，Kubernetes領域出現了新興的彈性測試框架，其中兩個框架是fabric8 Chaos Monkey(fabric8集成開發環境的一部分)和kube-monkey。
4.例行審計
無論你落實了多少制衡措施，你的Kubernetes生產環境都將得益于例行維護和審計。例行審計將涵蓋平常監測涵蓋不了的方面。傳統上，審計是作為手動過程進行的，而這個領域的自動化工具在迅速而顯著地改進。
5.自動擴展
對于Kubernetes來說，擴展通常意味著兩者之一：
- 擴展pod
- 擴展集群內的節點
擴展pod絕對是最常見的擴展形式。這將添加更多的服務實例，讓它們準備開始接受流量。通常，pod級別的擴展使用Heapster度量標準來執行，確定是否需要創建新實例。我們通常實際上將最小pod數量設置得很低，讓Kubernetes Horizontal Pod Autoscaler正確設置最小副本數量。我們的確始終將最小值設置成大于每個群集一個副本，以免出現單點故障情況。
擴展節點屬于比較少見的情形，但對于高度彈性的應用程序來說是一種非常有用的擴展機制。節點擴展需要底層IaaS(AWS和GCP等)來擴展，并注冊到Kubernetes集群。這個過程可以采用手動操作，不過我們不建議這么做。通常我們使用可以自動擴展單個節點的工具。節點級別的自動擴展器將執行兩個主要操作，***個是需要時添加更多節點，第二個是刪除未充分利用的節點。
6.資源配額
資源配額讓你可以限制Kubernetes平臺里面的命名空間，確保一個應用程序不會占用所有資源，不會影響其他應用程序。設置資源配額可能有點困難。根據我們的經驗，按預期負載來劃分命名空間，并使用一個比率來計算集群的百分比是最穩妥的方法。運行Heapster就可以使用kubectl top {node | pod}命令，該命令顯示當前節點或pod的資源使用情況，這有時還有助于配額。之后，使用監視和審計來確定你的分區是否正確。
7.容器資源約束
搞清楚單個容器或pod需要多少資源可以說已成了一門藝術。過去，開發團隊估計的資源比實際需要的資源多得多。我們試圖執行某種級別的負載測試，觀察故障切換是如何進行的，然后適當地分配資源。Netflix稱這個方法為“擠壓測試”(squeeze testing)。
原文標題：7 WAYS TO AUTOMATE KUBERNETES AT SCALE IN PRODUCTION，作者：Craig Martin
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
