當(dāng)我在 2002 年采用 Gentoo Linux 作為我的主要操作系統(tǒng)時，我開始了我的自動化之旅。二十年后，自動化還沒有完成。當(dāng)我與客戶和合作伙伴會面時，他們分享了團隊內(nèi)部的自動化成果，但他們也描述了在組織層面實現(xiàn)類似成功所面臨的挑戰(zhàn)。

大多數(shù) IT 組織都能夠端到端地提供虛擬機，從而將過去 4 周的交付周期縮短到僅 5 分鐘。這種級別的自動化本身就是一個復(fù)雜的工作流程，需要網(wǎng)絡(luò)（IP 地址管理、DNS、代理、網(wǎng)絡(luò)區(qū)域等）、身份訪問管理、??虛擬機管理程序??、存儲、備份、更新操作系統(tǒng)、應(yīng)用最新的配置文件、監(jiān)控、安全和強化以及合規(guī)性基準測試，等等。哇，這么多！

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

處理此類負載的一種常見方法是擁有一個超大的服務(wù)器集群，以供 IT 專業(yè)人員的特定團隊使用，監(jiān)控客戶或公民的季節(jié)性涌入。每個人都希望及時部署整個棧。他們希望基礎(chǔ)架構(gòu)在混合云場景的上下文中運行工作負載，使用“構(gòu)建-消耗-回收build-consume-trash”模型來優(yōu)化成本，同時從無限彈性中受益。

換句話說，每個人都想要烏托邦式的“云體驗”。

云真的能交付嗎？

尚有一線機會，這主要歸功于 ??Kubernetes?? 的設(shè)計方式。Kubernetes 的指數(shù)級普及推動了創(chuàng)新，取代了管理平臺和應(yīng)用的標準傳統(tǒng)做法。 Kubernetes 需要使用 “萬物皆代碼Everything-as-Code”（EaC）來定義從簡單的計算節(jié)點到 TLS 證書的所有資源的期望狀態(tài)。Kubernetes 強制使用三種主要的設(shè)計結(jié)構(gòu)：

• 一個標準接口，以減少內(nèi)部和外部組件之間的整合問題
• API 優(yōu)先及僅 API 的方法來標準化其所有組件的 CRUD（創(chuàng)建、讀取、更新、刪除）操作
• 使用??YAML?? 作為通用語言，以簡單易讀的方式定義這些組件的所有所需狀態(tài)

這三個關(guān)鍵組成部分基本上是選擇自動化平臺的相同要求，至少如果你想讓跨職能團隊輕松采用是這樣的。這也模糊了團隊之間的職責(zé)分工，有助于提高跨越孤島的協(xié)作，這是一件好事！

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

讓自動化成為現(xiàn)實

你沒看錯！網(wǎng)絡(luò)商店或政府報告等復(fù)雜系統(tǒng)的整個?？梢杂们逦?、可理解、通用的術(shù)語定義，可以在任何本地或云提供商上執(zhí)行。可以定義具有自定義指標的自動伸縮器以觸發(fā)所需棧的即時部署，以解決季節(jié)性高峰期間客戶或市民的涌入問題。當(dāng)指標恢復(fù)正常，且云計算資源不再有存在的理由時，你將它們回收并恢復(fù)常規(guī)運營，而由一組核心資產(chǎn)在本地接管業(yè)務(wù)，直到下一次激增。

雞和蛋的悖論

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

似乎從 Kubernetes 開始可以激發(fā)更好的自動化，但這并不是一個一成不變的結(jié)論。工具不是對技能、實踐和文化問題的解決方案。但是，設(shè)計良好的平臺可以成為 IT 組織內(nèi)學(xué)習(xí)、變革和跨職能協(xié)作的催化劑。

開始使用 Kubernetes

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