编者注：以下内容根据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方式的区别。
今天的分享就到这里，感谢大家能抽时间来听我这次的分享，希望有机会在线下多交流。谢谢大家！
