Kubernetes 能否幫助解決自動化挑戰？

組織層面的自動化一直是一個難以實現的目標，但 Kubernetes 或許能夠改變這一切。

當我在 2002 年採用 Gentoo Linux 作為我的主要操作系統時，我開始了我的自動化之旅。二十年後，自動化還沒有完成。當我與客戶和合作夥伴會面時，他們分享了團隊內部的自動化成果，但他們也描述了在組織層面實現類似成功所面臨的挑戰。

大多數 IT 組織都能夠端到端地提供虛擬機，從而將過去 4 周的交付周期縮短到僅 5 分鐘。這種級別的自動化本身就是一個複雜的工作流程，需要網路（IP 地址管理、DNS、代理、網路區域等）、身份訪問管理、虛擬機管理程序、存儲、備份、更新操作系統、應用最新的配置文件、監控、安全和強化以及合規性基準測試，等等。哇，這麼多！

滿足高速、可擴展和按需自動化的業務需求並不容易。例如，來看看經典的網上商店或提交納稅申報表的在線政府服務，其工作負載有明確的峰值需要面對。

處理此類負載的一種常見方法是擁有一個超大的伺服器集群，以供 IT 專業人員的特定團隊使用，監控客戶或公民的季節性湧入。每個人都希望及時部署整個棧。他們希望基礎架構在混合雲場景的上下文中運行工作負載，使用「 構建-消耗-回收 build-consume-trash 」模型來優化成本，同時從無限彈性中受益。

換句話說，每個人都想要烏托邦式的「雲體驗」。

雲真的能交付嗎？

尚有一線機會，這主要歸功於 Kubernetes 的設計方式。Kubernetes 的指數級普及推動了創新，取代了管理平台和應用的標準傳統做法。 Kubernetes 需要使用 「 萬物皆代碼 Everything-as-Code 」（EaC）來定義從簡單的計算節點到 TLS 證書的所有資源的期望狀態。Kubernetes 強制使用三種主要的設計結構：

• 一個標準介面，以減少內部和外部組件之間的整合問題
• API 優先及僅 API 的方法來標準化其所有組件的 CRUD（創建、讀取、更新、刪除）操作
• 使用 YAML 作為通用語言，以簡單易讀的方式定義這些組件的所有所需狀態

這三個關鍵組成部分基本上是選擇自動化平台的相同要求，至少如果你想讓跨職能團隊輕鬆採用是這樣的。這也模糊了團隊之間的職責分工，有助於提高跨越孤島的協作，這是一件好事！

事實上，採用 Kubernetes 的客戶和合作夥伴正在加速進入超自動化狀態。Kubernetes 有機地推動團隊採用多種 DevOps 基礎和實踐，如：EaC、使用 Git 進行版本控制、同行評審、 文檔即代碼 Documentation as Code ，並鼓勵跨職能協作。這些實踐有助於提高團隊的自動化技能，並幫助團隊在處理應用生命周期和基礎架構的 GitOps 和 CI/CD 管道方面取得良好的開端。

讓自動化成為現實

你沒看錯！網路商店或政府報告等複雜系統的整個棧可以用清晰、可理解、通用的術語定義，可以在任何本地或雲提供商上執行。可以定義具有自定義指標的自動伸縮器以觸發所需棧的即時部署，以解決季節性高峰期間客戶或市民的湧入問題。當指標恢復正常，且雲計算資源不再有存在的理由時，你將它們回收並恢復常規運營，而由一組核心資產在本地接管業務，直到下一次激增。

雞和蛋的悖論

考慮到 Kubernetes 和雲原生模式，自動化是必須的。但它提出了一個重要的問題：一個組織可以在解決自動化戰略之前採用 Kubernetes 嗎？

似乎從 Kubernetes 開始可以激發更好的自動化，但這並不是一個一成不變的結論。工具不是對技能、實踐和文化問題的解決方案。但是，設計良好的平台可以成為 IT 組織內學習、變革和跨職能協作的催化劑。

開始使用 Kubernetes

即使你覺得自己錯過了自動化列車，也不要害怕從簡單、不複雜的棧上開始使用 Kubernetes。當你 掌握了初始步驟，就可以擁抱這個出色的編排系統的簡單性，並根據更複雜的需求進行迭代。

via: https://opensource.com/article/22/10/kubernetes-solve-automation-challenges

作者：Rom Adams 選題：lkxed 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive