遵循精益方法可以幫助我們顯著提高 Kubernetes 的投資回報率，改善工作負載性能，并節省維護和故障排除的時間。
譯自 What Does It Mean to Keep Clusters Lean?，作者 Ant Weiss。
随着 Kubernetes 成為建構現代軟體傳遞平台的事實标準，有效管理叢集 變得越來越重要。這一過程催生了“保持叢集精益”的流行口号。
您是否在實踐DevOps？這意味着您是精益的！精益原則位于 DevOps 方法論的核心。并非偶然，CALMS 思維架構（由 DevOps 先驅 John Willis 和 Damon Edwards 提出，并由 Jez Humble 進一步發展）中的“L”代表精益傳遞實踐。
現代 DevOps 實踐植根于精益管理原則。這些原則，包括準時制零件傳遞和消除浪費，最初由二戰後日本的豐田生産系統 (TPS) 定義。後來，在 1990 年代，西方創造了“精益”一詞來描述這些理念。諸如“改變世界的機器”之類的書籍解釋了 TPS 以及精益管理如何在全球範圍内傳播到各個行業，包括軟體開發。
“精益軟體開發”一書由 Mary 和 Tom Poppendieck 于 2003 年出版，定義了軟體傳遞中遇到的浪費類型，并描述了如何通過結構化的持續改進流程來消除這些浪費。
雲原生世界中的精益原則
簡而言之，精益管理的原則如下：
- 專注于價值
- 消除浪費
- 追求持續改進
遵循這些原則，企業可以更快地傳遞價值，減少浪費，并實作更高的生産品質。
雲原生基礎設施旨在通過提供雲資源（無需冗長的規劃流程和未充分利用的伺服器場）來快速傳遞高品質軟體并優化價值流。自治工程團隊部署自治微服務，這些微服務異步且高效地與其他服務互動。
當然，這是理想情況。但在現實生活中，大多數 Kubernetes 叢集都是浪費的，而且不夠可靠。它們中發生的事情太多了，無法在不應用明确定義的方法的情況下有效地管理它們。
随着 Kubernetes 成為運作生産級軟體（無論是 Web 服務、批處理還是資料管道）的事實标準方式，人們越來越認識到，隻有通過有意識地保持叢集精益，才能實作令人滿意的雲 ROI，進而在充滿挑戰的全球 IT 市場中保持競争力。
保持叢集精益
以下是一些幫助保持 Kubernetes 叢集精益的實踐。
1. 專注于價值
一旦我們将傳遞平台标準化為使用 Kubernetes，将大多數工作負載運作在那裡是有意義的。但是，我們的工作負載及其提供的價值類型可能會有很大差異。長期運作的 Web 服務的可靠性标準與 ML 模型訓練或定期批處理作業的可靠性标準不同。此外，還需要考慮環境成熟度。開發實驗、性能測試、CI 作業和一次性維護程式具有不同的可用性要求和合理的營運成本。
節點選擇
根據所需的可用性級别和節省的工程時間，定義用于叢集的 VM 執行個體類型（例如，選擇搶占式執行個體而不是預留容量）。
您可以使用LearnK8S Kubernetes 執行個體電腦 進行初始規劃。
所有雲提供商現在都提供基于專用作業系統（如 Bottlerocket OS）或 ARM 處理器的優化執行個體。
使用此類執行個體可以使我們的叢集更精益、更便宜，但需要事先驗證它們是否适合我們的特定工作負載。
網絡拓撲限制
仔細選擇叢集的網絡拓撲結構會對雲賬單産生重大影響，尤其是在運作資料密集型工作負載時。在建立大多數叢集時，預設情況下會在三個可用區中運作資料平面以提高可用性。叢集内跨 AZ 網絡傳輸的每個位元組都會花費您額外的幾分錢。是以，當可用性不是我們想要實作的價值的一部分（例如，對于背景批處理）時，有意義地覆寫預設設定并在同一個 AZ 中運作所有節點。
存儲配置
Kubernetes 提供多種存儲選項，它們在持久性、可用性和性能級别方面有所不同。專注于提供的價值，我們可以為工作負載選擇最合适的存儲類型。
2. 消除風險
最初的豐田生産系統開創了安燈線的概念——一根貫穿整個工廠的電纜，任何勞工可以拉動它來停止生産線。這個想法是管理層信任勞工是他們所在領域的專家，是以他們應該在發現任何他們認為對生産品質構成風險的問題時拉動電纜。任何潛伏的風險都可能導緻後續的重大浪費。Kubernetes 的工作方式相同。是以，在考慮浪費之前，應該處理具有潛在安全性和可靠性風險的工作負載。
以下是一些常見的 Kubernetes 工作負載風險及其緩解方法：
未定義的資源請求和限制
當未定義請求和限制時，Kubernetes 排程程式将所有 pod 都視為 BestEffort pod。這意味着沒有任何可靠性保證。這可以通過使用 LimitRange 對象來一定程度地防止，但需要持續的 pod 調整大小（下一節中描述）來緩解這種情況。
資源請求和限制不足
這意味着我們的 pod 沒有獲得所需的資源，這會導緻意外故障和延遲增加，進而影響應用程式的可靠性。
容器重新開機
容器是臨時的，可以在發生故障時無縫重新開機。這是最常見的 Kubernetes 工作負載類型（如 Deployment 和 DaemonSet）的預設操作模式。然而，頻繁發生的重新開機表明存在問題。無論是應用程式錯誤、權限問題還是配置錯誤的存活探測，我們都希望盡快對其進行故障排除和修複，以保持叢集精益。
這裡還有其他類型的風險。我們需要一個目标可觀察性系統來發現并提醒我們叢集中的可靠性風險，以及智能自主自動化來修複最常見的問題。
3. 消除浪費
如前所述，大多數叢集需要更高效地利用。換句話說，使用大量雲資源會導緻過度支出。
我們希望為工作負載提供盡可能多的資源，這是可以了解的——沒有工程師希望他們的應用程式因為 CPU 限制而像烏龜一樣緩慢爬行，或者因為 OOM 殺死而悲慘地死亡。但遺憾的是，即使給一個容器提供三到四倍的資源，也無法提供可靠性保證！同一節點上可能存在其他配置錯誤的容器，它們具有不足的請求和過度的限制，導緻我們的容器即使在我們的慷慨幫助下也無法獲得資源。
要達到所需的可靠性和成本目标，唯一的方法是了解叢集中浪費的來源，并建立一個持續消除浪費的過程。
以下是一些每個 Kubernetes 管理者都應該采用的實踐，以保持其叢集無浪費：
Pod 調整大小
apiVersion: v1
kind: Pod
metadata:
name: myapp
spec:
containers:
- name: app
image: images.my-company.example/app:v4
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m" 正确定義 pod 中容器的資源請求和限制會影響所有内容，從基本排程和驅逐到 HPA 操作和節點自動擴充。問題是，這需要大量的工作才能确定。性能測試 可以幫助進行初始定義。然而，Kubernetes 環境的動态性要求我們持續監控運作時資源消耗并相應地更新配置，最好以自動化的方式。這是確定我們的容器在需要時獲得所需資源的唯一方法。
節點使用率監控
即使我們的容器資源經過優化，我們仍然會遇到額外的浪費，因為我們的節點選擇不是最佳的。這可能是由于在适當的時候沒有使用折扣 Spot 執行個體和預留執行個體，或者配置了資源無法被活動工作負載有效利用的執行個體類型。精益叢集必須由一個自動化系統進行管理，該系統提供節點組和類型級别的節點使用率的細粒度可見性，并提供智能建議，以重新配置節點池以進行進一步優化。
4. 及時供應
未使用的基礎設施會浪費我們的資金，并産生不必要的維護開銷，而不會增加任何額外價值。精益方法的核心是在需要時提供資源，并在不再需要時釋放資源。
以下是一些保持叢集精益的方法：
自動擴充
自動擴充功能使 Kubernetes 真正成為雲原生。然而，它們是可選的！定義自動擴充需要在 Pod（HPA、VPA、KEDA）或節點級别（cluster-autoscaler、Karpenter 等）進行額外的配置。保持叢集精益意味着投資于此配置，持續驗證自動擴充算法的效率，并對其進行優化以适應系統不斷變化的需求。
即時節點供應
并非所有節點自動擴充器都是相同的。例如，傳統的 cluster-autoscaler 的效率受到靜态 ASG 配置的限制。精益意味着在需要時精确地供應我們需要的資源——是以，精益叢集遷移到 Karpenter（如果在 AWS 上）或節點自動供應（在 GCP 和 Azure 上）。
動态環境管理
一個完善的 Kubernetes 自動化設定允許我們通過在現有叢集中建立命名空間或啟動新的叢集來快速配置新環境。這種易用性會導緻許多資源未被充分利用。保持精益需要制定一個操作政策來管理這些環境，并在不再需要時将其退役。請參閱 此處 以了解如何在非工作時間将 Kubernetes 資源置于休眠狀态的示例。
5. 持續優化
精益方法基于持續改進的理念——即始終尋找使生産流程更高效、提高品質和減少浪費的額外方法。
同樣，我們希望通過自動化資源配置設定、分析成本和性能趨勢、重新定義 SLO 以及不懈地消除風險來持續優化 Kubernetes 叢集。
總結
遵循精益方法可以幫助我們顯著提高 Kubernetes 的投資回報率，改善工作負載性能，并節省用于維護和故障排除的時間。
為了保持叢集精益——請遵循以下指南：
- 專注于價值
- 消除風險
- 消除浪費
- 即時供應
- 持續優化
願您的叢集保持精益！