关于 Kubernetes 规划的灵魂 n 问
作者 | 易立 阿里云資深技術(shù)專家
導(dǎo)讀：Kubernetes 已經(jīng)成為企業(yè)新一代云 IT 架構(gòu)的重要基礎(chǔ)設(shè)施，但是在企業(yè)部署和運維 Kubernetes 集群的過程中，依然充滿了復(fù)雜性和困擾。
阿里云容器服務(wù)自從 2015 年上線后，目前托管著上萬的 K8s 集群來支撐全球各地的客戶。我們對客戶在規(guī)劃集群過程中經(jīng)常會遇見的問題，進行一些分析解答。試圖緩解大家的“選擇恐懼癥”。
如何選擇 Worker 節(jié)點實例規(guī)格？
裸金屬還是虛擬機？
在 Dimanti 2019 年的容器調(diào)查報告中，對專有云用戶選擇裸金屬服務(wù)器來運行容器的主要原因進行了分析。
選擇裸金屬服務(wù)器的最主要原因（超過 55%）是：傳統(tǒng)虛擬化技術(shù) I/O 損耗較大；對于 I/O 密集型應(yīng)用，裸金屬相比傳統(tǒng)虛擬機有更好的性能表現(xiàn)；
此外近 36% 的客戶認為：裸金屬服務(wù)器可以降低成本。大多數(shù)企業(yè)在初始階段采用將容器運行在虛擬機的方案，但是當(dāng)大規(guī)模生產(chǎn)部署的時候，客戶希望直接運行在裸金屬服務(wù)器上來減少虛擬化技術(shù)的 license 成本（這也常被戲稱為“VMWare 稅”）；
還有近 30% 的客戶因為在物理機上部署有更少的額外資源開銷（如虛擬化管理、虛擬機操作系統(tǒng)等）；還有近 24% 的客戶選擇的原因是：可以有更高的部署密度，從而降低基礎(chǔ)設(shè)施成本；
超過 28% 的客戶認為，在物理機上可以更加靈活地選擇網(wǎng)絡(luò)、存儲等設(shè)備和軟件應(yīng)用生態(tài)。
在公共云上，我們應(yīng)該如何選擇呢？2017 年 10 月，阿里云“神龍架構(gòu)”橫空出世。彈性裸金屬服務(wù)器（ECS Bare Metal Instance）是一款同時兼具虛擬機彈性和物理機性能及特性的新型計算類產(chǎn)品，實現(xiàn)超強超穩(wěn)的計算能力，無任何虛擬化開銷。阿里云 2019 年 8 月重磅發(fā)布了彈性計算第六代企業(yè)級實例，基于神龍架構(gòu)對虛擬化能力進行了全面升級。
-
基于阿里自研神龍芯片和全新的輕量化 Hypervisor - 極大減少虛擬化性能開銷。基于阿里云智能神龍芯片和全新的輕量化 VMM，將大量傳統(tǒng)虛擬化功能卸載到專用硬件上，大大降低了虛擬化的性能開銷，同時用戶幾乎可以獲得所有的宿主機 CPU 和內(nèi)存資源，提高整機和大規(guī)格實例的各項能力，尤其是 I/O 性能有了大幅度提升；
-
使用最新第二代英特爾至強可擴展處理器 - E2E 性能提升。使用最新一代 Intel Cascade Lake CPU, 突發(fā)主頻提升至 3.2GHz, 各場景 E2E 性能大幅提升，并在深度學(xué)習(xí)的多種場景有數(shù)倍的提升；
-
給企業(yè)級場景帶來穩(wěn)定和可預(yù)期的表現(xiàn) - 全球最高水準 SLA。針對軟硬件優(yōu)化以及更加實施更細致的 QoS 手段，給企業(yè)級客戶的負載提供更穩(wěn)定可預(yù)期的性能。
一般而言建議：
- 對性能極其敏感的應(yīng)用，如高性能計算，裸金屬實例是較好的選擇；
- 如果需要 Intel SGX，或者安全沙箱等技術(shù)，裸金屬實例是不二選擇；
- 六代虛擬機實例基于神龍架構(gòu)，I/O 性能有了顯著提升，同時有更加豐富的規(guī)格配置，可以針對自身應(yīng)用需求靈活選擇，降低資源成本；
- 虛擬機實例支持熱遷移，可以有效降低運維成本。
阿里云 ACK K8s 集群支持多個節(jié)點伸縮組（AutoScalingGroup），不同彈性伸縮組支持不同的實例規(guī)格。在工作實踐，我們會為 K8s 集群劃分靜態(tài)資源池和彈性資源池。通常而言，固定資源池可以根據(jù)需要選擇裸金屬或者虛擬機實例。彈性資源池建議根據(jù)應(yīng)用負載使用合適規(guī)格的虛擬機實例來優(yōu)化成本、避免浪費，提升彈性供給保障。此外由于裸金屬實例一般 CPU 核數(shù)非常多，大規(guī)格實例在使用中的挑戰(zhàn)請參見下文。
較少的大規(guī)格實例還是較多的小規(guī)格實例？
一個引申的問題是，如何選擇實例規(guī)格？我們列表對比一下：
默認情況下，kubelet 使用 CFS 配額 來執(zhí)行 pod 的 CPU 約束。當(dāng)節(jié)點上運行了很多 CPU 密集的應(yīng)用時，工作負載可能會遷移到不同的 CPU 核，工作負載的會受到 CPU 緩存親和性以及調(diào)度延遲的影響。當(dāng)使用大規(guī)格實例類型時，節(jié)點的 CPU 數(shù)量較多，現(xiàn)有的 Java，Golang 等應(yīng)用在多 CPU 共享的場景，性能會出現(xiàn)明顯下降。所有對于大規(guī)格實例，需要對 CPU 管理策略進行配置，利用 CPU set 進行資源分配。
此外一個重要的考慮因素就是 NUMA 支持。在 NUMA 開啟的裸金屬實例或者大規(guī)格實例上，如果處理不當(dāng)，內(nèi)存訪問吞吐可能會比優(yōu)化方式降低了 30%。Topology 管理器可以開啟 NUMA 感知 。但是目前 K8s 對 NUMA 的支持比較簡單，還無法充分發(fā)揮 NUMA 的性能。
https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/
阿里云容器服務(wù)提供了 CGroup Controller 可以更加靈活地對 NUMA 架構(gòu)進行調(diào)度和重調(diào)度。
如何容器運行時?
Docker 容器還是安全沙箱？
在 Sysdig 發(fā)布的 2019 容器使用報告中，我們可以看到 Docker 容器占據(jù)市場規(guī)模最大的容器運行時 （79%），containerd 是 Docker 貢獻給 CNCF 社區(qū)的開源容器運行時，現(xiàn)在也占據(jù)了一席之地，并且得到了廠商的廣泛支持；cri-o 是紅帽公司推出的支持 OCI 規(guī)范的面向 K8s 的輕量容器運行時，目前還處在初級階段。
很多同學(xué)都關(guān)心 containerd 與 Docker 的關(guān)系，以及是否 containerd 可以取代 Docker？Docker Engine 底層的容器生命周期管理也是基于 containerd 實現(xiàn)。但是 Docker Engine 包含了更多的開發(fā)者工具鏈，比如鏡像構(gòu)建。也包含了 Docker 自己的日志、存儲、網(wǎng)絡(luò)、Swarm 編排等能力。此外，絕大多數(shù)容器生態(tài)廠商，如安全、監(jiān)控、日志、開發(fā)等對 Docker Engine 的支持比較完善，對 containerd 的支持也在逐漸補齊。
所以在 Kubernetes 運行時環(huán)境，對安全和效率和定制化更加關(guān)注的用戶可以選擇 containerd 作為容器運行時環(huán)境。對于大多數(shù)開發(fā)者，繼續(xù)使用 Docker Engine 作為容器運行時也是一個不錯的選擇。
此外，傳統(tǒng)的 Docker RunC 容器與宿主機 Linux 共享內(nèi)核，通過 CGroup 和 namespace 實現(xiàn)資源隔離。但是由于操作系統(tǒng)內(nèi)核的攻擊面比較大，一旦惡意容器利用內(nèi)核漏洞，可以影響整個宿主機上所有的容器。
越來越多企業(yè)客戶關(guān)注容器的安全性，為了提升安全隔離，阿里云和螞蟻金服團隊合作，引入安全沙箱容器技術(shù)。19 年 9 月份我們發(fā)布了基于輕量虛擬化技術(shù)的 RunV 安全沙箱。相比于 RunC 容器，每個 RunV 容器具有獨立內(nèi)核，即使容器所屬內(nèi)核被攻破，也不會影響其他容器，非常適合運行來自第三方不可信應(yīng)用或者在多租戶場景下進行更好的安全隔離。
阿里云安全沙箱容器有大量性能優(yōu)化，可以達到 90% 的原生 RunC 性能：
- 利用 Terway CNI 網(wǎng)絡(luò)插件，網(wǎng)絡(luò)性能無損；
- 利用 DeviceMapper 構(gòu)建了?速、穩(wěn)定的容器 Graph Driver；
- 優(yōu)化 FlexVolume 和 CSI Plugin，把 mount bind 的動作下沉到沙箱容器內(nèi)，從而避開了 9pfs 帶來的性能損耗。
而且，ACK 為安全沙箱容器和和 RunC 容器提供了完全一致的用戶體驗，包括日志、監(jiān)控、彈性等。同時，ACK 可以在一臺神龍裸金屬實例上同時混布 RunC 和 RunV 容器，用戶可以根據(jù)自己的業(yè)務(wù)特性自主選擇。
同時，我們也要看到安全沙箱容器還有一些局限性，現(xiàn)有很多日志、監(jiān)控、安全等工具對獨立內(nèi)核的安全沙箱支持不好，需要作為 sidecar 部署在安全沙箱內(nèi)部。
對于用戶而言，如果需要多租戶隔離的場景，可以采用安全沙箱配合 network policy 來完成，當(dāng)然也可以讓不同租戶的應(yīng)用運行在不同的虛擬機或者彈性容器實例上，利用虛擬化技術(shù)來進行隔離。
注意：安全沙箱目前只能運行在裸金屬實例上，當(dāng)容器應(yīng)用需要資源較少時成本比較高。可以參考下文的 Serverless K8s 有關(guān)內(nèi)容。
如何規(guī)劃容器集群？
一個大集群還是一組小集群？
在生產(chǎn)實踐中，大家經(jīng)常問到的一個問題是我們公司應(yīng)該選擇一個還是多個 Kubernetes 集群。
Rob Hirschfeld 在 Twitter 上做了一個調(diào)查：
- 一個大一統(tǒng)的平臺，支持多種應(yīng)用負載、環(huán)境和多租戶隔離；
- 或者，一組以應(yīng)用為中心的小集群，支持不同應(yīng)用和環(huán)境的生命周期管理。
https://thenewstack.io/the-optimal-kubernetes-cluster-size-lets-look-at-the-data/
大多數(shù)的用戶選擇是后者，典型的場景是：
- 開發(fā)、測試環(huán)境使用不同的集群
- 不同的部門使用不同的集群進行隔離
- 不同的應(yīng)用使用不同的集群
- 不同版本的 K8s 集群
在用戶反饋中，采用以多個小集群的主要原因在于爆炸半徑比較小，可以有效提升系統(tǒng)的可用性。同時通過集群也可以比較好地進行資源隔離。管理、運維復(fù)雜性的增加是采用多個小集群的一個不足之處，但是在公共云上利用托管的 K8s 服務(wù)（比如阿里云的 ACK）創(chuàng)建和管理 K8s 集群生命周期非常簡單，可以有效解決這個問題。
我們可以比較一下這兩種選擇：
源自 Google Borg 的理念，Kubernetes 的愿景是成為 Data Center Operating System，而且 Kubernetes 也提供了 RBAC、namespace 等管理能力，支持多用戶共享一個集群，并實現(xiàn)資源限制。但是這些更多是 “軟多租” 能力，不能實現(xiàn)不同租戶之間的強隔離。在多租最佳實踐中，我們可以有如下的一些建議：
-
數(shù)據(jù)平面：可以通過 PSP (PodSecurityPolicy) 或者安全沙箱容器，提升容器的隔離性；利用 Network Policy 提升應(yīng)用之間網(wǎng)絡(luò)隔離性；可以通過將 nodes 和 namespace 綁定在一起，來提升 namespace 之間資源的隔離；
-
控制平面：Kubernetes 的控制平面包括 master 組件 API Server, Scheduler, etcd 等，系統(tǒng) addon 如 CoreDNS, Ingress Controller 等，以及用戶的擴展，如 3 方的 CRD (Customer Resource Definition) controller。這些組件大多不具備良好的租戶之間的安全、資源和故障隔離能力。一個錯誤的 CRD contoller 實現(xiàn)有可能打掛一個集群的 API Server。
關(guān)于 Kubernetes 多租戶實踐的具體信息可以參考下文。目前而言，Kubernetes 對硬隔離的支持存在很多局限性，同時社區(qū)也在積極探索一些方向，如阿里容器團隊的 Virtual Cluster Proposal 可以提升隔離的支持，但是這些技術(shù)還未成熟。
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 集群的規(guī)模在保障穩(wěn)定性的前提下受限于多個維度，一般而言 Kubernetes 集群小于 5000 節(jié)點。當(dāng)然，運行在阿里云上還受限于云產(chǎn)品的 quota 限制。阿里經(jīng)濟體在 Kubernetes 規(guī)模化上有豐富的經(jīng)驗，但是對于絕大多數(shù)客戶而言，是無法解決超大集群的運維和定制化復(fù)雜性的。
對于公共云客戶我們一般建議，針對業(yè)務(wù)場景建議選擇合適的集群規(guī)模：
- 對于跨地域（region）場景，采用多集群策略，K8s 集群不應(yīng)跨地域。我們可以利用 CEN 將不同地域的 VPC 打通；
- 對于強隔離場景，采用多集群策略，不同安全域的應(yīng)用部署在不同的集群上；
- 對于應(yīng)用隔離場景，比如 SaaS 化應(yīng)用，可以采用單集群方式支持多租，并加強安全隔離；
- 對于多個大規(guī)模應(yīng)用，可以采用多集群策略，比如，在線應(yīng)用、AI 訓(xùn)練、實時計算等可以運行在不同的 K8s 集群之上，一方面可以控制集群規(guī)模，一方面可以針對應(yīng)用負載選擇合適的節(jié)點規(guī)格和調(diào)度策略。
由于有 VPC 中節(jié)點、網(wǎng)絡(luò)資源的限制，我們可以甚至將不同的 K8s 集群分別部署在不同的 VPC，利用 CEN 實現(xiàn)網(wǎng)絡(luò)打通，這部分需要對網(wǎng)絡(luò)進行前期規(guī)劃。
- 如果需要對多個集群的應(yīng)用進行統(tǒng)一管理，有如下幾個考慮；
- 利用 Kubefed 構(gòu)建集群聯(lián)邦，ACK 對集群聯(lián)邦的支持可以參考。
https://help.aliyun.com/document_detail/121653.html?spm=a2c6h.12873639.0.0.28373df9R7x2DP
利用統(tǒng)一的配置管理中心，比如 GitOps 方式來管理和運維應(yīng)用。
https://github.com/fluxcd/flux?spm=a2c6h.12873639.0.0.28373df9R7x2DP
另外利用托管服務(wù)網(wǎng)格服務(wù) ASM，可以利用 Istio 服務(wù)網(wǎng)格輕松實現(xiàn)對多個 K8s 集群的應(yīng)用的統(tǒng)一路由管理。
如何選擇 K8s 或者 Serverless K8s 集群？
在所有的調(diào)查中，K8s 的復(fù)雜性和缺乏相應(yīng)的技能是阻礙 K8s 企業(yè)所采用的主要問題，在 IDC 中運維一個 Kubernetes 生產(chǎn)集群還是非常具有挑戰(zhàn)的任務(wù)。阿里云的 Kubernetes 服務(wù) ACK 簡化了 K8s 集群的生命周期管理，托管了集群的 master 節(jié)點被，但是用戶依然要維護 worker 節(jié)點，比如進行升級安全補丁等，并根據(jù)自己的使用情況進行容量規(guī)劃。
針對 K8s 的運維復(fù)雜性挑戰(zhàn)，阿里云推出了 Serverless Kubernetes 容器服務(wù) ASK。
完全兼容現(xiàn)有 K8s 容器應(yīng)用，但是所有容器基礎(chǔ)設(shè)施被阿里云托管，用戶可以專注于自己的應(yīng)用。它具備幾個特點：
在 ASK 中，應(yīng)用運行在彈性容器實例 - ECI （Elastic Container Instance）中，ECI 基于輕量虛擬機提供的沙箱環(huán)境實現(xiàn)應(yīng)用安全隔離，并且完全兼容 Kubernetes Pod 語義。在 ASK 中我們通過對 Kubernetes 做減法，將復(fù)雜性下沉到基礎(chǔ)設(shè)施，極大降低了運維管理負擔(dān)，提升用戶體驗，讓 Kubernetes 更簡單，讓開發(fā)者更加專注于應(yīng)用自身。除了無需管理節(jié)點和 Master 外，我們將 DNS, Ingress 等能力通過阿里云產(chǎn)品的原生能力來實現(xiàn)，提供了極簡但功能完備的 Kubernetes 應(yīng)用運行環(huán)境。
Serverless Kubernetes 極大降低了管理復(fù)雜性，而且其自身設(shè)計非常適合突發(fā)類應(yīng)用負載，如 CI/CD，批量計算等等。比如一個典型的在線教育客戶，根據(jù)教學(xué)需要按需部署教學(xué)應(yīng)用，課程結(jié)束自動釋放資源，整體計算成本只有使用包月節(jié)點的 1/3。
在編排調(diào)度層，我們借助了 CNCF 社區(qū)的 Virtual-Kubelet，并對其進行了深度擴展。Virtual-Kubelet 提供了一個抽象的控制器模型來模擬一個虛擬 Kubernetes 節(jié)點。當(dāng)一個 Pod 被調(diào)度到虛擬節(jié)點上，控制器會利用 ECI 服務(wù)來創(chuàng)建一個 ECI 實例來運行 Pod。
我們還可以將虛擬節(jié)點加入 ACK K8s 集群，允許用戶靈活控制應(yīng)用部署在普通節(jié)點上，還是虛擬節(jié)點上。
值得注意的是 ASK/ECI 是 nodeless 形態(tài)的 pod，在 K8s 中有很多能力和 node 相關(guān)，比如 NodePort 等概念不支持，此外類似日志、監(jiān)控組件經(jīng)常以 DaemonSet 的方式在 K8s 節(jié)點上部署，在 ASK/ECI 中需要將其轉(zhuǎn)化為 Sidecar。
用戶該如何選擇 ACK 和 ASK 呢？ACK 主要面向的是基礎(chǔ)設(shè)施運維團隊，具備和 K8s 高度的兼容性和靈活性控制性。而 ASK 則是面向業(yè)務(wù)技術(shù)團隊或者開發(fā)者，用戶完全不需具備 K8s 的管理運維能力，即可管理和部署 K8s 應(yīng)用。而 ACK on ECI，則同時支持用戶負載運行在 ECS 實例或者 ECI 實例上，可以允許用戶進行靈活控制。
ACK on ECI/ASK 則可以將彈性的負載通過 ECI 的方式運行，有幾個非常典型的場景：
- 應(yīng)對突發(fā)流量：ECI 基于面向容器的輕量安全沙箱，可以實現(xiàn) 30s 500Pod 的彈性伸縮能力，可以輕松應(yīng)對突發(fā)的業(yè)務(wù)流量，在面對不確定的業(yè)務(wù)流量時，可以簡化彈性配置；
- 批量數(shù)據(jù)處理：我們可以實現(xiàn) Serverless Spark/Presto 這樣的計算任務(wù), 按需為計算任務(wù)分配計算資源；
- 安全隔離：有些業(yè)務(wù)應(yīng)用需要運行 3 方不可信應(yīng)用，比如一個 AI 算法模型，ECI 本身利用安全沙箱進行隔離，我們可以利用 ECI 隔離運行相關(guān)應(yīng)用。
ACK on ECI 還可以和 Knative 這樣的 Serverless 應(yīng)用框架配合，開發(fā)領(lǐng)域相關(guān)的 Serverless 應(yīng)用。
總結(jié)
合理規(guī)劃 K8s 集群可以有效規(guī)避后續(xù)運維實踐中的穩(wěn)定性問題，降低使用成本。期待與大家一起交流阿里云上使用 Kubernetes 的實踐經(jīng)驗。
關(guān)于作者
易立，阿里云資深技術(shù)專家，阿里云容器服務(wù)的研發(fā)負責(zé)人。之前曾在 IBM 中國開發(fā)中心工作，擔(dān)任資深技術(shù)專員；作為架構(gòu)師和主要開發(fā)人員負責(zé)或參與了一系列在云計算、區(qū)塊鏈、Web 2.0，SOA 領(lǐng)域的產(chǎn)品研發(fā)和創(chuàng)新。
“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術(shù)圈。”
總結(jié)
以上是生活随笔為你收集整理的关于 Kubernetes 规划的灵魂 n 问的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 函数计算支持 MySQL 实例绑定
- 下一篇： “网红” WebAssembly 与 K