作者 | 守辰、志敏
來源|
阿裡巴巴雲原生公衆号11 月 11 日零點剛過 26 秒，阿裡雲再一次抗住了全球最大的流量洪峰。今年 雙11 是阿裡經濟體核心系統全面雲原生化的一年，相比去年核心系統的上雲，雲原生化不僅讓阿裡享受到了雲計算技術成本優化的紅利，也讓阿裡的業務最大化獲得雲的彈性、效率和穩定性等價值。
為應對 雙11，阿裡雲原生面臨怎樣的挑戰？
為了支援阿裡這樣大規模業務的雲原生化，阿裡雲原生面臨怎麼樣的挑戰呢？
1. 叢集多、規模大
基于對業務穩定性和系統性能等方面的綜合考慮，大型企業往往需要将業務叢集部署到多個地域，在這樣的場景下，支撐多叢集部署的容器服務能力非常必要。同時，為了簡化多叢集管理的複雜度，以及為不能實作跨叢集服務發現的業務提供支援，還需要關注容器服務中單個叢集對大規模節點的管理能力。另外，大型企業的業務複雜多樣，是以一個叢集内往往需要部署豐富的元件，不僅包括主要的 Master 元件， 還需要部署業務方定制的 Operator 等。叢集多、規模大，再加上單個叢集内元件衆多， 容器服務的性能、可擴充性、可運維性都面臨着很大的挑戰。
2. 變化快、難預期
市場瞬息萬變，企業，特别是網際網路企業，如果僅憑借經驗、依靠規劃來應對市場變化，越來越難以支撐業務發展，往往需要企業快速地進行業務疊代、部署調整以應對市場的變化。這對為業務提供應用傳遞快速支援、彈性伸縮性能和快速響應支撐的容器服務提出了很大的要求。
3. 變更多、風險大
企業 IT 系統的雲原生化過程不僅要面臨一次性的雲遷移和雲原生改造成本，還将持續應對由于業務疊代和基礎設施變更、人員流動帶來的風險。而業務的疊代、基礎設施的變更會無法避免地為系統引入缺陷，嚴重時甚至造成故障，影響業務正常運作。最後，這些風險都可能會随着人員的流動進一步加劇。
阿裡雲容器服務大規模實踐
1. 高擴充性
為了提高容器服務的可擴充性，需要自底向上、關聯應用和服務一起優化。
1）接口最小化
針對上層 PaaS，容器服務依托 OAM（Open Application Model） 和 OpenKruise Workload 提供了豐富的應用傳遞能力抽象。對于 PaaS 層來說，隻需要讀取彙總的應用部署統計數值即可，極大減少了上層系統需要批量查詢 pod、event 等資訊的工作量，進而減小了對容器服務的管控壓力；同時，通過把數量多、占用空間大的 pod 及 events 資訊轉存到資料庫中， 并根據資料庫中的内容提供一個統一的、可内嵌的部署狀态檢視和診斷頁面的方式，可以使 PaaS 層避免直接通路容器服務來實作相關功能。
2）分化而治之
“分化而治之”是指要對業務做出合理的劃分，避免因為所有業務和應用都集中在少數幾個命名空間中，導緻容器服務管控（控制器和 APIServer）在查詢命名空間下所有資源時産生過大消耗的情況。目前在阿裡内部最廣泛的實踐方式是使用“應用名”做為命名空間。一方面應用是業務傳遞的基本機關，且不受組織調整的影響；另一方面，容器服務的元件以及業務自己的 Operator，在處理時往往會 list 命名空間下的資源，而命名空間預設在控制器和 APIServer 中都實作有索引，如果使用應用作為命名空間可以利用預設的索引加速查詢操作。
3）苦修内外功
對于容器服務的核心管控，需要紮實的内功做基礎。針對大規模的使用場景，阿裡雲的容器服務進行了大量的元件優化，比如通過索引、Watch 書簽等的方式，避免直接穿透 APIServer 通路底層存儲 ETCD，并通過優化 ETCD 空閑頁面配置設定算法、分離 event 和 lease 存儲至獨立 ETCD 的方法，提升 ETCD 本身的存儲能力，其中不少已經回報給了社群，極大降低了 ETCD 處理讀請求的壓力。 詳情可檢視：
https://4m.cn/JsXsU。
其次，對于核心管控本身，要做好保護的外功。特别是安全防護，需要在平時就做好預案，并且常态化地執行演練。例如， 對于容器服務 APIServer， 需要保證任何時候的 APIServer 都能保持可用性。 除了常見的 HA 方案外， 還需要保證 APIServer 不受異常的 operator 和 daemonset 等元件的影響。為了保證 APIServer 的魯棒性，可以利用官方提供的 max-requests-inflight 和 max-mutating-requests-inflight 來實作， 在緊急情況下阿裡雲還提供了動态修改 infight 值配置的功能，友善在緊急情況下不需要重新開機 APIServer 就可以應用新的配置進行限流。
對于最核心的 ETCD，要做好資料的備份。考慮到資料備份的及時性，不僅要進行資料定期的冷備，還需要實時地進行資料的異地熱備，并常态化地執行資料備份、灰階的演練，保證可用性。
2. 快速
在應對業務變化多、基礎設施變化多帶來的不可預期問題，可采取以下方式。
1）負載自動化
為了高效地進行應用傳遞，研發需要權衡傳遞效率和業務穩定性。阿裡大規模地使用 OpenKruise 進行應用的傳遞，其中 cloneset 覆寫了阿裡上百萬的容器。 在 cloneset 中可以通過 partition 來控制暫停釋出進而進行業務觀察，通過 maxunavailable 來控制釋出的并發度。通過綜合設定 partition 和 maxunavailable 可以實作複雜的釋出政策。實際上，大多數情況下 PaaS 層在設計分批釋出的功能時，往往選取了每批暫停的方式（僅通過 cloneset partition 字段來控制分批），如下圖。然而，每批暫停的方式往往因為應用每批中個别機器的問題而産生卡單的問題，嚴重影響釋出效率。
是以推薦使用流式釋出的配置：
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
updateStrategy:
# 首批partition設定， 非首批置0
partition: 0
# 控制釋出的并發度， 實作為1/分批數
maxUnavailable: 20% 2）以快制動
為了應對突發的業務流量， 需要能夠快速的進行應用的部署，并從多方面保障緊急場景的快速擴容。
一方面，通過推進業務使用方的 CPUShare 化，讓應用能夠原地利用節點額外計算資源，進而給緊急擴容争取更多的反應時間。
其次，通過鏡像預熱的方式來預熱基礎鏡像，通過 P2P 和 CDN 的技術加速大規模的鏡像分發，通過按需下載下傳容器啟動實際需要的鏡像資料，使業務鏡像下載下傳時間極大地降低。
3）打好提前量
俗話說，"不打無準備之仗" 。要實作高效率的部署，做好準備是必需的。
首先是對于資源的準備， 如果叢集内沒有為服務準備好一定的容量，或者沒有為叢集準備好額外節點額度的話，就無法在必要時實作彈性。因為阿裡不同業務有着不同的流量峰值，我們會結合實際情況定期對部分業務縮容，并對另外一種業務進行擴容的方式實作計劃資源的伸縮。
當然，尋找這樣可以比對較好的業務組會比較困難，對于采用函數等 Serverless 形态的應用， 阿裡建構一個公共預擴容的 Pod 池，使得不同業務緊急擴容時能夠完全規避排程、網絡和儲存的開銷， 達到極緻的擴容速度。
3. 穩定
為了確定使用容器服務的業務穩定，阿裡在具體實踐中遵循了以下幾個原則。
1）信任最小化
俗話說，"常在河邊走，哪有不濕鞋"。為了確定頻繁進行叢集運維工作的同學不因為疏忽而犯錯，就要保證業務可操作的權限最小化，對于授權的寫和删除操作，還要增加額外的保護。近一步來講，為了防止容器服務使用者的誤操作，我們對 Namespace、CRD 和 Workload 的資源都增加了級聯删除的保護，避免使用者因為誤删除還在運作 Pod 的 Namespace、CRD 和 Workload 而引發災難性的後果。下圖展示了删除一個 CRD 可能造成的級聯删除故障，實際應用中，許多 operator 中都會設定 CR 為關聯 Workload 的 Owner， 是以一旦删除了 CRD（例如非預期的 Operator 更新操作），極有可能會導緻級聯删除關聯的所有 Pod，引起故障。
另外， 對于業務運作依賴的如日志上傳、微服務調用、安全審計等基礎設功能，需要進行資源的隔離。是以，阿裡在對應用進行大量的輕量化容器改造過程中，采取了把基礎設施功能從應用的富容器中剝離到 Sidecar 或者 Daemonset 中的方式，并對 Sidecar 或者 Daemon 的容器進行資源的隔離， 保證即使基礎設施功能發生記憶體洩露等異常也不會直接影響業務的正常運作。
2）預設穩定性
指保證所有應用都具備基本的穩定性保障配置，包括預設的排程打散政策、Pod 中斷預算、應用負載釋出最大不可用數量，讓穩定性成為像水、電、煤一樣的基礎設施。這樣能夠避免應用因為主控端故障、運維操作、應用釋出操作導緻服務的完全不可用。保障可以通過 webhook 或者通過全局的應用傳遞模闆來實作，應用 PaaS 也可以根據業務的實際要求來定制。
3）規範化應用
在進行雲原生改造時，需要制定啟停腳本、可用和探活探針規範，幫助業務把自愈能力内置到應用中去。這包括推動應用配置相應的存活探針，保證應用在異常退出後能夠被自動拉起；保證應用啟動和退出時執行優雅上下線的操作等。配合這些規範，還需要設定相關探針的準入、監測機制，防止業務研發同學在對 K8s 機制不完全了解的情況下編寫錯誤的探針。我們常常見到很多研發同學直接複用已有的健康檢查腳本來作為探活探針，但是這些腳本往往存在調用開銷大（例如執行了解壓縮）、存在副作用（例如會修改業務流量開啟狀态）、以及執行不穩定（例如調用涉及下遊服務）的問題，這些對業務的正常運作都會産生非常大的幹擾，甚至引發故障。
4）集中化處理
對于探活失敗的自動重新開機、問題節點的驅逐操作， 阿裡雲容器服務把 Kubelet 自主執行的自愈操作，改為了中心控制器集中觸發，進而可以利用應用級别的可用度資料實作限流、熔斷等安全防護措施。這樣，即使發生了業務錯配探活腳本或者運維誤操作執行批量驅逐等操作狀況，業務同樣能得到保護；而在大促峰值等特殊的業務場景下，可以針對具體需求設計相應的預案，關閉相應探活、重新開機、驅逐等操作，避免在業務峰值時因為探活等活動引起應用資源使用的波動，保證業務短期的極緻确定性要求。
5）變更三闆斧
首先，要保證容器服務自身的變更可觀測、可灰階、可復原。 對于 Controller 和 Webhook 這類的中心管控元件，一般可以通過叢集來進行灰階，但如果涉及的改動風險過大，甚至還需要進行 Namespace 級别細粒度的灰階；由于阿裡部分容器服務是在節點上或者 Pod 的 Sidecar 中運作的，而官方 K8s 中欠缺對于節點上 Pod 和Sidecar 中容器的灰階釋出支援，是以阿裡使用了
OpenKruise中的 Advance Daemonset 和 Sidecarset 來執行相關的釋出。
使用阿裡雲容器服務輕松建構大規模容器平台
阿裡雲容器服務 ACK（Alibaba Cloud Container Service for Kubernetes）是全球首批通過 Kubernetes 一緻性認證的服務平台，提供高性能的容器應用管理服務，支援企業級 Kubernetes 容器化應用的生命周期管理。ACK 在阿裡集團内作為核心的容器化基礎設施，有豐富的應用場景和經驗積累，包括電商、實時音視訊、資料庫、消息中間件、人工智能等場景，支撐廣泛的内外部客戶參加 雙11 活動；同時，容器服務将阿裡内部各種大規模場景的經驗和能力融入産品，向公有雲客戶開放，提升了更加豐富的功能和更加突出的穩定性，容器服務連續多年保持國内容器市場佔有率第一。
在過去的一年，ACK 進行了積極的技術更新，針對阿裡的大規模實踐和企業的豐富生産實踐，進一步增強了可靠性、安全性，并且提供可賠付的 SLA 的 Kubernetes 叢集 - ACKPro 版。ACK Pro 版叢集是在原 ACK 托管版叢集的基礎上發展而來的叢集類型，繼承了原托管版叢集的所有優勢，例如 Master 節點托管、Master 節點高可用等。同時，相比原托管版進一步提升了叢集的可靠性、安全性和排程性能，并且支援賠付标準的 SLA，适合生産環境下有着大規模業務，對穩定性和安全性有高要求的企業客戶。
9 月底，阿裡雲成為率先通過信通院容器規模化性能測試的雲服務商，獲得最進階别認證—“卓越”級别，并首先成功實作以單叢集 1 萬節點 1 百萬 Pod 的規模突破，建構了國内最大規模容器叢集，引領國内容器落地的技術風向标。此次測評範圍涉及：資源排程效率、滿負載壓力測試、長穩測試、擴充效率測試、網絡存儲性能測試、采集效率測試等，客觀真實反映容器叢集元件級的性能表現。目前開源版本 Kubernetes 最多可以支撐 5 千節點及 15 萬 Pod，已經無法滿足日益增長的業務需求。作為雲原生領域的實踐者和引領者，阿裡雲基于服務百萬客戶的經驗，從多個次元對 Kubernetes 叢集進行優化，率先實作了單叢集 1 萬節點 1 百萬 Pod 的規模突破，可幫助企業輕松應對不斷增加的規模化需求。
在應用管理領域，OpenKruise 項目已經正式成為了 CNCF 沙箱項目。OpenKruise 的開源也使得每一位 Kubernetes 開發者和阿裡雲上的使用者，都能便捷地使用阿裡内部雲原生應用統一的部署釋出能力。阿裡通過将 OpenKruise 打造為一個 Kubernetes 之上面向大規模應用場景的通用擴充引擎，當社群使用者或外部企業遇到了 K8s 原生 Workload 不滿足的困境時，不需要每個企業内部重複造一套相似的“輪子”，而是可以選擇複用 OpenKruise 的成熟能力。阿裡集團内部自己 OpenKruise；而更多來自社群的需求場景輸入，以及每一位參與 OpenKruise 建設的雲原生愛好者，共同打造了這個更完善、普适的雲原生應用負載引擎。
在應用制品管理領域，面向安全及性能需求高的企業客戶，阿裡雲推出容器鏡像服務企業版 ACR EE，提供公共雲首個獨享執行個體的企業級服務。ACR EE 除了支援多架構容器鏡像，還支援多版本 Helm Chart、Operator 等符合 OCI 規範制品的托管。在安全治理部分，ACR EE 提供了網絡通路控制、安全掃描、鏡像加簽、安全審計等多元度安全保障，助力企業從 DevOps 到 DevSecOps 的更新。在全球分發加速場景，ACR EE 優化了網絡鍊路及排程政策，保障穩定的跨海同步成功率。在大鏡像規模化分發場景，ACR EE 支援按需加載，實作鏡像資料免全量下載下傳和線上解壓，平均容器啟動時間降低 60%，提升 3 倍應用分發效率。目前已有衆多企業生産環境模使用 ACR EE，保障企業客戶雲原生應用制品的安全托管及多場景高效分發。
我們希望，阿裡雲上的開發者可以自由組合雲上的容器産品家族，通過 ACK Pro+ACR EE+OpenKruise 等項目，像搭積木一樣在雲上打造衆多企業自有的大規模容器平台。
更多企業落地實踐内容，可
下載下傳雲原生架構白皮書了解詳情！