![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/e402cb7f83d04f7bb5fc6baec2c929a2.png)

作者 | 守辰、志敏
**來源|**[**阿里巴巴雲原生公眾號**](https://mp.weixin.qq.com/s/5tHgy80YlOFMtMN-T-0olQ)

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 層避免直接訪問容器服務來實現相關功能。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/dfa418293bb14079b2ff1d36a9fc1901.png)

### 2）分化而治之

“分化而治之”是指要對業務做出合理的劃分，避免因為所有業務和應用都集中在少數幾個名稱空間中，導致容器服務管控（控制器和 APIServer）在查詢名稱空間下所有資源時產生過大消耗的情況。目前在阿里內部最廣泛的實踐方式是使用“應用名”做為名稱空間。一方面應用是業務交付的基本單位，且不受組織調整的影響；另一方面，容器服務的元件以及業務自己的 Operator，在處理時往往會 list 名稱空間下的資源，而名稱空間預設在控制器和 APIServer 中都實現有索引，如果使用應用作為名稱空間可以利用預設的索引加速查詢操作。

### 3）苦修內外功

對於容器服務的核心管控，需要紮實的內功做基礎。針對大規模的使用場景，阿里雲的容器服務進行了大量的元件最佳化，比如透過索引、Watch 書籤等的方式，避免直接穿透 APIServer 訪問底層儲存 ETCD，並透過最佳化 ETCD 空閒頁面分配演算法、分離 event 和 lease 儲存至獨立 ETCD 的方法，提升 ETCD 本身的儲存能力，其中不少已經反饋給了社群，極大降低了 ETCD 處理讀請求的壓力。 詳情可檢視：[https://4m.cn/JsXsU](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 欄位來控制分批），如下圖。然而，每批暫停的方式往往因為應用每批中個別機器的問題而產生卡單的問題，嚴重影響釋出效率。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/a21467688465444081e2b76b3bff2984.png)

因此推薦使用流式釋出的配置：

```
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，引起故障。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/f548179d8dfd471bb5690c7ff62aed54.png)

另外， 對於業務執行依賴的如日誌上傳、微服務呼叫、安全審計等基礎設功能，需要進行資源的隔離。因此，阿里在對應用進行大量的輕量化容器改造過程中，採取了把基礎設施功能從應用的富容器中剝離到 Sidecar 或者 Daemonset 中的方式，並對 Sidecar 或者 Daemon 的容器進行資源的隔離， 保證即使基礎設施功能發生記憶體洩露等異常也不會直接影響業務的正常執行。

### 2）預設穩定性

指保證所有應用都具備基本的穩定性保障配置，包括預設的排程打散策略、Pod 中斷預算、應用負載釋出最大不可用數量，讓穩定性成為像水、電、煤一樣的基礎設施。這樣能夠避免應用因為宿主機故障、運維操作、應用釋出操作導致服務的完全不可用。保障可以透過 webhook 或者透過全域性的應用交付模板來實現，應用 PaaS 也可以根據業務的實際要求來定製。

### 3）規範化應用

在進行雲原生改造時，需要制定啟停指令碼、可用和探活探針規範，幫助業務把自愈能力內建到應用中去。這包括推動應用配置相應的存活探針，保證應用在異常退出後能夠被自動拉起；保證應用啟動和退出時執行優雅上下線的操作等。配合這些規範，還需要設定相關探針的准入、監測機制，防止業務研發同學在對 K8s 機制不完全瞭解的情況下編寫錯誤的探針。我們常常見到很多研發同學直接複用已有的健康檢查指令碼來作為探活探針，但是這些指令碼往往存在呼叫開銷大（例如執行了解壓縮）、存在副作用（例如會修改業務流量開啟狀態）、以及執行不穩定（例如呼叫涉及下游服務）的問題，這些對業務的正常執行都會產生非常大的干擾，甚至引發故障。

### 4）集中化處理

對於探活失敗的自動重啟、問題節點的驅逐操作， 阿里雲容器服務把 Kubelet 自主執行的自愈操作，改為了中心控制器集中觸發，從而可以利用應用級別的可用度資料實現限流、熔斷等安全防護措施。這樣，即使發生了業務錯配探活指令碼或者運維誤操作執行批次驅逐等操作狀況，業務同樣能得到保護；而在大促峰值等特殊的業務場景下，可以針對具體需求設計相應的預案，關閉相應探活、重啟、驅逐等操作，避免在業務峰值時因為探活等活動引起應用資源使用的波動，保證業務短期的極致確定性要求。

### 5）變更三板斧

首先，要保證容器服務自身的變更可觀測、可灰度、可回滾。 對於 Controller 和 Webhook 這類的中心管控元件，一般可以透過叢集來進行灰度，但如果涉及的改動風險過大，甚至還需要進行 Namespace 級別細粒度的灰度；由於阿里部分容器服務是在節點上或者 Pod 的 Sidecar 中執行的，而官方 K8s 中欠缺對於節點上 Pod 和Sidecar 中容器的灰度釋出支援，因此阿里使用了 [OpenKruise](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495317&idx=1&sn=85d9543209ca83bd8d94a1424f36b785&chksm=fae6e55acd916c4cbe684012220b3b39b4b24ab18c78b57c17eccbafca6617cdd21682716f2c&scene=21#wechat_redirect) 中的 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 等專案，像搭積木一樣在雲上打造眾多企業自有的大規模容器平臺。

更多企業落地實踐內容，可[下載雲原生架構白皮書瞭解詳情](https://developer.aliyun.com/topic/cn-architecture-paper)！

「更高更快更穩」，看阿里巴巴如何修煉容器服務「內外功」

相關文章