簡介：基于容器、Kubernetes 等云原生技術，提供的開放社區標準、不可變基礎設施、聲明式 API 會成為企業 CloudOps 的最佳實踐，也將在這個基礎上推進數據化、智能化體系建設，將運維復雜性進一步下沉，讓企業可以聚焦于自己的業務創新。阿里云也將持續向外輸出自身在超大規模云原生實踐和探索中的能力沉淀，與更多企業、開發者一起，躬身入局，全面擁抱云原生運維技術體系。

作者 | 易立

云原生已經成為數字經濟技術的創新基石，并且正在深刻地改變企業上云和用云的方式。云原生的用云方式可以幫助企業最大化獲得云價值，也給企業的計算基礎設施、應用架構、組織文化和研發流程帶來新一輪變革。而業務和技術挑戰也催生了新一代云原生運維技術體系。

本文整理自阿里云資深技術專家、容器服務研發負責人易立在阿里云聯合主辦的“2021云上架構與運維峰會”中的演講實錄，分享了云原生時代運維技術發出的重要改變，以及源自阿里云超大規模云原生應用發展進程中的CloudOps實踐。

易立，阿里云資深技術專家、容器服務研發負責人

新商業帶來新機遇與新挑戰

阿里云對云原生的定義是因云而生的軟件、硬件和架構，幫助企業最大化獲得云價值。云原生技術帶來的變化包含幾個維度：

• 首先是計算基礎設施的變化，包含虛擬化、容器、函數計算的新的計算形態，幫助應用高效地運行在公共云、私有云、邊緣云等不同的云環境。
• 其次是應用架構的變化。利用微服務、服務網格等技術幫助企業構建分布式、松耦合、高彈性、高容錯的現代化應用。
• 最后是組織、文化和流程的變化。比如 DevOps、DevSecOps、FinOps、 SRE 等理念持續推動現代化的軟件開發流程和組織升級。

回顧云原生出現的時代背景，移動互聯網的出現改變了商業的形態，改變了人與人溝通的方式，讓任何人在任何時間、任何地點都可以輕松獲取自己所需的服務。IT 系統需要能夠應對互聯網規模的快速增長，并且能夠快速迭代、低成本試錯。

以 Netflix、阿里為代表的一系列互聯網公司推動了新一代應用架構的變革，Spring Cloud、Apache Dubbo 等微服務架構應運而生。微服務架構解決了傳統單體式應用存在的幾個問題：每個服務可以獨立部署和交付，大大提升了業務敏捷性；每個服務可以獨立橫向擴容，應對互聯網規模的挑戰。

與傳統單體應用相比，分布式的微服務架構具備更快的迭代速度、更低的開發復雜性和更好的可擴展性。但同時，它的部署和運維的復雜性卻大大增加。我們需要如何應對？

此外，“脈沖”計算成為常態。比如雙十一大促期間，零點需要的算力是平時的數十倍；一個突發的新聞事件，可能讓上千萬用戶涌向社交媒體。云計算無疑是處理突發流量洪峰的更加經濟、高效的方式。如何上好云、用好云、管好云，如何讓應用可以更加充分利用基礎設施的彈性，成為企業運維團隊的關注重點。這些業務和技術挑戰也催生了云原生的運維技術體系 – CloudOps。

云原生時代運維技術變革

1、云原生運維解決之道

CloudOps 要解決幾個關鍵問題：

• 標準化：標準化可以促進開發團隊與運維團隊的溝通和協同，標準化也有助于生態分工，推動更多自動化工具的出現。
• 自動化：只有自動化運維，才能支撐互聯網規模的挑戰，才能持續支撐業務的快速迭代與穩定性。
• 數智化：數據化、AI 增強的自動化運維成為未來發展的必然趨勢

2、容器 “應用集裝箱”重塑軟件供應鏈

在傳統的應用分發、部署過程中，常會由于缺乏標準導致工具碎片化，比如 Java 應用和 AI 應用的部署，需要完全不同的技術棧，交付效率低。此外，為了避免應用之間的環境沖突，我們經常需要將每個應用單獨部署在一個獨立的物理機或者虛擬機上，這也造成了很多資源浪費。

2013 年開源的容器技術 Docker 出現，開創性地提出了基于容器鏡像的應用分發和交付方式，重塑了軟件開發、交付和運維的整個生命周期。

