作者 | 守辰、志敏
來源|阿里巴巴云原生公眾號

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設置， 非首批置0partition: 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 優化了網絡鏈路及調度策略，保障穩定的跨海同步成功率。在大鏡像規?；职l場景，ACR EE 支持按需加載，實現鏡像數據免全量下載和在線解壓，平均容器啟動時間降低 60%，提升 3 倍應用分發效率。目前已有眾多企業生產環境模使用 ACR EE，保障企業客戶云原生應用制品的安全托管及多場景高效分發。

我們希望，阿里云上的開發者可以自由組合云上的容器產品家族，通過 ACK Pro+ACR EE+OpenKruise 等項目，像搭積木一樣在云上打造眾多企業自有的大規模容器平臺。

更多企業落地實踐內容，可下載云原生架構白皮書了解詳情！

總結

以上是生活随笔為你收集整理的「更高更快更稳」，看阿里巴巴如何修炼容器服务「内外功」的全部內容，希望文章能夠幫你解決所遇到的問題。

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