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

作者 | 易立 阿里雲資深技術專家

> **導讀**：Kubernetes 已經成為企業新一代雲 IT 架構的重要基礎設施，但是在企業部署和運維 Kubernetes 叢集的過程中，依然充滿了**複雜性和困擾**。

阿里雲容器服務自從 2015 年上線後，目前**託管著上萬的 K8s 叢集**來支撐全球各地的客戶。我們對客戶在規劃叢集過程中經常會遇見的問題，進行一些分析解答。試圖緩解大家的“**選擇恐懼症**”。

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

# 如何選擇 Worker 節點例項規格？

## 裸金屬還是虛擬機器？
在 Dimanti 2019 年的容器調查報告中，對專有云使用者選擇裸金屬伺服器來執行容器的主要原因進行了分析。

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

1. 選擇裸金屬伺服器的最主要原因（**超過 55%**）是：傳統虛擬化技術 I/O 損耗較大；對於 I/O 密集型應用，裸金屬相比傳統虛擬機器有更好的效能表現；

2. **此外近 36% 的客戶認為：裸金屬伺服器可以降低成本**。大多數企業在初始階段採用將容器執行在虛擬機器的方案，但是當大規模生產部署的時候，客戶希望直接執行在裸金屬伺服器上來減少虛擬化技術的 license 成本（這也常被戲稱為“VMWare 稅”）；

3. **還有近 30% 的客戶因為在物理機上部署有更少的額外資源開銷**（如虛擬化管理、虛擬機器作業系統等）；還有近 24% 的客戶選擇的原因是：可以有更高的部署密度，從而降低基礎設施成本；

4. **超過 28% 的客戶認為，在物理機上可以更加靈活地選擇網路、儲存等裝置和軟體應用生態。**

在公共雲上，我們應該如何選擇呢？2017 年 10 月，阿里雲“神龍架構”橫空出世。彈性裸金屬伺服器（ECS Bare Metal Instance）是一款同時兼具虛擬機器彈性和物理機效能及特性的新型計算類產品，實現超強超穩的計算能力，無任何虛擬化開銷。阿里雲 2019 年 8 月重磅釋出了彈性計算第六代企業級例項，基於神龍架構對虛擬化能力進行了全面升級。

- 基於阿里自研神龍晶片和全新的輕量化 Hypervisor - 極大減少虛擬化效能開銷。基於阿里雲智慧神龍晶片和全新的輕量化 VMM，將大量傳統虛擬化功能解除安裝到專用硬體上，大大降低了虛擬化的效能開銷，同時使用者幾乎可以獲得所有的宿主機 CPU 和記憶體資源，提高整機和大規格例項的各項能力，尤其是 I/O 效能有了大幅度提升；

- 使用最新第二代英特爾至強可擴充套件處理器 - E2E 效能提升。使用最新一代 Intel Cascade Lake CPU, 突發主頻提升至 3.2GHz, 各場景 E2E 效能大幅提升，並在深度學習的多種場景有數倍的提升；

- 給企業級場景帶來穩定和可預期的表現 - 全球最高水準 SLA。針對軟硬體最佳化以及更加實施更細緻的 QoS 手段，給企業級客戶的負載提供更穩定可預期的效能。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/25a318535b6146b7b5ab87f518045db1.png)
![4.png](https://ucc.alicdn.com/pic/developer-ecology/6f4f3bca6cf848eba15bffc5d792f4b4.png)

一般而言建議：

- 對效能極其敏感的應用，如高效能運算，裸金屬例項是較好的選擇；
- 如果需要 Intel SGX，或者安全沙箱等技術，裸金屬例項是不二選擇；
- 六代虛擬機器例項基於神龍架構，I/O 效能有了顯著提升，同時有更加豐富的規格配置，可以針對自身應用需求靈活選擇，降低資源成本；
- 虛擬機器例項支援熱遷移，可以有效降低運維成本。

阿里雲 ACK K8s 叢集支援多個節點伸縮組（AutoScalingGroup），不同彈性伸縮組支援不同的例項規格。在工作實踐，我們會為 K8s 叢集劃分靜態資源池和彈性資源池。通常而言，固定資源池可以根據需要選擇裸金屬或者虛擬機器例項。彈性資源池建議根據應用負載使用合適規格的虛擬機器例項來最佳化成本、避免浪費，提升彈性供給保障。此外由於裸金屬例項一般 CPU 核數非常多，大規格例項在使用中的挑戰請參見下文。

## 較少的大規格例項還是較多的小規格例項？

一個引申的問題是，如何選擇例項規格？我們列表對比一下：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/6033fc9c3bc74e7088599ea1d3a2f79a.png)

預設情況下，kubelet 使用 CFS 配額 來執行 pod 的 CPU 約束。當節點上執行了很多 CPU 密集的應用時，工作負載可能會遷移到不同的 CPU 核，工作負載的會受到 CPU 快取親和性以及排程延遲的影響。當使用大規格例項型別時，節點的 CPU 數量較多，現有的 Java，Golang 等應用在多 CPU 共享的場景，效能會出現明顯下降。所有對於大規格例項，需要對 CPU 管理策略進行配置，利用 CPU set 進行資源分配。

此外一個重要的考慮因素就是 NUMA 支援。在 NUMA 開啟的裸金屬例項或者大規格例項上，如果處理不當，記憶體訪問吞吐可能會比最佳化方式降低了 30%。Topology 管理器可以開啟 NUMA 感知 。但是目前 K8s 對 NUMA 的支援比較簡單，還無法充分發揮 NUMA 的效能。

[https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/](https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/)

阿里雲容器服務提供了 CGroup Controller 可以更加靈活地對 NUMA 架構進行排程和重排程。

# 如何容器執行時?

## Docker 容器還是安全沙箱？
在 Sysdig 釋出的 2019 容器使用報告中，我們可以看到 Docker 容器佔據市場規模最大的容器執行時 （79%），containerd 是 Docker 貢獻給 CNCF 社群的開源容器執行時，現在也佔據了一席之地，並且得到了廠商的廣泛支援；cri-o 是紅帽公司推出的支援 OCI 規範的面向 K8s 的輕量容器執行時，目前還處在初級階段。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/06195af4c7df4465b3822e9fc4949017.png)

很多同學都關心 containerd 與 Docker 的關係，以及是否 containerd 可以取代 Docker？Docker Engine 底層的容器生命週期管理也是基於 containerd 實現。但是 Docker Engine 包含了更多的開發者工具鏈，比如映象構建。也包含了 Docker 自己的日誌、儲存、網路、Swarm 編排等能力。此外，絕大多數容器生態廠商，如安全、監控、日誌、開發等對 Docker Engine 的支援比較完善，對 containerd 的支援也在逐漸補齊。

所以在 Kubernetes 執行時環境，對安全和效率和定製化更加關注的使用者可以選擇 containerd 作為容器執行時環境。對於大多數開發者，繼續使用 Docker Engine 作為容器執行時也是一個不錯的選擇。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/92463ceaa155410f8d916df21009bd73.png)

此外，傳統的 Docker RunC 容器與宿主機 Linux 共享核心，透過 CGroup 和 namespace 實現資源隔離。但是由於作業系統核心的攻擊面比較大，一旦惡意容器利用核心漏洞，可以影響整個宿主機上所有的容器。

越來越多企業客戶關注容器的安全性，為了提升安全隔離，阿里雲和螞蟻金服團隊合作，引入安全沙箱容器技術。19 年 9 月份我們釋出了基於輕量虛擬化技術的 RunV 安全沙箱。相比於 RunC 容器，每個 RunV 容器具有獨立核心，即使容器所屬核心被攻破，也不會影響其他容器，非常適合執行來自第三方不可信應用或者在多租戶場景下進行更好的安全隔離。

阿里雲安全沙箱容器有大量效能最佳化，可以達到 90% 的原生 RunC 效能：

- 利用 Terway CNI 網路外掛，網路效能無損；
- 利用 DeviceMapper 構建了⾼速、穩定的容器 Graph Driver；
- 最佳化 FlexVolume 和 CSI Plugin，把 mount bind 的動作下沉到沙箱容器內，從而避開了 9pfs 帶來的效能損耗。

而且，ACK 為安全沙箱容器和和 RunC 容器提供了完全一致的使用者體驗，包括日誌、監控、彈性等。同時，ACK 可以在一臺神龍裸金屬例項上同時混布 RunC 和 RunV 容器，使用者可以根據自己的業務特性自主選擇。

![8.jpeg](https://ucc.alicdn.com/pic/developer-ecology/560651f0fc854e6195c489fa3dada4a3.jpeg)

同時，我們也要看到安全沙箱容器還有一些侷限性，現有很多日誌、監控、安全等工具對獨立核心的安全沙箱支援不好，需要作為 sidecar 部署在安全沙箱內部。

對於使用者而言，如果需要多租戶隔離的場景，可以採用安全沙箱配合 network policy 來完成，當然也可以讓不同租戶的應用執行在不同的虛擬機器或者彈性容器例項上，利用虛擬化技術來進行隔離。

注意：安全沙箱目前只能執行在裸金屬例項上，當容器應用需要資源較少時成本比較高。可以參考下文的 Serverless K8s 有關內容。

# 如何規劃容器叢集？

## 一個大叢集還是一組小叢集？
在生產實踐中，大家經常問到的一個問題是我們公司應該選擇一個還是多個 Kubernetes 叢集。

Rob Hirschfeld 在 Twitter 上做了一個調查：

- 一個大一統的平臺，支援多種應用負載、環境和多租戶隔離；
- 或者，一組以應用為中心的小叢集，支援不同應用和環境的生命週期管理。

[https://thenewstack.io/the-optimal-kubernetes-cluster-size-lets-look-at-the-data/](https://thenewstack.io/the-optimal-kubernetes-cluster-size-lets-look-at-the-data/)

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

大多數的使用者選擇是後者，典型的場景是：

- 開發、測試環境使用不同的叢集
- 不同的部門使用不同的叢集進行隔離
- 不同的應用使用不同的叢集
- 不同版本的 K8s 叢集

在使用者反饋中，採用以多個小叢集的主要原因在於爆炸半徑比較小，可以有效提升系統的可用性。同時透過叢集也可以比較好地進行資源隔離。管理、運維複雜性的增加是採用多個小叢集的一個不足之處，但是在公共雲上利用託管的 K8s 服務（比如阿里雲的 ACK）建立和管理 K8s 叢集生命週期非常簡單，可以有效解決這個問題。

我們可以比較一下這兩種選擇：
![10.png](https://ucc.alicdn.com/pic/developer-ecology/d2ece263d1074782a5739f8b0c842c9b.png)

源自 Google Borg 的理念，Kubernetes 的願景是成為 Data Center Operating System，而且 Kubernetes 也提供了 RBAC、namespace 等管理能力，支援多使用者共享一個叢集，並實現資源限制。但是這些更多是 “軟多租” 能力，不能實現不同租戶之間的強隔離。在多租最佳實踐中，我們可以有如下的一些建議：

- 資料平面：可以透過 PSP (PodSecurityPolicy) 或者安全沙箱容器，提升容器的隔離性；利用 Network Policy 提升應用之間網路隔離性；可以透過將 nodes 和 namespace 繫結在一起，來提升 namespace 之間資源的隔離；

- 控制平面：Kubernetes 的控制平面包括 master 元件 API Server, Scheduler, etcd 等，系統 addon 如 CoreDNS, Ingress Controller 等，以及使用者的擴充套件，如 3 方的 CRD (Customer Resource Definition) controller。這些元件大多不具備良好的租戶之間的安全、資源和故障隔離能力。一個錯誤的 CRD contoller 實現有可能打掛一個叢集的 API Server。

關於 Kubernetes 多租戶實踐的具體資訊可以參考下文。目前而言，Kubernetes 對硬隔離的支援存在很多侷限性，同時社群也在積極探索一些方向，如阿里容器團隊的 Virtual Cluster Proposal 可以提升隔離的支援，但是這些技術還未成熟。

[https://www.infoq.cn/article/NyjadtOXDemzPWyRCtdm?spm=a2c6h.12873639.0.0.28373df9R7x2DP](https://www.infoq.cn/article/NyjadtOXDemzPWyRCtdm)

[https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster?spm=a2c6h.12873639.0.0.28373df9R7x2DP](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster)

另一個需要考慮的方案是 Kubernetes 自身的可擴充套件性，我們知道一個 Kubernetes 叢集的規模在保障穩定性的前提下受限於多個維度，一般而言 Kubernetes 叢集小於 5000 節點。當然，執行在阿里雲上還受限於雲產品的 quota 限制。阿里經濟體在 Kubernetes 規模化上有豐富的經驗，但是對於絕大多數客戶而言，是無法解決超大叢集的運維和定製化複雜性的。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/5659c8f503bb4eb3b8b596d9ed26ead5.png)

對於公共雲客戶我們一般建議，針對業務場景建議選擇合適的叢集規模：

- 對於跨地域（region）場景，採用多叢集策略，K8s 叢集不應跨地域。我們可以利用 CEN 將不同地域的 VPC 打通；
- 對於強隔離場景，採用多叢集策略，不同安全域的應用部署在不同的叢集上；
- 對於應用隔離場景，比如 SaaS 化應用，可以採用單叢集方式支援多租，並加強安全隔離；
- 對於多個大規模應用，可以採用多叢集策略，比如，線上應用、AI 訓練、實時計算等可以執行在不同的 K8s 叢集之上，一方面可以控制叢集規模，一方面可以針對應用負載選擇合適的節點規格和排程策略。

由於有 VPC 中節點、網路資源的限制，我們可以甚至將不同的 K8s 叢集分別部署在不同的 VPC，利用 CEN 實現網路打通，這部分需要對網路進行前期規劃。

- 如果需要對多個叢集的應用進行統一管理，有如下幾個考慮；
- 利用 Kubefed 構建叢集聯邦，ACK 對叢集聯邦的支援可以參考。

[https://help.aliyun.com/document_detail/121653.html?spm=a2c6h.12873639.0.0.28373df9R7x2DP](https://help.aliyun.com/document_detail/121653.html?spm=a2c6h.12873639.0.0.28373df9R7x2DP)

利用統一的配置管理中心，比如 GitOps 方式來管理和運維應用。

[https://github.com/fluxcd/flux?spm=a2c6h.12873639.0.0.28373df9R7x2DP](https://github.com/fluxcd/flux?spm=a2c6h.12873639.0.0.28373df9R7x2DP)

另外利用託管服務網格服務 ASM，可以利用 Istio 服務網格輕鬆實現對多個 K8s 叢集的應用的統一路由管理。

## 如何選擇 K8s 或者 Serverless K8s 叢集？
在所有的調查中，K8s 的複雜性和缺乏相應的技能是阻礙 K8s 企業所採用的主要問題，在 IDC 中運維一個 Kubernetes 生產叢集還是非常具有挑戰的任務。阿里雲的 Kubernetes 服務 ACK 簡化了 K8s 叢集的生命週期管理，託管了叢集的 master 節點被，但是使用者依然要維護 worker 節點，比如進行升級安全補丁等，並根據自己的使用情況進行容量規劃。

針對 K8s 的運維複雜性挑戰，阿里雲推出了 Serverless Kubernetes 容器服務 ASK。

完全相容現有 K8s 容器應用，但是所有容器基礎設施被阿里雲託管，使用者可以專注於自己的應用。它具備幾個特點：

1. 首先它按照容器應用實際消耗的資源付費，而不是按照預留的節點資源付費；
1. 對使用者而言沒有節點的概念，零維護；
1. 所有資源按需建立，無需任何容量規劃。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/61f98a87397743609148895f52fe3916.png)

在 ASK 中，應用執行在彈性容器例項 - ECI （Elastic Container Instance）中，ECI 基於輕量虛擬機器提供的沙箱環境實現應用安全隔離，並且完全相容 Kubernetes Pod 語義。在 ASK 中我們透過對 Kubernetes 做減法，將複雜性下沉到基礎設施，極大降低了運維管理負擔，提升使用者體驗，讓 Kubernetes 更簡單，讓開發者更加專注於應用自身。除了無需管理節點和 Master 外，我們將 DNS, Ingress 等能力透過阿里雲產品的原生能力來實現，提供了極簡但功能完備的 Kubernetes 應用執行環境。

Serverless Kubernetes 極大降低了管理複雜性，而且其自身設計非常適合突發類應用負載，如 CI/CD，批次計算等等。比如一個典型的線上教育客戶，根據教學需要按需部署教學應用，課程結束自動釋放資源，整體計算成本只有使用包月節點的 1/3。

在編排排程層，我們藉助了 CNCF 社群的 Virtual-Kubelet，並對其進行了深度擴充套件。Virtual-Kubelet 提供了一個抽象的控制器模型來模擬一個虛擬 Kubernetes 節點。當一個 Pod 被排程到虛擬節點上，控制器會利用 ECI 服務來建立一個 ECI 例項來執行 Pod。

我們還可以將虛擬節點加入 ACK K8s 叢集，允許使用者靈活控制應用部署在普通節點上，還是虛擬節點上。

值得注意的是 ASK/ECI 是 nodeless 形態的 pod，在 K8s 中有很多能力和 node 相關，比如 NodePort 等概念不支援，此外類似日誌、監控元件經常以 DaemonSet 的方式在 K8s 節點上部署，在 ASK/ECI 中需要將其轉化為 Sidecar。

![13.jpeg](https://ucc.alicdn.com/pic/developer-ecology/a944ab53082842a8ac2944e224380865.jpeg)

使用者該如何選擇 ACK 和 ASK 呢？ACK 主要面向的是基礎設施運維團隊，具備和 K8s 高度的相容性和靈活性控制性。而 ASK 則是面向業務技術團隊或者開發者，使用者完全不需具備 K8s 的管理運維能力，即可管理和部署 K8s 應用。而 ACK on ECI，則同時支援使用者負載執行在 ECS 例項或者 ECI 例項上，可以允許使用者進行靈活控制。

ACK on ECI/ASK 則可以將彈性的負載透過 ECI 的方式執行，有幾個非常典型的場景：

- 應對突發流量：ECI 基於面向容器的輕量安全沙箱，可以實現 30s 500Pod 的彈性伸縮能力，可以輕鬆應對突發的業務流量，在面對不確定的業務流量時，可以簡化彈性配置；
- 批次資料處理：我們可以實現 Serverless Spark/Presto 這樣的計算任務, 按需為計算任務分配計算資源；
- 安全隔離：有些業務應用需要執行 3 方不可信應用，比如一個 AI 演算法模型，ECI 本身利用安全沙箱進行隔離，我們可以利用 ECI 隔離執行相關應用。

ACK on ECI 還可以和 Knative 這樣的 Serverless 應用框架配合，開發領域相關的 Serverless 應用。

# 總結
合理規劃 K8s 叢集可以有效規避後續運維實踐中的穩定性問題，降低使用成本。期待與大家一起交流阿里雲上使用 Kubernetes 的實踐經驗。

**關於作者**

易立，阿里雲資深技術專家，阿里雲容器服務的研發負責人。之前曾在 IBM 中國開發中心工作，擔任資深技術專員；作為架構師和主要開發人員負責或參與了一系列在雲端計算、區塊鏈、Web 2.0，SOA 領域的產品研發和創新。阿里雲容器平臺團隊求賢若渴！社招技術專家 / 高階技術專家，base 杭州 / 北京 / 深圳。歡迎發簡歷到 jiaxu.ljx@alibaba-inc.com

![14.png](https://ucc.alicdn.com/pic/developer-ecology/8452e6f90f3e44ab9281395a0c2d26e2.png)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

關於 Kubernetes 規劃的靈魂 n 問

相關文章