就像傳統的供應鏈體系為例，不管什么樣的產品都是通過使用集裝箱來進行運輸，極大提升了物流效率，使得全球化的分工協同成為可能。

容器鏡像將應用和其依賴的應用環境一同打包。鏡像可以通過鏡像倉庫進行分發，可以一致的方式運行在開發、測試和生產環境中。

容器技術是一種輕量化 OS 虛擬化能力，可以提升應用部署密度，優化資源利用率，與傳統的虛擬化技術相比，更加敏捷、輕量，具備更好的彈性和可移植性。

容器作為云時代的“應用集裝箱”，重塑了整個軟件供應鏈，也開啟了云原生技術浪潮。

3、容器技術加速不可變基礎設施理念落地

在傳統的軟件部署和變更過程中，經常會出現因為環境間的差異導致應用出現不可用的問題。比如，新版本應用需要依賴 JDK11 的能力，而如果部署環境中沒有更新 JDK 版本，就會導致應用失敗。“It works on my machine”也成了開發人員打趣的口頭禪。而且隨著時間的推移，系統的配置已經不可考，采用原地升級的方式在變更的時候一不留神就會掉進坑里。

不可變基礎設施（Immutable Infrastructure）是由 Chad Fowler 于 2013 年提出的一個理念，其核心思想是“任何基礎設施實例一旦創建，就變成為只讀狀態，如需要修改和升級，則使用新的實例進行替換。”

這種模式可以減少配置管理的復雜性，確保系統配置變更可以可靠地、重復地執行。而且一旦部署出錯時可進行快速回滾。

Docker 和 Kubernetes 容器技術正是實現 Immutable Infrastructure 模式的最佳方式。當我們為容器應用更新一個鏡像版本的時候，Kubernetes 會新創建一個容器，并且通過負載均衡將新請求路由到新容器，然后銷毀老容器，這避免了令人頭疼的配置漂移問題。

4、Kubernetes：分布式資源調度的標準及 CloudOps 最佳載體

目前，容器鏡像已經成為了分布式應用交付的標準。Kubernetes 已經成為了分布式資源調度的標準。

越來越多的應用，通過容器方式進行管理、交付：從無狀態的 Web 應用，有狀態的數據庫、消息等應用，再到數據化、智能化應用。

CNCF 2020 年調查報告指出，55%的受訪者已經在生產中的容器中運行有狀態應用；Gartner 預測到 2023 年，70%的 AI 任務會通過容器或 Serverless 模式構建。

對比一下經典的 Linux 操作系統和 Kubernetes 的概念模型，他們的目標都是向下封裝資源，向上支撐應用，提供了標準化的 API 來支持應用生命周期，并且提升應用的可移植性。

不同的是，Linux 的計算調度單元是進程，調度范圍限制在一臺計算節點。而 Kubernetes 的調度單位是 Pod 一個進程組，它的調度范圍是一個分布式集群，支持應用在公共云、專有云等不同環境間進行遷移。

對于運維團隊而言，Kubernetes 成為實現 CloudOps 理念的最佳平臺。

首先是 K8s 采用聲明式 API，讓開發者可以專注于應用自身，而非系統執行細節。比如，在 Kubernetes 之上，提供了 Deployment、StatefulSet、Job 等不同類型應用負載的抽象。聲明式 API 是云原生重要的設計理念，有助于將系統復雜性下沉，交給基礎設施進行實現和持續優化。

此外，K8s 提供了可擴展性架構，所有 K8s 組件都是基于一致的、開放的 API 進行實現和交互。開發者也可通過 CRD（Custom Resource Definition）/ Operator 等方式提供領域相關的擴展，極大拓寬了 K8s 的應用場景。

最后，K8s 提供平臺無關的技術抽象：如 CNI 網絡插件, CSI 存儲插件等等，可以對上層業務應用屏蔽基礎設施差異。

5、為什么是 Kubernetes？

Kubernetes 的成功背后的魔法就是控制循環，Kubernetes 有幾個簡單的概念。

首先，一切都是資源，通過控制器對資源進行自動化管理。

用戶可以聲明資源的目標狀態。當控制器發現資源當前狀態與目標狀態存在不一致，就會持續調整，讓資源狀態趨近于目標狀態。通過這個方法，可以統一處理各種情況，比如，根據調整應用副本數進行擴縮容，或者節點宕機后應用自動遷移，等等。

