雲原生已經成為數字經濟技術的創新基石，並且正在深刻地改變企業上雲和用雲的方式。雲原生的用雲方式可以幫助企業最大化獲得雲價值，也給企業的計算基礎設施、應用架構、組織文化和研發流程帶來新一輪變革。而業務和技術挑戰也催生了新一代雲原生運維技術體系。
本文整理自阿里雲資深技術專家、容器服務研發負責人易立在阿里雲聯合主辦的“2021雲上架構與運維峰會”中的演講實錄，分享了雲原生時代運維技術發出的重要改變，以及源自阿里雲超大規模雲原生應用發展程式中的CloudOps實踐。
阿里雲對雲原生的定義是因雲而生的軟體、硬體和架構，幫助企業最大化獲得雲價值。雲原生技術帶來的變化包含幾個維度：
回顧雲原生出現的時代背景，移動網際網路的出現改變了商業的形態，改變了人與人溝通的方式，讓任何人在任何時間、任何地點都可以輕鬆獲取自己所需的服務。IT 系統需要能夠應對網際網路規模的快速增長，並且能夠快速迭代、低成本試錯。以 Netflix、阿里為代表的一系列網際網路公司推動了新一代應用架構的變革，Spring Cloud、Apache Dubbo 等微服務架構應運而生。微服務架構解決了傳統單體式應用存在的幾個問題：每個服務可以獨立部署和交付，大大提升了業務敏捷性；每個服務可以獨立橫向擴容，應對網際網路規模的挑戰。與傳統單體應用相比，分散式的微服務架構具備更快的迭代速度、更低的開發複雜性和更好的可擴充套件性。但同時，它的部署和運維的複雜性卻大大增加。我們需要如何應對？此外，“脈衝”計算成為常態。比如雙十一大促期間，零點需要的算力是平時的數十倍；一個突發的新聞事件，可能讓上千萬使用者湧向社交媒體。雲端計算無疑是處理突發流量洪峰的更加經濟、高效的方式。如何上好雲、用好雲、管好雲，如何讓應用可以更加充分利用基礎設施的彈性，成為企業運維團隊的關注重點。這些業務和技術挑戰也催生了雲原生的運維技術體系 – CloudOps。
標準化：標準化可以促進開發團隊與運維團隊的溝通和協同，標準化也有助於生態分工，推動更多自動化工具的出現。
自動化：只有自動化運維，才能支撐網際網路規模的挑戰，才能持續支撐業務的快速迭代與穩定性。
數智化：資料化、AI 增強的自動化運維成為未來發展的必然趨勢
在傳統的應用分發、部署過程中，常會由於缺乏標準導致工具碎片化，比如 Java 應用和 AI 應用的部署，需要完全不同的技術棧，交付效率低。此外，為了避免應用之間的環境衝突，我們經常需要將每個應用單獨部署在一個獨立的物理機或者虛擬機器上，這也造成了很多資源浪費。2013 年開源的容器技術 Docker 出現，開創性地提出了基於容器映象的應用分發和交付方式，重塑了軟體開發、交付和運維的整個生命週期。
就像傳統的供應鏈體系為例，不管什麼樣的產品都是透過使用集裝箱來進行運輸，極大提升了物流效率，使得全球化的分工協同成為可能。容器映象將應用和其依賴的應用環境一同打包。映象可以透過映象倉庫進行分發，可以一致的方式執行在開發、測試和生產環境中。容器技術是一種輕量化 OS 虛擬化能力，可以提升應用部署密度，最佳化資源利用率，與傳統的虛擬化技術相比，更加敏捷、輕量，具備更好的彈性和可移植性。容器作為雲時代的“應用集裝箱”，重塑了整個軟體供應鏈，也開啟了雲原生技術浪潮。
在傳統的軟體部署和變更過程中，經常會出現因為環境間的差異導致應用出現不可用的問題。比如，新版本應用需要依賴 JDK11 的能力，而如果部署環境中沒有更新 JDK 版本，就會導致應用失敗。“It works on my machine”也成了開發人員打趣的口頭禪。而且隨著時間的推移，系統的配置已經不可考，採用原地升級的方式在變更的時候一不留神就會掉進坑裡。不可變基礎設施（Immutable Infrastructure）是由 Chad Fowler 於 2013 年提出的一個理念，其核心思想是“任何基礎設施例項一旦建立，就變成為只讀狀態，如需要修改和升級，則使用新的例項進行替換。”這種模式可以減少配置管理的複雜性，確保系統配置變更可以可靠地、重複地執行。而且一旦部署出錯時可進行快速回滾。Docker 和 Kubernetes 容器技術正是實現 Immutable Infrastructure 模式的最佳方式。當我們為容器應用更新一個映象版本的時候，Kubernetes 會新建立一個容器，並且透過負載均衡將新請求路由到新容器，然後銷燬老容器，這避免了令人頭疼的配置漂移問題。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 儲存外掛等等，可以對上層業務應用遮蔽基礎設施差異。
Kubernetes 的成功背後的魔法就是控制迴圈，Kubernetes 有幾個簡單的概念。
首先，一切都是資源，透過控制器對資源進行自動化管理。使用者可以宣告資源的目標狀態。當控制器發現資源當前狀態與目標狀態存在不一致，就會持續調整，讓資源狀態趨近於目標狀態。透過這個方法，可以統一處理各種情況，比如，根據調整應用副本數進行擴縮容，或者節點當機後應用自動遷移，等等。正因如此，Kubernetes 支援資源範圍已經遠超容器應用。比如服務網格，可以對應用通訊流量進行宣告式管理；Crossplane 可以利用 K8s CRD 對 ECS，OSS 等雲資源進行管理和抽象。
K8s 控制器 “把複雜留給自己，把簡單交給使用者”的理想非常美好，然而實現一個高效、健壯的控制器卻充滿技術挑戰。OpenKruise 是阿里雲開源的雲原生應用自動化管理引擎，也是捐獻到 Cloud Native Computing Foundation (CNCF) 下的沙箱專案。它來自阿里巴巴多年來容器化、雲原生的技術沉澱，解決容器應用在大規模生產環境的自動化和穩定性挑戰。
OpenKruise 提供了增強的應用灰度釋出，穩定性防護，Sidecar 容器擴充套件等多種能力。OpenKruise 開源實現和集團內部版本程式碼保持一致。支撐了阿里集團應用 100%雲原生化，也已經在蘇寧、OPPO、小米、Lyft 等企業得到廣泛應用。歡迎大家社群共建和使用反饋。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 開源社群也在不斷完善相關的工具和最佳實踐，大家可以關注相關進展。
分散式系統存在高度複雜性，在應用、基礎設施、部署過程中任何一個地方的問題，都可能導致業務系統的故障。面對這樣的不確定性風險，我們有兩種做法：一種是“聽天由命”，信佛祖，不當機；一種是透過系統化的方法進行主動出擊，提升系統的確定性。2012 年，Netflix 提出了“混沌工程”的理念，透過主動注入故障的方式，提前發現系統的薄弱環節，推進架構的改進，最終實現業務韌性。我們可以將混沌工程的工作方式比作疫苗，透過“接種滅活疫苗”的方式，讓我們的免疫系統受到鍛鍊，具備抵擋 “疾病” 的能力。阿里雙十一購物節的順利成功，離不開全鏈路壓測等對混沌工程的大規模實踐，為此阿里團隊在這個領域積累了豐富的實戰經驗。
ChaosBlade 是一組遵循混沌工程理念的實驗工具，具有場景豐富、簡單易用等特點，已經成為 CNCF 沙箱專案。它支援 Linux、Kubernetes、Docker 等不同執行環境，以及 Java、NodeJS、C++、Golang 等多種語言。內建了 200 多個場景的測試方案。
chaosblade-box 是新引入的混沌工程控制檯，可實現實驗環境平臺化管理，進一步簡化使用者體驗，降低使用門檻。歡迎大家加入 Chaosblade 社群共建，也可以使用阿里雲應用高可用服務 AHAS 雲服務。最後我將結合阿里實踐，介紹我們在 CloudOps 上的一些探索。在傳統組織中，開發和運維角色是嚴格分開的。而不同業務線也構建了一個一個的煙囪化架構，從基礎設施環境與運維，到應用運維與開發，都是獨立的團隊，缺乏良好的協同與複用。
首先，公共雲、專有云成為了不同業務部門間共享的基礎設施。然後，SRE （Site ReliabilityEngineering）理念開始得到廣泛接受。是透過軟體和自動化手段，來解決系統的運維複雜性和穩定性問題。由於 Kubernetes 的標準化、可擴充套件性和可移植性等優勢，越來越多企業的SRE團隊基於 K8s 管理雲環境，極大提升了企業運維效率與資源效率。在此之上，平臺工程團隊開始浮現，基於 Kubernetes 構建企業的 PaaS 平臺和 CI/CD 流程，支援中介軟體和不同業務部門的應用部署與運維。提升企業的標準化和自動化水平，進一步提升應用研發、交付效率。這樣的分層結構中，向下的團隊更多是透過 SLO 驅動，從而讓上層系統對底層依賴技術具備更好的可預期性。越向上的團隊更多是業務驅動，更好地支撐業務發展。
阿里雲容器服務 SRE 團隊一直也在踐行 CloudOps 的最佳實踐，簡單總結如下：
第一項是全域性穩定性架構設計，讓整個平臺防範與未然：第二項是建設穩定性應急體系，也就是我們日常所說的 1-5-10 快恢能力，它包含：
雲原生已經成為勢不可擋的技術趨勢。Gartner 預測到 2025 年，95%數字化運維將透過雲原生平臺進行支撐。
我們可以根據企業能力和業務目標選擇合適的遷雲之路，大致可以分為幾個階段：從 Rehost、Re-platform 到 Re-architect，我們可以看到遷移的複雜性和所需技能在增加，但是敏捷性、彈性、可用性、容錯性等收益也在持續增加。阿里集團上雲也經歷了這樣的歷程，在去年業務 100%上公共雲的基礎之上，今年實現了應用 100%雲原生化。幫助阿里業務的研發效率提升了 20%，資源利用率提升了 30%。
最後做一個快速總結。基於容器、Kubernetes 等雲原生技術，提供的開放社群標準、不可變基礎設施、宣告式 API 會成為企業 CloudOps 的最佳實踐，也將在這個基礎上推進資料化、智慧化體系建設，將運維複雜性進一步下沉，讓企業可以聚焦於自己的業務創新。阿里雲也將持續向外輸出自身在超大規模雲原生實踐和探索中的能力沉澱，與更多企業、開發者一起，躬身入局，全面擁抱雲原生運維技術體系。
RocketMQ Streams：將輕量級實時計算引擎融合進訊息系統
Sealer-把Kubernetes看成作業系統叢集維度的Docker
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69972138/viewspace-2849010/，如需轉載，請註明出處，否則將追究法律責任。
