當我在 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。當你 ??掌握了初始步驟??，就可以擁抱這個出色的編排系統的簡單性，并根據更復雜的需求進行迭代。