正因如此，Kubernetes 支持資源范圍已經遠超容器應用。比如服務網格，可以對應用通信流量進行聲明式管理；Crossplane 可以利用 K8s CRD 對 ECS，OSS 等云資源進行管理和抽象。

6、云原生應用自動化管理探索與開源實踐

K8s 控制器 “把復雜留給自己，把簡單交給用戶”的理想非常美好，然而實現一個高效、健壯的控制器卻充滿技術挑戰。

OpenKruise 是阿里云開源的云原生應用自動化管理引擎，也是捐獻到 Cloud Native Computing Foundation (CNCF) 下的沙箱項目。它來自阿里巴巴多年來容器化、云原生的技術沉淀，解決容器應用在大規模生產環境的自動化和穩定性挑戰。

OpenKruise 提供了增強的應用灰度發布，穩定性防護，Sidecar 容器擴展等多種能力。

OpenKruise 開源實現和集團內部版本代碼保持一致。支撐了阿里集團應用 100%云原生化，也已經在蘇寧、OPPO、小米、Lyft 等企業得到廣泛應用。歡迎大家社區共建和使用反饋。

7、GitOps：聲明式 API 催生的應用交付流程與協同新方式

基礎架構即代碼（Infrastructure-as-Code，IaC）是一種典型的聲明式 API，它改變了云上資源管理、配置和協同的方式。利用 IaC 工具，我們可以將云服務器、網絡和數據庫等不同云資源進行自動化的創建、組裝和變配。

將 IaC 概念進行延伸，可以覆蓋整個云原生軟件的交付、運維流程，即 Everything as Code。本圖列出來云原生應用涉及的各種模型，從基礎設施、到應用定義、到應用交付管理和安全體系，我們都可以通過聲明式方式對應用的配置進行管理。

比如，我們可以通過 Istio 來對應用流量切換進行聲明式處理，可以利用 OPA（Open Policy Agent）來定義運行時安全策略等等。

更近一步，我們可以將應用的所有環境配置都通過源代碼控制系統 Git 進行管理，并通過自動化的流程進行交付和變更。這樣就是 GitOps 的核心理念。

首先，從應用定義到基礎設施環境，所有的配置都以源代碼的方式保存在 Git 中；所有變更、審批記錄也記錄在 Git 的歷史狀態中。這樣 Git 成為 sourceof truth，我們可以追溯變更歷史、可以回滾到指定版本。

GitOps 與聲明式 API、不可變基礎設施相結合，保障了應用環境的可復現性，提升了交付與管理效率。GitOps 在阿里集團已經被廣泛使用，在阿里云容器服務 ACK 中也有支持。目前 GitOps 開源社區也在不斷完善相關的工具和最佳實踐，大家可以關注相關進展。08

8、云原生催生穩定性思想變革

分布式系統存在高度復雜性，在應用、基礎設施、部署過程中任何一個地方的問題，都可能導致業務系統的故障。

面對這樣的不確定性風險，我們有兩種做法：一種是“聽天由命”，信佛祖，不宕機；一種是通過系統化的方法進行主動出擊，提升系統的確定性。

2012 年，Netflix 提出了“混沌工程”的理念，通過主動注入故障的方式，提前發現系統的薄弱環節，推進架構的改進，最終實現業務韌性。我們可以將混沌工程的工作方式比作疫苗，通過“接種滅活疫苗”的方式，讓我們的免疫系統受到鍛煉，具備抵擋 “疾病” 的能力。

阿里雙十一購物節的順利成功，離不開全鏈路壓測等對混沌工程的大規模實踐，為此阿里團隊在這個領域積累了豐富的實戰經驗。

ChaosBlade 是一組遵循混沌工程理念的實驗工具，具有場景豐富、簡單易用等特點，已經成為 CNCF 沙箱項目。它支持 Linux、Kubernetes、Docker 等不同運行環境，以及 Java、NodeJS、C++、Golang 等多種語言。內置了 200 多個場景的測試方案。

chaosblade-box 是新引入的混沌工程控制臺，可實現實驗環境平臺化管理，進一步簡化用戶體驗，降低使用門檻。歡迎大家加入 Chaosblade 社區共建，也可以使用阿里云應用高可用服務 AHAS 云服務。

云原生 CloudOps 之路

最后我將結合阿里實踐，介紹我們在 CloudOps 上的一些探索。

在傳統組織中，開發和運維角色是嚴格分開的。而不同業務線也構建了一個一個的煙囪化架構，從基礎設施環境與運維，到應用運維與開發，都是獨立的團隊，缺乏良好的協同與復用。

