7種方法 實現在生產中自動化Kubernetes集群

作者 | Craig Martin

原文 | https://thenewstack.io/7-ways-automate-kubernetes-scale-production/

開源容器編排引擎Kubernetes不是一個管理平台，也不該被認為是一個管理平台。整個編排的要點就是確實的自動化系統來幫助部署和大規模應用的管理，不需要在每一個地方和每一步中介入人力。如果你使用的工具和Kubernetes不支持自動化，那麼你就沒有真正利用編排的優勢。

為了實現這個目的，以下7種方法能夠讓你在生產中自動化Kubernetes集群。

01

日誌

Logging

任何Kubernetes生產環境都嚴重依賴log。在Kenzan，我們特地嘗試將平台日誌從應用日誌中分離。實現這個可能需要非常不同的工具和應用，或者可以通過在日誌中進行過濾和標記來完成。與任何分散式系統一樣，日誌為精準追蹤特定的調用提供非常重要的依據，即使它們在不同的微服務上，也能夠識別出根本原因。

02

自我修復

Self-Healing

我們相信，你的系統幾乎不可能在沒有自我修復能力的情況下實現高的正常運行時間率，特別是在一個分散式環境中。Kubernetes可以定期的監控pod和容器的健康，並且立即採取行動解決遇到的問題。Kubernetes本地識別的兩種對象類型是podstatus和containerstatus。

容器探查（活性調查和準備情況調查）讓你定義你希望Kubernetes如何監視容器是否存在和準備就緒。準備情況調查格外有用，因為它實際上會離開pods，但如果探測失敗，就不會為它們提供流量服務。

但是需要注意的是，當然自我修復功能是很好的（例如每半小時重啟），它們也會掩蓋應用的問題。需要足夠強大的監控和日誌功能來發現任何可能存在問題。

03

彈性測試

Resilience Testing

根據應用測試的需要，彈性測試應該成為平台的一部分。在應用的任何層級失敗都是可恢復的，因此不會有任何停機時間。在我們的經驗中，只有在開發團隊預先知道他們的工作將通過廣泛的彈性測試進行時，防彈應用才可行。

雖然能通過最簡單的人工方法來進行一類彈性測試，例如人工關閉資料庫或任意刪除pods，我們的經驗證明了這些方法在被自動化時更有效。雖然Netflix的Chaos Monkey是個非常強大、有用的彈性測試工具，在Amazon Web Service中運行，但它不是為了Kubernetes構建的。慶幸的是，在Kubernetes領域中有新興的彈性測試框架，其中兩個是fabric8 Chaos Monkey（fabric8集成開發環境的一部分）和kube-monkey。

04

常規審計

Routine Auditing

無論你放了多少檢查和平衡，Kubernetes生產環境將從常規維護和審計中受益。這些審計將覆蓋題目而正常的監控則不會覆蓋。傳統上，審計作為人工流程來進行，但是這個空間中的自動化工具是快速和顯著改進的。

05

自動縮放

Autoscaling

對於Kubernetes，縮放通常意味著以下兩件事之一：

縮放pods

在集群中縮放節點

縮放pods是最常見的擴展形式之一。這將增加更多的服務實例，並讓它們準備開始接受流量。典型的pod層級擴展是用Heapster度量來決定是否需要創建新的實例。我們實際上設置最小pod數很低，相信Kubernetes Horizontal Pod Autoscaler來正確設置最佳副本數量。我們總是設置每個集群最小值大於1個副本，避免單點失敗情況。

擴展節點是比較少見的情況，但是對於高彈性的應用來說是非常有用的擴展機制。節點擴展將需要支持IaaS（AWS，GCP等等）來擴展和註冊到Kubernetes集群中。這個過程可以人工完成，儘管我們不建議這麼做。通常我們用工具來自動化單個節點的縮放（例如Kubernetes Repo）。節點級的autoscaler主要將做兩件事，第一個是當需要時增加更多的節點，第二個是移除未充分使用的節點。

06

資源分配

Resource Quotas

資源分配可以讓你在Kubernetes平台里限制namespace，確保一個應用不會消耗掉所有資源和影響其他應用。設置資源分配有一點挑戰。在我們的經驗中，我們發現通過預期負載來分解namespace和使用一個比例來計算集群的百分比是最有策略的開始。運行Heapster允許使用kubectl top 命令，它顯示了當前節點或pod資源使用，有時候對於分配也有幫助。從這點來說，如果你的分割是對的，就使用監控和審計來確定。

07

容器資源限制

Container Resource Constraints

搞清楚單個容器或pod需要多少資源已經變成一項藝術。以前，開發人員團隊已經把他們的評估方法變的比需要的更強。我們嘗試執行一些層級的負載測試來了解它是如何失敗的，然後適當分配資源。Netfilix創造這個方法「擠壓測試」。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！