編者注：以下內容根據FIT2CLOUD飛致雲南區總經理遲曉強在5月27日“FIT2CLOU飛致雲在線講堂”的直播內容整理而成。點擊“閱讀原文”即可觀看完整版直播內容。
大家好，我是 FIT2CLOUD 飛致雲南區的遲曉強。今天跟大家分享一下我們公司一款全新的產品——KubeOperator。
說到FIT2CLOUD飛致雲，大家可能比較瞭解我們的雲管平臺產品，包括我們的JumpServer堡壘機，很多客戶和合作夥伴都非常瞭解。
我今天會跟大家分享一下，我們爲什麼會在雲原生基礎架構管理方面，即在Kubernetes領域，做KubeOperator這款產品？以及KubeOperator能解決什麼樣的問題？
我今天的分享分爲以下幾個方面：
一、雲原生與Kubernetes
二、企業落地Kubernetes面臨的挑戰
三、KubeOperator如何幫助企業應對挑戰？
四、KubeOperator的技術優勢
一、雲原生與Kubernetes
大家有時候會說，2019年是雲原生的元年。從2019年開始，或者說在2019前後，雲原生Kubernetes集羣基礎架構發展的非常迅猛，整個開源生態都非常好，我會跟大家聊聊在這段時間接觸過的客戶，包括我們在社區裏面的觀察，Kubernetes現在發展到了什麼情況？
第二個方面，現在一說起容器，一說起Kubernetes，沒有人不熟悉。我們也做了非常多的金融行業或者是某些行業的頭部客戶，跟他們聊聊在落地雲原生基礎架構，包括Kubernetes的時候面臨哪些挑戰？我們發現了客戶的問題後，才發起了KubeOperator項目，來幫助客戶應對這些挑戰。
首先跟大家聊聊雲原生。在2011年我剛開始接觸雲計算時，有一篇很著名的文章，提到軟件正在吞噬世界。我們以前做各種項目也好，或者企業的業務系統、企業的價值傳遞都會基於一些硬件或者基於一些手工來做，軟件確實是改變了傳統業務交付的方式。很多事情軟件定義了，也有很多事情通過軟件來取代了人工，取代了原來的物理環境。
隨着軟件不斷地發展，雲也到來了。雲完全利用了軟件，尤其是開源軟件這種普惠的技術，把很多這種基於軟件的方案快速地傳遞到了客戶側。雲也是一種非常普惠的技術，一個工程師、企業裏面的一個員工，甚至是個人，通過雲都能很快地獲取到想要的一些技術和方案。
對於雲原生來說，會涉及到非常多的領域，有剛纔我們說的雲原生的基礎架構，基於雲原生的上層的一些業務場景，以及一些雲原生的技術棧、微服務框架、一些API框架等。
所以現在看來，談雲已經不是一個特別時髦的詞了，談雲原生纔是一個更時髦的詞。
說到雲原生，大家會想起CNCF基金會（雲原生計算基金會）。CNCF曾經把雲計算按照時間軸拉開，我們能從中看到企業IT基礎架構的變遷。
針對每一個時間節點，CNCF列舉出來了每一個節點的代表性IT技術和代表性廠商。比如一開始的SUN，SUN產品的生命力真的很強。我們的一些銀行客戶，他們現在居然還要買這個產品的相關服務。包括VMware也是一樣，從2001年到現在，我們很多客戶都會用VMware虛擬化。
從2006年IaaS真正出現，AWS提供了IaaS的服務，提供了最開始由EC2、S3提供的服務。之後出現了Heroku PaaS平臺、OpenStack以及Cloud Foundry。
我剛開始工作的時候，就用的Cloud Foundry。它的設想是很好的，這個是一個純基於PaaS的平臺。通過這個平臺，你不用再關心底層的基礎架構，不用再關心計算存儲網絡是怎麼樣的。對於開發人員來說，只需要關心做我的Java的應用，只需要做相應的C#的應用，其他的你什麼都不用關心，實際上這是一個很美好的事情。
Cloud Foundry非常有侷限性，只能做Java和Web的應用等。後來容器出現了，Docker出現了。Cloud Foundry也在做一些方向性的轉變，它也在做基於雲原生、基於容器、基於Kubernetes的一些方案。現在大家都說，Kubernetes是主流，不管是從基礎架構的編排能力，還是它周圍的相應的生態，真的是處在統治級別的地位。
在中國，CNCF也有一個報告。這篇報告是2018年CNCF發佈的一個企業報告，報告講到單從中國市場來看Kubernetes，通過它在微信裏面的搜索的量能看出來，它比OpenStack的搜索量都要高。同時，我們也看到很多企業已經逐步在開發測試環節全面地上了Kubernetes的架構，他們也在規劃生產。作爲未來發展的一個趨勢，企業也會把雲原生實踐應用到生產環節。
無論是在方法論、技術棧，到實際的落地場景，到每一個工具的演變，Kubernetes都在圍繞着雲原生做着大量的實踐、突破與創新。
Kubernetes的概念也不光是做基礎架構的編排，我們能看到Kubernetes涉及到的整個生態會非常多。最簡單的一個就是Kubernetes是一套編排引擎，很多廠商、社區都會圍繞着Kubernetes做相應的事情。比如說對於Kubernetes基礎設施，我可以在計算、存儲、網絡做相應的Kubernetes插件，我們通過分佈式或者集中式的存儲，來支持Kubernetes集羣。
有一些廠商也在做Kubernetes的發行版，國內外有非常多的廠商說我要做一個更好的Kubernetes，做了一些優化，做了一些其他的東西。同時，我們會按照企業的一些要求相應地做一些上層的封裝，上層一些場景的展現，所以會做很多Kubernetes發行版。
同時，對於Kubernetes的應用開發，我們也有大量的工作可以做。比如說微服務的改造，做整個CI/CD的工具鏈，做整個流水線在傳統架構上CI/CD怎麼做？在Kubernetes容器雲的環境下CI/CD怎麼做？我們說做下一代New PaaS，基於Kubernetes的下一代PaaS平臺，它真的能做到通過容器來實現各種中間件、數據庫的服務，以及機器學習、AI服務。
還有一個領域也很重要。當大家都開始去實踐Kubernetes集羣，對於企業客戶的一個很大挑戰是什麼呢？很大的挑戰就是——我有非常多的Kubernetes集羣，有的是自己搭的，有的是公有云上的，甚至有的是通過第三方廠商，他們交付的時候就是通過Kubernetes集羣做交付的。
那麼對於Kubernetes集羣怎麼去統一的管理？以及有很多客戶，他們想要去做Kubernetes，第一步可能就卡住了，就是他怎麼去產生一個Kubernetes集羣？怎麼去快速創建一個生產級別Ready的Kubernetes集羣？這塊很大的工作量就在Kubernetes集羣的管理，這也是FIT2CLOUD飛致雲做KubeOperator這款產品的初心。我們會在這個領域裏爲整個生態貢獻一份力量。
剛纔說Kubernetes生態非常繁榮，對於企業級客戶來說，雲原生能力的建設會有非常多的選擇。比如計算、存儲、網絡、基礎架構、上層業務的一些場景，整個的CI/CD流水線，包括跟企業客戶對接時用戶租戶體系的建立等。
其實，雲原生能力建設真的無外乎兩種選擇。第一種就是All In One，可能像以前的運營商做項目交鑰匙，你什麼都不用管（理想狀態），我可以一站式幫你提供雲原生的能力，從底層的計算、存儲、網絡，到上層的Kubernetes生產環境的部署，包括上面的業務場景、CI/CD等，全幫你去做，其實現在已經有很多這樣的產品了。
**另一種就是解耦的方式。**我們要獨立地去建設，最簡單的一個事情就是單獨去建設一個Kubernetes集羣，也可以去分步建設，微服務改造怎麼做？DevOps流水線怎麼做？這是分開建設。
二、企業落地 Kubernetes 面臨的挑戰
其實上面的兩種思路都有很多挑戰，我們也根據CNCF對Kubernetes落地的時候做的一些調查來看一下。
這張圖裏就展示了容器技術真正落地會有哪些挑戰？
CNCF做了非常多的調查問卷，列舉出來了企業挑戰的一些優先級。
首先最大的挑戰是文化挑戰，尤其是開發團隊的挑戰。說白了對於我們來說，以前傳統的業務上線、基礎設施自然交互的方式在容器時代其實是有很大變化的。以前我們所關心的、開發關心的、IT關心的在現在可能會有一些變化。所以最大的挑戰就是文化，到底我們要不要用這個技術？用這個技術我需要做什麼樣的準備？我們的團隊需要做什麼樣的改變？
**第二個挑戰是安全合規。**我以前會經常說，任何一個新技術你最安全地談論它的方式就是談論它到底是否安全合規。
**第三個挑戰是過於複雜。**對於我們來說，容器的網絡、存儲的方案、集羣規劃的方案其實跟傳統架構有很大區別。所以很多時候一開始我們會發現很難快速地去掌握Kubernetes集羣。它過於複雜，我們原來的安全合規方案是否能在新的環境裏落地也是一個不小的挑戰。
其他的挑戰還包括缺少培訓、監控、網絡告警、日誌、存儲的問題，這都是容器技術在企業落地會遇到的一些挑戰。
我們去拜訪客戶的時候也會發現，有的客戶的典型畫像是，運維部門一直以來都在做VMware虛擬化的運維，做物理裸機的運維，甚至做傳統IDC機房的運維。**容器對他們來說的第一個挑戰就是過於複雜。**不知道該從哪裏去着手，去搭建一些Kubernetes集羣要學的東西會非常多。前期準備一些其他的東西，一些基於Kubernetes的知識，都會有很大的挑戰。
Kubernetes基礎架構落地也面臨很多挑戰。這個調查裏面列舉了一些大家最關心的問題，包括安全、網絡、存儲、監控，以及整個Kubernetes集羣的複雜度。它的日誌怎麼做？怎麼收集？怎麼展示？怎麼分析？它的高可用方案，涉及到Kubernetes集羣是單獨部署一個大的集羣，是否能通過Namespace等來做一些資源的隔離和劃分呢？還是說我會建非常多的小的Kubernetes集羣等？包括自動伸縮。這些都是Kubernetes在落地的時候會遇到的一些挑戰。
報告統計有幾個亮點。第一個亮點就是存儲。存儲往往是比網絡更重要的，我們接觸客戶的感受也是一樣，存儲比網絡更重要。到底選一個什麼樣的存儲的方案？保證Kubernetes集羣能夠穩定運行，保證I/O能隔離，Kubernetes之上我們要做一些New PaaS，比如說一個數據庫雲。它底下的存儲怎麼搞？存儲的I/O怎麼保證？怎麼做隔離？所以存儲往往在本地環境下更重要。
自動伸縮也非常重要。大家通常會比較關注在雲上的自動伸縮方案。但在本地環境中對於自動伸縮並不是這麼的關心。往往就只會伸，不會縮，這個就是一個很有意思的現象。我們有一個客戶在廣州，他的Kubernetes節點，第一次告訴我們的時候有200個節點，我當時就已經覺得很大了。過兩天跟他再聊，他說他們都快到300~400個節點了，他們只會去擴大規模。
所以，Kubernetes集羣在企業客戶內部落地也會有這樣的挑戰。大家也可以回想一下自己在學習Kubernetes，或者我們的企業在做容器雲的選型，在做Kubernetes基礎架構落地的時候是不是也會遇到類似的問題？比如說安全、網絡、存儲等。
剛剛說了每一個領域都會有哪些挑戰，但實際上它落地的時候，按照時間來看，任何一套系統、軟件、解決方案，要落地都會有這樣的一些挑戰。比如說Day0的規劃、Day1的部署、Day2的運營。Kubernetes集羣也是一樣的，它要在真實的企業環境落地，在時間軸範圍內也會遇到Day0規劃、Day1部署、Day2運營的問題。
**首先來看看Day0規劃。**這個Kubernetes集羣到底要部多大？是開發用還是生產用？如果是生產用要不要高可用？裏面部署的業務跟集羣怎麼樣做匹配？業務服務如何暴露？底層的存儲選哪些？甚至還有很多客戶會說，既然Kubernetes集羣是一套普惠的技術，是一套開源的方案，那它的底層操作系統是不是也是一套開源的操作系統，甚至是一個不收費的操作系統。
Day1部署包括Kubernetes集羣怎麼快速地構建起來，底下的這些節點怎麼快速地展示出來，是部署在IaaS上，那麼IaaS跟Kubernetes集羣怎麼聯動？有沒有一個可視化的界面？在快速部署的過程中如果遇到一些問題，能不能通過一個可視化的界面快速地去查看？這都是Day1部署的挑戰。
Day2運營是當我把Kubernetes集羣已經搭建好了，無論是前期規劃、開發測試還是生產，Kubernetes本身的版本迭代是非常快的，社區也很給力、也很火爆。那麼這個Kubernetes集羣要不要跟着社區去升級？也許下一個版本就能解決你當前的一些問題，下一個版本就能滿足你當前企業網絡的一些特殊要求。
我們也經常見到很多客戶，告訴我說，某一家容器雲廠商的網絡方案在他們企業客戶落地不了。原因就是他提供的Kubernetes綁定的某一個SDN方案在企業內部有一些問題。但真的有可能下一個版本支持的網絡插件就能解決這個問題。
所以在Day2運營層面，就會涉及到集羣如何無縫的升級，跟着社區的版本不斷的升級。集羣負載過大的時候，怎麼快速擴容？而不是說推倒重做。
或者像我們以前也遇到一些客戶，他用的是某個KVM的方案。他以前做擴容怎麼做的？真的有點刀耕火種，但這可能是一個普遍的情況。他會做到某一個版本的集羣升級時重新搭一套新的集羣，把它做擴容，擴容完了以後再把裏面的虛機一臺臺地挪過來，這樣效率或者說整個的可用性來說其實都不是非常的理想。
Kubernetes集羣也可以做到快速、無縫升級。所以Day2運營的一些問題，包括集羣真的上生產了以後怎麼做安全加固？怎麼做備份和恢復？這些都是真實的Kubernetes集羣落地的時候會遇到的挑戰。我們也做大量的這種分析，也學習了很多調研報告。那我們就提出來要在這個領域裏面貢獻我們的一份力量。所以我們就創立了KubeOperator這個項目，作爲一套純開源的方案，去幫助企業客戶應對前面說的挑戰。
三、KubeOperator如何幫助企業應對挑戰？
跟大家簡單介紹一下KubeOperator。前面也說了，一項新的技術要在合適的時間、合適的地點，遇到合適的人。KubeOperator也是在一個合適的地點、合適的時間誕生了。
KubeOperator是一套完全開源的方案，可在GitHub下載，也可以基於KubeOperator做一些開發。KubeOperator在GitHub也有一鍵安裝的腳本，大家可以去下載區試用，給我們提一些意見、問題。
**KubeOperator是由JumpServer開源產品的明星團隊打造的。**從JumpServer誕生到現在我們經歷了很多年，也積累了大量的企業級用戶，對於企業級軟件的需求有深入的理解。基於這些經驗和對企業級軟件的理解， JumpServer團隊又做了另外一款開源的產品，就是今天的KubeOperator。
KubeOperator基於Apache 2.0協議的，從開源的第一天起，項目的Star數量就一路上升。從這張圖可以看出來KubeOperator Star數量的上升曲線。說明在這個領域裏，有非常多我們的粉絲、企業級客戶、我們的雲管平臺客戶、JumpServer的客戶都在關注這個新的項目。如果大家在部署和使用中有任何問題，或者說有哪些Feature Request，我們都可以在Github裏討論。
在KubeOperator產品架構圖中，紅色框框起來的部分是KubeOperator的核心能力。
首先，KubeOperator基於Ansible和Terraform對接底層基礎設施資源。Ansible是做整個自動化，做一些任務的下發。Terraform是一個現在非常主流的IaC框架（Infrastructure as Code），它能快速地去調用底層IaaS的一些東西，實現VMware虛擬機的快速創建、OpenStack虛擬機網絡的快速創建等等。
通過Ansible和Terraform，KubeOperator對接本地NFS存儲、vSAN等，我們可以在物理機、vSphere、以及其他的一些虛擬機上，快速地搭建一整套的Kubernetes集羣。
同時，KubeOperator也內置對一些網絡插件、存儲插件的兼容。比如Flannel、Calico、NSX-T等各種軟件SDN方案，在KubeOperator中都可以快速落地。同時服務暴露發現方面，比如硬件的F5，軟件的Jenkins，我們都可以快速做一個Ingerss controller，幫我們做服務的發現。
基於KubeOperator，我們可以做到集羣的前期規劃，這個很重要，通過可視化的界面可以做規劃。同時，我們有集羣的快速部署，有集羣的後期的運維、管理，集羣無縫的升級、集羣快速的增加，集羣的備份，以及包括很重要的我們有一個應用商店。
這個應用商店，我們基於的是現在主流的應用打包規範，把這些應用在Kubernetes裏面快速地部署出來。我們可以提供一個Kubernetes as a Service，用戶可以通過KubeOperator管理一個或多個集羣。KubeOperator也有自己的權限體系、用戶租戶管理體系，可以讓不同的用戶去管理，或者去使用通過KubeOperator搭建出來的不同的集羣。
**如果用一句話總結KubeOperator帶來的價值，就是它可以在完全離線的情況下，通過可視化的方式，在物理主機上規劃、部署和運營生產級別Kubernetes集羣的軟件。**這是KubeOperator要做的事情。KubeOperator對離線環境的支持真的很重要的。我們有些客戶即使在內網可以訪問公網的情況下，在部署Kubernetes的時候都會遇到很多挑戰。
很多用戶在做Kubernetes集羣落地的時候遇到了挑戰，那麼KubeOperator能幫助用戶做些什麼呢？或者說KubeOperator到底有哪些能力？
第一，KubeOperator應對安全挑戰。
根據CNCF的報告，當Kubernetes集羣落地的時候，怎麼做權限的劃分和資源的隔離呢？報告發現了兩大主流方案。第一個方案就是大的集羣通過Namespace來做劃分；第二個方案是做非常多不同的小集羣。當然這兩種方案都會有很多呼聲，都有自己的一些優缺點。
KubeOperator首先能做到的是管理多個集羣。在管理多個集羣之上，提供一套租戶管理體系，可以跟企業內部的AD進行打通。在這套管理體系裏面，KubeOperator設定了幾個角色，首先會有一個超級管理員，他是做整個集羣的管理，包括後面的用戶權限的管理、資源的納入，比如擴容是不是要把VMware接進來，模板的管理等，包括系統的一些設置。
還有項目管理員。當你把某些集羣分給某一個項目，是開發測試環境還是生產環境，它會來做統一管理。
同時，還有一些只讀用戶。這個只讀用戶也很有意思，我們在客戶側發現，有很多行業的解決方案會基於Kubernetes來交付，會提供一整套Kubernetes，業務應用也加在上面，交付給最終用戶。所以我們也會規劃出來一些只讀用戶，來查看集羣的基本運行情況。只讀用戶只需要關心的是這個集羣是否正常運行，但更重要的是上層的業務是哪些。
另外，對KubeOperator創建的這些集羣或者納管的這些集羣，我們會對其做健康評分和安全合規的掃描。
集羣健康評分其實是基於Kubernetes集羣應用層面的一些評分。比如說，你到底有沒有設置固定的IP？你的文件系統是否是隻讀的？你的CPU、存儲器有沒有設定一些限制？你的標籤是否規範？網絡端口是否規範？這是從應用層面，Kubernetes集羣跑起來之後我們怎麼用它，這個層面進行評分。
無論是納管的還是創建的集羣，KubeOperator都會做一個快速的評分，看你是否滿足某些條件，全部都滿足肯定是A+，當你有些條件不滿足的時候，會有B或者D。當然，這個評分是基於一些主流對於Kubernetes集羣評測的要求進行應用層面的評分。
前面也講了，Kubernetes在企業內部落地有一個很重要的挑戰就是它太複雜了。光Master一個節點裏就有非常多的組件，每一個Node節點也會有很多，裏面還有非常多的網絡插件、存儲插件等等。組件非常多，當然它的每一個組件都有自己的部署和運行最佳實踐。
CIS（Center Of Internet Security）機構會專門對各種企業級軟件的每一個核心組件做檢查，對於Kubernetes也是。比如說Kubernetes中 API Server通信有沒有通過TLS加密？加密用的什麼協議？用的什麼加密制式？KubeOperator也會應用這個合規掃描，對已有Kubernetes集羣做一個全面的組件檢查。
大家如果感興趣的話，也可以用KubeOperator自己搭建一個集羣，做一個評分，看我們自己通過KubeOperator運維的集羣，是否能夠通過應用層面的健康評分，以及CIS安全合規的掃描。
第二，KubeOperator應對存儲挑戰。
企業客戶內部有非常多的存儲系統，集中式存儲、分佈式存儲、對象存儲等。Kubernetes集羣所需要支撐的存儲以前的版本是固定的，現在通過CSI接口，可以對應不同的存儲的方案。
左邊這張圖裏面展示了一個報告，顯示了當下大家對於存儲的使用方案都有哪些比較推薦的方案。排名靠前的很多是公有云服務商，比如說EBS、谷歌起草並且提倡的存儲編排框架Rook等。KubeOperator目前已經可以支持大量企業客戶購買的存儲方案，比如說對於獨立主機我們支持NFS、Ceph塊存儲，也支持NetApp的商業存儲方案。
在vSphere平臺中，KubeOperator支持vSphere Datastore，無論你是集中式的存儲還是分佈式存儲。OpenStack也是一樣的，我們也支持分佈式存儲或者是兼容的集中存儲。所以，KubeOperator可以在不同的環境裏提供不同的存儲的方案，讓你快速地基於某些存儲方案把Kubernetes集羣快速地部署和運營起來。
第三， KubeOperator應對網絡挑戰。
KubeOperator如何應對網絡挑戰呢？大家可以看下這兩個調研的結果。
右邊這張圖對Kubernetes上的網絡插件做了統計，比如Flannel、Calico。對於KubeOperator來說，已經可以內置支持Flannel和Calico方案。
從調研報告也可以看出，這兩個方案是非常主流的，也是大部分客戶會採用的網絡方案。不同的網絡方案有自己的優缺點，有的是QoS做得好，有的是隔離做得好，有的是性能做得好，當我們使用KubeOperator去運維集羣的時候，都會有相應的提示和圖形化的展示。同時，我們也在規劃去支持OVS網絡插件。所以，目前KubeOperator所包含的網絡方案已經覆蓋了絕大部分客戶的需求。
另一方面就是上層，也會有很多網絡層面的挑戰。企業內部跑的這些業務，怎麼去做服務的暴露和發現？一般的企業客戶都會使用F5，KubeOperator是支持用戶通過F5去暴露相應服務的。同時，對於軟件的方案，我們也支持兩個比較主流的方案，從這個報告裏也可以看出，是Nginx和Traefik。另外，CoreDNS作爲一個默認的選項，我們也提供支持。
第四，KubeOperator應對監控、日誌挑戰。
先談下 KubeOperator內置了應用商店。在左邊這張圖裏，我們看到整個Kubernetes生態裏關於應用打包的規範基本上已經統一了，都會用Helm。KubeOperator在運維Kubernetes集羣之上增加了應用商店，是支持Helm規範的應用商店。在應用商店裏面，我們內置了許多集羣管理的CI/CD，一些AI應用，支持一鍵部署。
當你通過KubeOperator創建集羣之後，在應用商店裏，只需點擊某一個應用，稍微改一下用戶名和密碼，就可以把這個應用通過Helm規範快速地部署在KubeOperator所管理的Kubernetes集羣之上。
KubeOperator的應用商店內置了非常多的應用，也給大家推薦了很多主流方案。比如說，應用商店內置了Prometheus，支持對集羣、節點、Pod、Container的全方位監控和告警。也就是說，你不用單獨再去部署Prometheus了，通過KubeOperator應用商店，一鍵點擊，有內置應用就可以做了。另外，還支持日誌分析和展示方案。Prometheus的監控數據可以通過Grafana做統一監控和麪板展示。
KubeOperator也支持消息中心，前面說的日誌、監控、告警，可以通過消息中心快速地推到釘釘、微信通知等。這個是在國內是非常適用的，真的是爲中國用戶的實際場景打造的。當你的集羣出現故障，集羣評分下降了，從原來的A、B下降到C、D了，我們也會通過釘釘、微信來通知。
四、KubeOperator的技術優勢
最後來總結一下KubeOperator的技術優勢，也可以說是場景化的優勢。
首先， KubeOperator是純Web UI，你甚至不需要一行代碼，不需要登錄後臺（安裝部署時需要登錄）。
除此之外，對於KubeOperator的任何操作都可以通過Web UI來實現，因爲它支持純離線環境。你不需要關心到底網絡通不通，你什麼都不需要關心，只需要下載我們的離線包，就可以在本地環境離線直接部署。
KubeOperator也支持按需創建。按需創建分兩部分。第一是底層的IaaS計算資源怎麼按需的創建？虛擬機怎麼按需創建？第二是上層的Kubernetes到底需要三個Master十幾個Worker，還是一個Master兩個Worker就夠了，都可以按需創建Kubernetes集羣。
KubeOperator還可以按需伸縮。更多的是按需地擴容，當我們負載過多的時候，我們快速地加一些Worker node加進去。
KubeOperator還支持與社區的Kubernetes版本同步，用戶可以快速升級Kubernetes集羣。比如說，我們現在已經到1.15、1.16了，後面還有比如1.20等。KubeOperator可以實現只要是通過KubeOperator部署的集羣，都可以快速地去升級。
另外，還有Multi-AZ的支持。當你的KubeOperator上生產了，或者你需要使用它的高可用性，我們是支持Multi-AZ的。可以把3個Master或者多個Master分佈在不同的AZ裏面。當你的KubeOperator運行在VMware上，或者你有多個VMware，可以把Master部署在不同的VC上。
KubeOperator還有應用商店，其中內置了大量的應用。因爲KubeOperator應用商店支持Helm開放協議，我們也可以把第三方的資源加入進來，更好地利用第三方的一些資源。
最後，KubeOperator支持GPU。大家都知道，Kubernetes天生對於GPU場景是非常適用的。KubeOperator所運營、部署的Kubernetes集羣可以支持NVIDIA的驅動，讓它在上面快速地去跑相應的機器學習或者GPU算例的工作負載。
最後，做一個簡單的對比。我前面說了這麼多，大家心裏應該也有一些體會，或者用過我們平臺的也會有一些體會。如果真正要把Kubernetes的基礎架構進行落地，你會有很多挑戰。要真的是DIY手動去做，無論是從時間成本、人力成本，甚至是到最後能不能搭建成功，其實都是一個未知數。但是通過KubeOperator，真的是可以實現四個小時之內的快速搭建，並且一個人就可以去維護它。
前段時間我們有一個客戶，在使用KubeOperator時，他就告訴我們，如果網絡通的情況下，花30分鐘一個人就能把整個Kubernetes集羣快速搭建好，並且後續的運營他一個人就能搞定。這就是我們所說的KubeOperator和DIY方式的區別。
今天的分享就到這裏，感謝大家能抽時間來聽我這次的分享，希望有機會在線下多交流。謝謝大家！