云時代的到來也在改變著現代 IT 組織和流程。

首先，公共云、專有云成為了不同業務部門間共享的基礎設施。

然后，SRE （Site ReliabilityEngineering）理念開始得到廣泛接受。是通過軟件和自動化手段，來解決系統的運維復雜性和穩定性問題。由于 Kubernetes 的標準化、可擴展性和可移植性等優勢，越來越多企業的SRE團隊基于 K8s 管理云環境，極大提升了企業運維效率與資源效率。

在此之上，平臺工程團隊開始浮現，基于 Kubernetes 構建企業的 PaaS 平臺和 CI/CD 流程，支持中間件和不同業務部門的應用部署與運維。提升企業的標準化和自動化水平，進一步提升應用研發、交付效率。

這樣的分層結構中，向下的團隊更多是通過 SLO 驅動，從而讓上層系統對底層依賴技術具備更好的可預期性。越向上的團隊更多是業務驅動，更好地支撐業務發展。01

1、阿里云容器服務 SRE 團隊的最佳實踐

阿里云容器服務 SRE 團隊一直也在踐行 CloudOps 的最佳實踐，簡單總結如下：

第一項是全局穩定性架構設計，讓整個平臺防范與未然：

• 首先 Securityby-design：讓系統做到默認安全，同時通過安全軟件供應鏈保障全生命周期安全
• 其次 Designfor failure：控制爆炸半徑、提供限流/降級手段降低故障影響面
• 第三 Designfor automation：類似擴縮容、故障恢復等工作盡可能自動化完成
• 最后 Observabilityby-design：為每個生產應用定義 SLO，并建立相關的可觀測性體系，持續關注請求量，延遲、錯誤數、飽和度等黃金指標

第二項是建設穩定性應急體系，也就是我們日常所說的 1-5-10 快恢能力，它包含：

• 1 分鐘發現 - 包括通過黑盒、白盒監控能力
• 5 分鐘定位 - 提供診斷大盤，利用工具實現自動化根因定位
• 10 分鐘止損 - 包含系統化的預案的設計與持續積累，和自動化預案執行

最后一項是日常穩定性保障，主要包含：

• 變更管理規范化 – 所有發布做到可灰度、可監控、可回滾
• 問題跟蹤流程化 - 凡事有交代，件件有著落，做一個靠譜青年
• 故障演練常態化 – 通過巡檢、突襲、壓測等手段查漏補缺，讓故障預案持續保鮮

2、擁抱云原生運維技術體系

云原生已經成為勢不可擋的技術趨勢。Gartner 預測到 2025 年，95%數字化運維將通過云原生平臺進行支撐。

我們可以根據企業能力和業務目標選擇合適的遷云之路，大致可以分為幾個階段：

• Rehost 新托管：簡單地通過 lift-and-shift 方式，將線下物理機替換成為云上虛擬機或者裸金屬實例，不改變原有的運維方式。
• Re-platform 新平臺：利用托管的云服務替換線下自建應用基礎設施，比如通過 RDS 數據庫服務替換自建 MySQL，通過阿里云容器服務 ACK 來取代自建 K8s 集群。托管的云服務通常提供更好的彈性、穩定性和自治運維能力，可以讓用戶關注于應用而非基礎設施管理。
• Refactor/Re-architect 重構/新架構：包括對單體應用的微服務架構改造、容器化和 Serverless 化等現代化改造。

從 Rehost、Re-platform 到 Re-architect，我們可以看到遷移的復雜性和所需技能在增加，但是敏捷性、彈性、可用性、容錯性等收益也在持續增加。

阿里集團上云也經歷了這樣的歷程，在去年業務 100%上公共云的基礎之上，今年實現了應用 100%云原生化。幫助阿里業務的研發效率提升了 20%，資源利用率提升了 30%。

最后做一個快速總結。基于容器、Kubernetes 等云原生技術，提供的開放社區標準、不可變基礎設施、聲明式 API 會成為企業 CloudOps 的最佳實踐，也將在這個基礎上推進數據化、智能化體系建設，將運維復雜性進一步下沉，讓企業可以聚焦于自己的業務創新。阿里云也將持續向外輸出自身在超大規模云原生實踐和探索中的能力沉淀，與更多企業、開發者一起，躬身入局，全面擁抱云原生運維技術體系。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的云原生时代的运维体系进化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。