自動化管理大規模生產級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】