Kubernetes 能否幫助解決自動化挑戰?
![](https://linuxstory.org/wp-content/uploads/2024/06/105625ocz9sd9z6g4dzb44-800x400.jpg)
組織層面的自動化一直是一個難以實現的目標,但 Kubernetes 或許能夠改變這一切。
當我在 2002 年採用 Gentoo Linux 作為我的主要操作系統時,我開始了我的自動化之旅。二十年後,自動化還沒有完成。當我與客戶和合作夥伴會面時,他們分享了團隊內部的自動化成果,但他們也描述了在組織層面實現類似成功所面臨的挑戰。
大多數 IT 組織都能夠端到端地提供虛擬機,從而將過去 4 周的交付周期縮短到僅 5 分鐘。這種級別的自動化本身就是一個複雜的工作流程,需要網路(IP 地址管理、DNS、代理、網路區域等)、身份訪問管理、虛擬機管理程序、存儲、備份、更新操作系統、應用最新的配置文件、監控、安全和強化以及合規性基準測試,等等。哇,這麼多!
滿足高速、可擴展和按需自動化的業務需求並不容易。例如,來看看經典的網上商店或提交納稅申報表的在線政府服務,其工作負載有明確的峰值需要面對。
處理此類負載的一種常見方法是擁有一個超大的伺服器集群,以供 IT 專業人員的特定團隊使用,監控客戶或公民的季節性湧入。每個人都希望及時部署整個棧。他們希望基礎架構在混合雲場景的上下文中運行工作負載,使用「 構建-消耗-回收 」模型來優化成本,同時從無限彈性中受益。
換句話說,每個人都想要烏托邦式的「雲體驗」。
雲真的能交付嗎?
尚有一線機會,這主要歸功於 Kubernetes 的設計方式。Kubernetes 的指數級普及推動了創新,取代了管理平台和應用的標準傳統做法。 Kubernetes 需要使用 「 萬物皆代碼 」(EaC)來定義從簡單的計算節點到 TLS 證書的所有資源的期望狀態。Kubernetes 強制使用三種主要的設計結構:
- 一個標準介面,以減少內部和外部組件之間的整合問題
- API 優先及僅 API 的方法來標準化其所有組件的 CRUD(創建、讀取、更新、刪除)操作
- 使用 YAML 作為通用語言,以簡單易讀的方式定義這些組件的所有所需狀態
這三個關鍵組成部分基本上是選擇自動化平台的相同要求,至少如果你想讓跨職能團隊輕鬆採用是這樣的。這也模糊了團隊之間的職責分工,有助於提高跨越孤島的協作,這是一件好事!
事實上,採用 Kubernetes 的客戶和合作夥伴正在加速進入超自動化狀態。Kubernetes 有機地推動團隊採用多種 DevOps 基礎和實踐,如:EaC、使用 Git 進行版本控制、同行評審、 文檔即代碼 ,並鼓勵跨職能協作。這些實踐有助於提高團隊的自動化技能,並幫助團隊在處理應用生命周期和基礎架構的 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
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive