關於 Kubernetes 規劃的靈魂 n 問

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

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

阿里雲容器服務自從 2015 年上線後，目前託管着上萬的 K8s 集羣來支撐全球各地的客戶。咱們對客戶在規劃集羣過程當中常常會碰見的問題，進行一些分析解答。試圖緩解你們的「選擇恐懼症」。

如何選擇 Worker 節點實例規格？

裸金屬仍是虛擬機？

在 Dimanti 2019 年的容器調查報告中，對專有云用戶選擇裸金屬服務器來運行容器的主要緣由進行了分析。

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 手段，給企業級客戶的負載提供更穩定可預期的性能。

通常而言建議：

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

阿里雲 ACK K8s 集羣支持多個節點伸縮組（AutoScalingGroup），不一樣彈性伸縮組支持不一樣的實例規格。在工做實踐，咱們會爲 K8s 集羣劃分靜態資源池和彈性資源池。一般而言，固定資源池能夠根據須要選擇裸金屬或者虛擬機實例。彈性資源池建議根據應用負載使用合適規格的虛擬機實例來優化成本、避免浪費，提高彈性供給保障。此外因爲裸金屬實例通常 CPU 核數很是多，大規格實例在使用中的挑戰請參見下文。

較少的大規格實例仍是較多的小規格實例？

一個引伸的問題是，如何選擇實例規格？咱們列表對比一下：

默認狀況下，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/

阿里雲容器服務提供了 CGroup Controller 能夠更加靈活地對 NUMA 架構進行調度和重調度。

如何容器運行時?

Docker 容器仍是安全沙箱？

在 Sysdig 發佈的 2019 容器使用報告中，咱們能夠看到 Docker 容器佔據市場規模最大的容器運行時 （79%），containerd 是 Docker 貢獻給 CNCF 社區的開源容器運行時，如今也佔據了一席之地，而且獲得了廠商的普遍支持；cri-o 是紅帽公司推出的支持 OCI 規範的面向 K8s 的輕量容器運行時，目前還處在初級階段。

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

因此在 Kubernetes 運行時環境，對安全和效率和定製化更加關注的用戶能夠選擇 containerd 做爲容器運行時環境。對於大多數開發者，繼續使用 Docker Engine 做爲容器運行時也是一個不錯的選擇。

此外，傳統的 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 容器，用戶能夠根據本身的業務特性自主選擇。

同時，咱們也要看到安全沙箱容器還有一些侷限性，現有不少日誌、監控、安全等工具對獨立內核的安全沙箱支持很差，須要做爲 sidecar 部署在安全沙箱內部。

對於用戶而言，若是須要多租戶隔離的場景，能夠採用安全沙箱配合 network policy 來完成，固然也可讓不一樣租戶的應用運行在不一樣的虛擬機或者彈性容器實例上，利用虛擬化技術來進行隔離。

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

如何規劃容器集羣？

一個大集羣仍是一組小集羣？

在生產實踐中，你們常常問到的一個問題是咱們公司應該選擇一個仍是多個 Kubernetes 集羣。

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

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

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

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

• 開發、測試環境使用不一樣的集羣
• 不一樣的部門使用不一樣的集羣進行隔離
• 不一樣的應用使用不一樣的集羣
• 不一樣版本的 K8s 集羣

在用戶反饋中，採用以多個小集羣的主要緣由在於爆炸半徑比較小，能夠有效提高系統的可用性。同時經過集羣也能夠比較好地進行資源隔離。管理、運維複雜性的增長是採用多個小集羣的一個不足之處，可是在公共雲上利用託管的 K8s 服務（好比阿里雲的 ACK）建立和管理 K8s 集羣生命週期很是簡單，能夠有效解決這個問題。

咱們能夠比較一下這兩種選擇：

源自 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://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster?spm=a2c6h.12873639.0.0.28373df9R7x2DP

另外一個須要考慮的方案是 Kubernetes 自身的可擴展性，咱們知道一個 Kubernetes 集羣的規模在保障穩定性的前提下受限於多個維度，通常而言 Kubernetes 集羣小於 5000 節點。固然，運行在阿里雲上還受限於雲產品的 quota 限制。阿里經濟體在 Kubernetes 規模化上有豐富的經驗，可是對於絕大多數客戶而言，是沒法解決超大集羣的運維和定製化複雜性的。

對於公共雲客戶咱們通常建議，針對業務場景建議選擇合適的集羣規模：

• 對於跨地域（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

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

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. 首先它按照容器應用實際消耗的資源付費，而不是按照預留的節點資源付費；
2. 對用戶而言沒有節點的概念，零維護；
3. 全部資源按需建立，無需任何容量規劃。

在 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。

用戶該如何選擇 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

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」