Kubernetes 容器平臺(tái)，從繁榮走向碎片化
云計(jì)算的拐點(diǎn)已至進(jìn)入成熟期，云原生成為驅(qū)動(dòng)業(yè)務(wù)發(fā)展的動(dòng)力引擎，作為新型基礎(chǔ)設(shè)施，不僅是企業(yè)數(shù)字化轉(zhuǎn)型的最佳技術(shù)路徑，同時(shí)也成為新領(lǐng)域人工智能、大數(shù)據(jù)、邊緣計(jì)算、5G 等底層平臺(tái)基礎(chǔ)設(shè)施。隨著云原生技術(shù)的成熟和市場(chǎng)需求的升級(jí)，云計(jì)算的發(fā)展已步入新的階段。
云原生2.0，將充分地釋放了云計(jì)算的紅利，未來(lái)將有更多的業(yè)務(wù)應(yīng)用生于云，長(zhǎng)于云；為了最大程度發(fā)揮云原生的優(yōu)勢(shì)，支持好各種復(fù)雜個(gè)性化場(chǎng)景，云原生技術(shù)在不斷完善演進(jìn)，從中心到邊緣；理念也在不斷總結(jié)升華，從微服務(wù)到Mesh，再到無(wú)服務(wù)，業(yè)驅(qū)云長(zhǎng)，云隨業(yè)動(dòng)。
1.1 云原生時(shí)代
Kubernetes開(kāi)啟了整個(gè)云原生的時(shí)代，以?xún)赡隇橐粋€(gè)大的階段，可以分為五個(gè)階段，分別是孵化期、高速發(fā)展期、野蠻生長(zhǎng)期、普及推廣期、業(yè)務(wù)重構(gòu)期。隨著物聯(lián)網(wǎng)、人工智能等技術(shù)的不斷發(fā)展，尤其是產(chǎn)業(yè)互聯(lián)網(wǎng)發(fā)展落地，云原生作為新一代基礎(chǔ)設(shè)施，從互聯(lián)網(wǎng)大廠(chǎng)走向企業(yè)，走向產(chǎn)業(yè)；云原生2.0，企業(yè)云化從“On Cloud”走向“In Cloud“，生于云、長(zhǎng)于云且立而不破；企業(yè)新生能力基于云原生構(gòu)建，使其生于云；應(yīng)用、數(shù)據(jù)和AI的全生命周期云上完成，使其長(zhǎng)于云；企業(yè)原來(lái)的業(yè)務(wù)核心系統(tǒng)開(kāi)始基于云原生的技術(shù)理念解構(gòu)及重構(gòu)，實(shí)現(xiàn)借助技術(shù)的敏捷實(shí)現(xiàn)業(yè)務(wù)敏捷的數(shù)字化轉(zhuǎn)型。
未來(lái)云原生必將更全面的服務(wù)于產(chǎn)業(yè)與實(shí)業(yè)，分布式云 + 云原生，將成為云基礎(chǔ)設(shè)施新范式，賦能新云原生企業(yè)敏捷創(chuàng)新，推動(dòng)云原生生態(tài)有序繁榮，讓云無(wú)處不在，讓智能無(wú)所不及。
1.2 Kubernetes架構(gòu)及擴(kuò)展性
Kubernetes主要由以下幾個(gè)核心組件組成：
etcd保存整個(gè)集群的狀態(tài)； apiserver提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪(fǎng)問(wèn)控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制； controller manager負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測(cè)、自動(dòng)擴(kuò)展、滾動(dòng)更新等； scheduler負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上； kubelet負(fù)責(zé)維護(hù)容器的生命周期，負(fù)責(zé)Volume（CSI）和網(wǎng)絡(luò)（CNI）的管理；同時(shí)也負(fù)責(zé)管控Device Plugins，主要是GPU，F(xiàn)PGA及網(wǎng)絡(luò)設(shè)備。 container runtime負(fù)責(zé)鏡像管理以及Pod和容器的真正運(yùn)行（CRI）； kube-proxy負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡；
早期在Kubernetes在高速發(fā)展期，為了快速適配各個(gè)各樣的場(chǎng)景，將Kubernetes打造成一個(gè)可擴(kuò)展的平臺(tái)，大致可以分為基礎(chǔ)設(shè)施（Infrastructure）及應(yīng)用管理（Application Management）擴(kuò)展兩個(gè)方面：
基礎(chǔ)設(shè)施（Infrastructure）擴(kuò)展：
通過(guò)OCI與CRI標(biāo)準(zhǔn)容器鏡像（image spec）及容器運(yùn)行時(shí)（runtime spec）。 通過(guò)CNI與CSI標(biāo)準(zhǔn)化網(wǎng)絡(luò)及存儲(chǔ)，開(kāi)放網(wǎng)絡(luò)及存儲(chǔ)擴(kuò)展能力。 通過(guò)Device Plugins插件框架，將系統(tǒng)硬件資源引入到Kubernetes體系。
應(yīng)用管理（Application Management）擴(kuò)展：
通過(guò)CRD擴(kuò)展Kubernetes用戶(hù)自定義資源。 通過(guò)Operators實(shí)現(xiàn)Kubernetes應(yīng)用生命周期管理。
Kubernetes可擴(kuò)展性架構(gòu)及CNCF開(kāi)放式生態(tài)發(fā)展方向，在高速發(fā)展期，野蠻生長(zhǎng)期乃至普及推廣期，開(kāi)放式平臺(tái)及生態(tài)都是非常正確明智的選擇；但是進(jìn)入業(yè)務(wù)重構(gòu)期，面向業(yè)務(wù)需要提供整體性一體化的平臺(tái)，而不是一個(gè)碎片化的功能部件，不是所有公司都具備組裝及調(diào)優(yōu)能力，這時(shí)候平臺(tái)的價(jià)值就會(huì)被重復(fù)的組裝及調(diào)優(yōu)將價(jià)值拉低；平臺(tái)需要從散裝轉(zhuǎn)化成一體化，開(kāi)箱即用的品牌機(jī)，要么就直接選擇企業(yè)級(jí)容器平臺(tái)或公有云容器產(chǎn)品，比如Openshift及阿里云ACK；要么通過(guò)生態(tài)治理，逐步收緊平臺(tái)擴(kuò)展能力，增加組件的成熟度監(jiān)管，分久必合合久必分，在分與合中保障平臺(tái)及生態(tài)的良性發(fā)展。
1.3 Kubernetes走向碎片化
CNCF開(kāi)放式生態(tài)，是導(dǎo)致整個(gè)生態(tài)體系碎片化的根源；從2015年CNCF只有Kubernetes一個(gè)項(xiàng)目，到如今高達(dá)80多個(gè)官方項(xiàng)目，其中畢業(yè)項(xiàng)目15個(gè)，孵化項(xiàng)目21個(gè)，沙盒46個(gè)項(xiàng)目；包含底層眾多的容器運(yùn)行時(shí)、容器存儲(chǔ)、容器網(wǎng)絡(luò)以及硬件加速器項(xiàng)目，還有以應(yīng)用為中心的北向數(shù)據(jù)庫(kù)、中間件等項(xiàng)目。
通過(guò)CNCF官方認(rèn)證的Kubernetes的云服務(wù)或者發(fā)行版也多達(dá)130款，通過(guò)CNCF官方認(rèn)證服務(wù)商和培訓(xùn)合作伙伴超過(guò)250家。在中國(guó)CNCF的會(huì)員數(shù)量超過(guò)60家成員單位。
如此龐大的軟件生態(tài)體系，集結(jié)了開(kāi)源，云廠(chǎng)商，軟件服務(wù)商及設(shè)備廠(chǎng)商等多個(gè)利益方；整個(gè)生態(tài)大躍進(jìn)式發(fā)展，無(wú)論是公有云廠(chǎng)家還是企業(yè)，都是忙于通過(guò)積木式能力組裝容器平臺(tái)，樂(lè)此不疲。還有公有云廠(chǎng)商，疲于跟進(jìn)與整合容器技術(shù)，但只能提供毫無(wú)壁壘，毫無(wú)優(yōu)勢(shì)的工具平臺(tái)，無(wú)法形成真正產(chǎn)品及競(jìng)爭(zhēng)力；還有從容器，微服務(wù)到無(wú)服務(wù)技術(shù)，平臺(tái)能力幾乎應(yīng)有盡有，貌似全部就緒，好像就只差最理想的應(yīng)用遷入即可；但是在實(shí)際的使用及推廣過(guò)程，與喧囂的社區(qū)相比，云原生的價(jià)值被疲于應(yīng)對(duì)平臺(tái)各種詭異問(wèn)題，兼容新老業(yè)務(wù)的痛苦過(guò)程中消耗殆盡，一片哀嚎。
1.3.1 容器運(yùn)行時(shí)的碎片化
容器運(yùn)行時(shí)（Container Runtime Interface，簡(jiǎn)稱(chēng) CRI）是Kubernetes v1.5引入的容器運(yùn)行時(shí)接口，它將Kubelet與容器運(yùn)行時(shí)解耦，將原來(lái)完全面向Pod級(jí)別的內(nèi)部接口拆分成面向Sandbox和Container的gRPC接口，并將鏡像管理和容器管理分離到不同的服務(wù)。在v1.6時(shí)已經(jīng)有了很多外部容器運(yùn)行時(shí)，如frakti和cri-o等。v1.7中又新增了cri-containerd支持用containerd來(lái)管理容器。
Kubelet銜接運(yùn)行時(shí)的方式及調(diào)用鏈路如下：
docker： dockershim => dockerd => containerd => runccontainerd： containerd => shim v2 => runccri-o*： cri-o => runcfrakti： frakti => runvpouch： pouchContainer => containerd => runc
containerd與cri-o：兩者都是調(diào)用runc，containerd是內(nèi)置runc代碼，通過(guò)函數(shù)直接調(diào)用；cri-o是通過(guò)linux命令方式調(diào)用runc二進(jìn)制文件，在性能上containerd更具優(yōu)勢(shì)，但是cri-o集成方式更為合理優(yōu)雅，比較推薦cri-o。 runc與runv：runc創(chuàng)建的容器進(jìn)程，直接運(yùn)行在宿主機(jī)內(nèi)核上，而runv是運(yùn)行在由Hypervisor虛擬出來(lái)的虛擬機(jī)上，占用的資源更多啟動(dòng)速度慢，而且runv容器在調(diào)用底層硬件時(shí)，中間多了一層虛擬硬件層，計(jì)算效率上不如runc容器。
總的來(lái)說(shuō)，生產(chǎn)環(huán)境的運(yùn)行時(shí)選擇主要取決于運(yùn)行效率，端到端的全流程運(yùn)行效率，因此建議結(jié)合自身業(yè)務(wù)需求，使用場(chǎng)景以及團(tuán)隊(duì)技術(shù)儲(chǔ)備等選擇合適的容器運(yùn)行時(shí)。對(duì)性能要求大于安全隔離要求時(shí)，推薦使用cri-o + runc；對(duì)安全隔離要求大于性能要求時(shí)，在隔離性要求較高的業(yè)務(wù)場(chǎng)景下，推薦使用frakti + runv。
1.3.2 容器網(wǎng)絡(luò)的碎片化
容器網(wǎng)絡(luò)屬于Kubernetes容器平臺(tái)核心組件，技術(shù)復(fù)雜度高，對(duì)業(yè)務(wù)影響大。Kubernetes網(wǎng)絡(luò)依賴(lài)底層的技術(shù)大致可以分為三大類(lèi)：
Overlay模式是在二層或三層網(wǎng)絡(luò)之上再構(gòu)建起來(lái)一個(gè)獨(dú)立的網(wǎng)絡(luò)，這個(gè)網(wǎng)絡(luò)通常會(huì)有自己獨(dú)立的IP地址空間、交換或者路由的實(shí)現(xiàn)。VXLAN協(xié)議是目前最流行的Overlay網(wǎng)絡(luò)隧道協(xié)議之一，顯著優(yōu)勢(shì)就是靈活，對(duì)底層網(wǎng)絡(luò)沒(méi)有侵入性。 路由模式放棄了跨主機(jī)容器在L2的連通性，而專(zhuān)注于通過(guò)路由協(xié)議提供容器在L3的通信方案；路由模式更易于集成到現(xiàn)在的數(shù)據(jù)中心的基礎(chǔ)設(shè)施之上，便捷地連接容器和主機(jī)，并在報(bào)文過(guò)濾和隔離方面有著更好的擴(kuò)展能力及更精細(xì)的控制模型。 Underlay模式是借助驅(qū)動(dòng)程序?qū)⑺拗鳈C(jī)的底層網(wǎng)絡(luò)接口直接暴露給容器使用的一種網(wǎng)絡(luò)構(gòu)建技術(shù)，較為常見(jiàn)的解決方案有 MAC VLAN、IP VLAN 和直接路由等。
同時(shí)容器網(wǎng)絡(luò)技術(shù)也在持續(xù)演進(jìn)發(fā)展，社區(qū)開(kāi)源的網(wǎng)絡(luò)組件眾多，每個(gè)組件都有各自的優(yōu)點(diǎn)及適應(yīng)的場(chǎng)景，難以形成統(tǒng)一的標(biāo)準(zhǔn)組件，以下是比較常用Flannel、Calico、Cilium、OVN網(wǎng)絡(luò)插件簡(jiǎn)單介紹：
Flannel：Flannel是最流行的Kubernetes容器網(wǎng)絡(luò)插件，提供多種網(wǎng)絡(luò)模式實(shí)現(xiàn)，覆蓋多種場(chǎng)景，支持3種網(wǎng)絡(luò)模式：
UDP模式使用設(shè)備 flannel.0進(jìn)行封包解包，不是內(nèi)核原生支持，上下文切換較大，性能非常差；VXLAN模式使用 flannel.1進(jìn)行封包解包，內(nèi)核原生支持，性能較強(qiáng)，性能損失可以控制在20%~30%左右；HOST-GW模式直接將宿主機(jī)當(dāng)作子網(wǎng)的下一跳地址，性能最強(qiáng)，性能損失大約在10%左右。 Calico：Calico 是一套開(kāi)源的網(wǎng)絡(luò)和網(wǎng)絡(luò)安全方案，用于容器、虛擬機(jī)、宿主機(jī)之前的網(wǎng)絡(luò)連接，支持3種網(wǎng)絡(luò)模式：
全互聯(lián)模式(node-to-node mesh) 基于BGP協(xié)議，每一個(gè)BGP Speaker都需要和其他BGP Speaker建立BGP連接，這樣BGP連接總數(shù)就是N^2，如果數(shù)量過(guò)大會(huì)消耗大量連接。 路由反射模式Router Reflection（RR）基于BGP協(xié)議，指定一個(gè)或多個(gè)BGP Speaker為RouterReflection，它與網(wǎng)絡(luò)中其他Speaker建立連接，每個(gè)Speaker只要與Router Reflection建立BGP就可以獲得全網(wǎng)的路由信息。 IPIP模式把IP層封裝到IP層的一個(gè)tunnel，常規(guī)的網(wǎng)橋是mac層的，而ipip 則是通過(guò)兩端的路由做一個(gè)tunnel，從而將兩個(gè)本來(lái)不通的網(wǎng)絡(luò)通過(guò)點(diǎn)對(duì)點(diǎn)連接起來(lái)。 Cilium：
Cilium是一個(gè)基于eBPF和XDP的高性能容器網(wǎng)絡(luò)方案,是Kubernetes第一個(gè)基于BPF的CNI，支持L3/L4/L7安全策略，支持三層平面網(wǎng)絡(luò)(如Overlay，VXLAN和Geneve等)，提供基于BPF的負(fù)載均衡，提供便利的監(jiān)控和排錯(cuò)能力，為大規(guī)模集群環(huán)境而設(shè)計(jì)。Cilium的賣(mài)點(diǎn)并不是eBPF，相對(duì)于固化的iptables或ipvs而言，Cillium真正的賣(mài)點(diǎn)是eBPF提供的無(wú)限可編程能力。OVN：
ovn-kubernetes提供了一個(gè)OVS/OVN網(wǎng)絡(luò)插件，支持 underlay 和 overlay 兩種模式。underlay 是容器運(yùn)行在虛擬機(jī)中，而ovs則運(yùn)行在虛擬機(jī)所在的物理機(jī)上，OVN將容器網(wǎng)絡(luò)和虛擬機(jī)網(wǎng)絡(luò)連接在一起；overlay是OVN通過(guò)logical overlay network連接所有節(jié)點(diǎn)的容器，此時(shí)ovs可以直接運(yùn)行在物理機(jī)或虛擬機(jī)上。
總的來(lái)說(shuō)，Overlay模式對(duì)底層網(wǎng)絡(luò)要求低、落地容易、IP地址占用少等特點(diǎn)，但是對(duì)性能損失比較大。路由模式更易于集成到現(xiàn)在的數(shù)據(jù)中心的基礎(chǔ)設(shè)施之上，便捷地連接容器和主機(jī)，并在報(bào)文過(guò)濾和隔離方面有著更好的擴(kuò)展能力及更精細(xì)的控制模型；Underlay模式對(duì)底層網(wǎng)絡(luò)要求較高，但是如果底層已經(jīng)有一個(gè)完整的虛擬化IaaS層，尤其是公有云場(chǎng)景，將云原生能力直接融入到現(xiàn)有的云體系，通過(guò) Underlay模式實(shí)現(xiàn)高性能，靈活可定義的容器網(wǎng)絡(luò)才是最佳選擇。
1.3.3 容器存儲(chǔ)的碎片化
市面上的存儲(chǔ)產(chǎn)品種類(lèi)繁多，主要分為四大類(lèi)，分別是分布式文件存儲(chǔ)，分布式塊存儲(chǔ)，Local-Disk和傳統(tǒng)NAS。
分布式塊存儲(chǔ)：包括開(kāi)源社區(qū)的Ceph，Sheepdog，商業(yè)產(chǎn)品中EMC的Scale IO，Vmware的vSAN等，分布式塊存儲(chǔ)不適合容器場(chǎng)景，關(guān)鍵問(wèn)題是缺失RWX的特性。 分布式文件存儲(chǔ)：包括開(kāi)源社區(qū)的Glusterfs，Cephfs，Lustre，Moosefs，Lizardfs，商業(yè)產(chǎn)品中EMC的isilon，IBM的GPFS等。分布式文件存儲(chǔ)適合容器場(chǎng)景，但是性能問(wèn)題比較突出。 Local-Disk：有明顯的缺點(diǎn)，尤其是針對(duì)數(shù)據(jù)庫(kù)，大數(shù)據(jù)類(lèi)的應(yīng)用。節(jié)點(diǎn)故障后，數(shù)據(jù)的恢復(fù)時(shí)間長(zhǎng)，對(duì)業(yè)務(wù)影響范圍廣。 傳統(tǒng)NAS：也是一種文件存儲(chǔ)，但是協(xié)議網(wǎng)關(guān)（機(jī)頭）是性能瓶頸，傳統(tǒng)NAS已經(jīng)跟不上時(shí)代發(fā)展的潮流。
Kubernetes v1.9 引入的容器存儲(chǔ)接口CSI，并于v1.13版本正式GA。CSI的引入極大的增強(qiáng)了容器存儲(chǔ)生態(tài)體系，標(biāo)準(zhǔn)化容器平臺(tái)與外部存儲(chǔ)系統(tǒng)的集成。有狀態(tài)應(yīng)用不需要了解底層存儲(chǔ)系統(tǒng)的任何信息，只需將數(shù)據(jù)寫(xiě)入文件系統(tǒng)或塊設(shè)備的容器存儲(chǔ)卷，由容器平臺(tái)透明地處理存儲(chǔ)相關(guān)的編排與調(diào)度工作。
基于CSI實(shí)現(xiàn)的持久化Volume的創(chuàng)建和掛載流程如下：
1、用戶(hù)提交PVC，Kubernetes平臺(tái)自動(dòng)創(chuàng)建出PV 2、Kubernetes平臺(tái)將PV和PVC進(jìn)行綁定 3、部署Pod并使用已創(chuàng)建的PVC，Kubernetes將Pod調(diào)度到某宿主機(jī) 4、Kubernetes將PVC對(duì)應(yīng)的Volume進(jìn)行Attach到對(duì)應(yīng)宿主機(jī) 5、宿主機(jī)上的kubelet完成Volume的Mount操作
總的來(lái)說(shuō)，容器存儲(chǔ)方案的選擇，需要基于實(shí)際的業(yè)務(wù)需求出發(fā)，深刻理解容器平臺(tái)未來(lái)承載的業(yè)務(wù)類(lèi)型，如果基于云平臺(tái)構(gòu)建云原生平臺(tái)，盡量與IaaS底層保持一致，同時(shí)需要考慮團(tuán)隊(duì)的技術(shù)實(shí)力，開(kāi)源產(chǎn)品對(duì)技術(shù)能力要求比較高，選擇開(kāi)源產(chǎn)品，最好有相應(yīng)的技術(shù)人員儲(chǔ)備。如果技術(shù)儲(chǔ)備不足，最好是選擇商用產(chǎn)品，雖然成本高點(diǎn)但經(jīng)過(guò)了眾多企業(yè)的技術(shù)驗(yàn)證。
1.3.4 應(yīng)用管理的碎片化
資源對(duì)象及CRD，Kubernetes平臺(tái)開(kāi)放基礎(chǔ)
Kubernetes標(biāo)準(zhǔn)的資源對(duì)象超過(guò)一百多個(gè)，自下而上可以分為四層：資源層，實(shí)現(xiàn)網(wǎng)絡(luò)、存儲(chǔ)及基礎(chǔ)平臺(tái)等資源對(duì)象；調(diào)度層，實(shí)現(xiàn)各種調(diào)度控制器及調(diào)度等資源對(duì)象；隔離與服務(wù)訪(fǎng)問(wèn)層，實(shí)現(xiàn)資源限制與隔離、配置、身份、路由規(guī)則等資源對(duì)象；應(yīng)用層，實(shí)現(xiàn)應(yīng)用邏輯、服務(wù)定義、生命周期控制等資源對(duì)象；云原生平臺(tái)類(lèi)產(chǎn)品主要是在調(diào)度層擴(kuò)展，通過(guò)自定義CRD及控制器，實(shí)現(xiàn)Kubernetes的能力擴(kuò)展，比如邊緣容器，istio等。
CRD功能是在Kubernetes v1.7版本引入的，通過(guò) CRD 可以快速自定義 Kubernetes資源對(duì)象。CRD可以是命名空間的，也可以是集群范圍的，由CRD的作用域(scpoe)字段中所指定的，與Kubernetes內(nèi)置對(duì)象一樣，刪除名稱(chēng)空間將刪除該名稱(chēng)空間中的所有自定義對(duì)象?；贙ubernetes內(nèi)置對(duì)象與CRD就可以創(chuàng)建出千變?nèi)f化的組合；另外同一個(gè)資源對(duì)象又有多種實(shí)現(xiàn)方式，比如 Ingress就有10多種實(shí)現(xiàn)，PV就更不用說(shuō)，部分互不相干擴(kuò)展能力存在相互沖突及版本不兼容，一個(gè)生產(chǎn)運(yùn)行的Kubernetes容器集群，尤其是啟動(dòng)了Istio，Knative能力，CRD的數(shù)量是遠(yuǎn)遠(yuǎn)超過(guò)Kubernetes內(nèi)置對(duì)象，對(duì)于開(kāi)發(fā)者與平臺(tái)管理挑戰(zhàn)巨大。
從Helm到Operator，實(shí)現(xiàn)應(yīng)用全生命周期管理
云原生應(yīng)用日趨復(fù)雜，僅僅通過(guò)Kubernetes對(duì)象及Yaml很難清晰的描述一個(gè)復(fù)雜的應(yīng)用程序，所以誕生Helm與Operator。Helm 主要實(shí)現(xiàn)是云原生應(yīng)用打包和版本管理等。Operator本質(zhì)是一種調(diào)節(jié)器模式（Reconciler Pattern）的應(yīng)用，主要實(shí)現(xiàn)云原生應(yīng)用管理，尤其是有狀態(tài)應(yīng)用管理，協(xié)調(diào)應(yīng)用的實(shí)際狀態(tài)達(dá)到預(yù)期狀態(tài)。
Helm ：開(kāi)發(fā)非常容易，可以使用git倉(cāng)庫(kù)管理，運(yùn)維效率相對(duì)不高，用戶(hù)使用簡(jiǎn)單，開(kāi)源生態(tài)豐富。 Operator：開(kāi)發(fā)入門(mén)較難， OperatorHub搭建困難，運(yùn)維效率更高，用戶(hù)使用簡(jiǎn)單，開(kāi)源生態(tài)豐富
建議當(dāng)前考慮使用Operator作為容器應(yīng)用首選，社區(qū)有大量基于operator開(kāi)源實(shí)現(xiàn)支持各種中間件和應(yīng)用。同時(shí)也存在比較嚴(yán)重的碎片化問(wèn)題，在Helm hub上Kafka的chart多大十幾個(gè)，如果包含Kafka配置管理就更多很難選擇。Operator Hub稍微好點(diǎn)，Kafka有三個(gè)Operator供選擇。
OAM與KubeVela，走向標(biāo)準(zhǔn)與治理
OAM：Kubernetes的核心API資源比如Service、Deployment等，只是云原生應(yīng)用部分描述，所以衍生出Helm及Operator以應(yīng)用為中心，描述一個(gè)可部署的應(yīng)用，但是缺乏標(biāo)準(zhǔn)及規(guī)范，復(fù)用性差沖突難以排查處理，需要一個(gè)專(zhuān)注于應(yīng)用管理的、標(biāo)準(zhǔn)的、高度一致的模型標(biāo)準(zhǔn)與規(guī)范，所以就有衍生出了開(kāi)放應(yīng)用模型 Open Application Model （OAM），基于OAM實(shí)現(xiàn)應(yīng)用描述與基礎(chǔ)設(shè)施部署，管理應(yīng)用解耦，通過(guò)應(yīng)用組件（Components），應(yīng)用部署配置文件（Application Configuration），應(yīng)用運(yùn)維特征（Traits）實(shí)現(xiàn)平臺(tái)無(wú)關(guān)、高可擴(kuò)展的應(yīng)用描述能力。
KubeVela：是基于 OAM 標(biāo)準(zhǔn)實(shí)現(xiàn)的，面向平臺(tái)構(gòu)建者的、簡(jiǎn)單易用，高度可擴(kuò)展的開(kāi)源云原生平臺(tái)構(gòu)建引擎。目標(biāo)是讓任何平臺(tái)團(tuán)隊(duì)都能夠以Kubernetes原生的方式，快速、高效的打造出適合不同業(yè)務(wù)場(chǎng)景的、能夠直面用戶(hù)的云原生平臺(tái)出來(lái)。比如構(gòu)建應(yīng)用 PaaS、數(shù)據(jù)庫(kù) PaaS、AI PaaS 或者持續(xù)交付系統(tǒng)等。KubeVela開(kāi)發(fā)入門(mén)簡(jiǎn)單，環(huán)境搭建困難，混合云場(chǎng)景優(yōu)勢(shì)明顯，運(yùn)維效率高，但是處于生態(tài)發(fā)展初期。
總的來(lái)說(shuō)，Kubernetes原生的應(yīng)用原生比較標(biāo)準(zhǔn)，但是一些偏平臺(tái)的產(chǎn)品及應(yīng)用就相當(dāng)雜亂，大部分都只是借助Kubernetes 屏蔽了底層技術(shù)設(shè)施差異，對(duì)于上層的應(yīng)用來(lái)說(shuō)沒(méi)有什么變化。這些應(yīng)用大部分是傳統(tǒng)云時(shí)代PaaS平臺(tái)范疇的產(chǎn)品及應(yīng)用，還有少部分基于云原生技術(shù)及理念的新產(chǎn)品，企業(yè)及研發(fā)團(tuán)隊(duì)需要根據(jù)自己的需求，通過(guò)這些產(chǎn)品及應(yīng)用拼裝成一個(gè)面向應(yīng)用全生命周期的平臺(tái)，依然有大量的重復(fù)建設(shè)工作。
1.4 總結(jié)
對(duì)Kubernetes平臺(tái)及CNCF社區(qū)來(lái)說(shuō)，Kubernetes作為云原生的核心平臺(tái)，CNCF作為一個(gè)生態(tài)運(yùn)營(yíng)管理組織，要足夠開(kāi)放，滿(mǎn)足上下游個(gè)性化集成的需求，確保整個(gè)生態(tài)繁榮及良性競(jìng)爭(zhēng)，實(shí)現(xiàn)技術(shù)與平臺(tái)快速演進(jìn)，持續(xù)保持行業(yè)領(lǐng)先；同時(shí)也要去擁抱企業(yè)及開(kāi)發(fā)者的真正需求，解決當(dāng)前企業(yè)及研發(fā)團(tuán)隊(duì)平臺(tái)雜亂，投入成本過(guò)大，無(wú)流程難以管控的難題，真正助力企業(yè)實(shí)現(xiàn)業(yè)務(wù)價(jià)值。
對(duì)企業(yè)及用戶(hù)說(shuō)，“境”優(yōu)先，“器”其次，在云原生時(shí)代，面對(duì)復(fù)雜的平臺(tái)，繁榮且碎片化的生態(tài)，不要過(guò)度追求“神兵利器”，至少先掌握一種工具，能搞定問(wèn)題的就是好工具。