支持虚拟化的Kubernetes Operator框架
公有云和私有云的区别
很多开发人员喜欢使用公有云，因为公有云资源的申请简单、快速，随时可以获得虚拟机、数据库、大数据集群，甚至Kubernetes集群，更重要的是公有云不需要运维，开发人员不需要担心资源不够开不出虚拟机，或者数据库的磁盘满了不能服务等情况。所以，大型的企业都希望能够建设一个类似公有云的私有云环境，既可以快速灵活的满足用户的需求，又可以保留控制力和合规性。
公有云真的不需要运维吗？当然不是，只是因为公有云的供应商做了大量的工作，将繁琐的运维工作和最终用户屏蔽起来。而这些对于种类繁杂云服务运维工作的knowhow，正是公有云和私有云之间的主要差异之一。公有云的厂商在长期的运营过程中积累了大量对于各种云服务的运维知识和经验，并将其沉淀为自动化的工具，这正是私有云建设者缺乏的。私有云的运维团队无法在短时间内积累多种服务的运维实践，所以无法快速的根据用户的需求添加云服务，无法在出现故障时及时的恢复，从而使内部的用户转向了公有云。
在传统企业环境中，软件本身的交付和它的维护实践是分开的，运维团队需要自行积累经验，或者按照最佳实践文档进行配置。如何运维一个软件，最权威的一定是软件厂商自己，但是厂商通常很难将自己经验无损的传递给客户的运维团队，只能通过人天服务的形式帮助客户，这种模式很难支持大规模用户群体。由于缺乏规范的指导手册，此类情况在开源领域更加明显。公有云的供应商使用自己经验提供开源软件服务给用户，但是开源软件供应商确无法获益。所以，不断有开源软件厂商修改开源协议，试图避免公有云绕过自己提供服务。
什么是Kubernetes Operator？
Kubernetes Operator模式的出现为软件厂商和私有云建设者带来了好消息。Operator可以将软件和它的运维的最佳实践打包到一起，同时部署在用户环境中。在安装软件的同时，也将运维的领域经验标准化的交付给客户。
Operator利用了Kubernetes框架的可扩展性。软件厂商可以定义自己软件的CRD(customresourcedifinition)和controller。CRD代表着软件，controller通过监控和调整软件的运行状态来传递经验和最佳实践。
以etcd为例，
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
name: "example-etcd-cluster"
## Adding this annotation make this cluster managed by clusterwide operators
## namespaced operators ignore it
# annotations:
# etcd.database.coreos.com/scope: clusterwide
spec:
size: 3
version: "3.2.13"
用户创建一个“EtcdCluster”后，Kubernetes会按照要求创建相应的POD组成集群。后续etcd的controller会实时监控etcd集群的运行情况，接管集群的升级、扩缩容、备份恢复、故障处理等运维操作。controller会决定在什么条件下需要扩容，什么条件下需要备份，如果需要升级的时候需要按照什么步骤自动执行等和运维相关的操作。
Operator框架的强大之处就是允许用户开发一个应用程序管理另一个应用程序。是不是有点RPA(Robotic Process Automation)的意思，让机器人代替了人工的运维。
controller就是软件厂商传递给客户的运维经验。软件开发商可以不断升级Operator的能力，实现从基础安装(basic install)，无缝升级(seamless upgrades)，全生命周期管理(full lifecyle)，智能分析(deep insights)，全自动化运维(auto pilot)的演化路径。
什么是VM Operator？
Operator的理念非常好，它是在Kubernetes生态系统中发展起来的，所以目前只能支持服务和controller以容器的形式部署。但是在企业环境中有很多应用和服务，还是需要运行在虚拟机中，比如说sqlserver的供应商认为，sqlserver的集群现阶段还是应该运行在虚拟机中。那么如何使Kubernetes Operator支持虚拟机呢？VM Operator的出现就是为了解决这个问题。
VM Operator是VMware提供的可以通过Kubernetes API在vSphere环境中管理虚拟机的技术。开发人员可以声明式的在yaml文件中描述虚拟机，VM Operator驱动vSphere环境创建和管理虚拟机，以Kubernetes原生的方式管理虚拟化环境。
kind: VirtualMachine
apiVersion: v1
metaData:
name: apache-spark-instance
spec:
virtualMachineClass: small-with-gpu
virtualMachineImage: apache-spark-template
hostname: “Sparky” # Guest customization config specified on Pod
ports:
- containerPort: 80
name: "spark mgmt"
policy:
restartPolicy: “OnFailure”
结合Kubernetes Operator和VM Operator，软件厂商可以以任意的形态提供软件和经验的交付。etcd的厂商可以提供全容器化部署的Operator，sqlserver的厂商可以提供全虚拟化部署的Operator，合作伙伴可以提供容器与虚拟机混合部署的应用的Operator。重要的是这些Operator都是符合同一个标准的，可以统一管理。
企业私有云建设的新思路
通过以上的技术，企业在建设私有云的时候只需要搭建一个“底座”，不同的软件供应商和合作伙伴以Operator的形式将自己的软件和经验，无论以容器还是虚拟机的格式，配置成为服务目录中选项，用户按需申请使用，后台自动运维，形成一个私有云软件交付的生态系统。私有云“底座”的建设者 + 云服务供应商 + 云消费者。
- 对于“底座”的建设者来说，纯资源管理的工作相对简单，有成熟的套路。以最小的代价打通软件供应商进入企业环境的通道。“底座”可以统一管理不同云服务的授权和计量计费。一个真实的例子，美国一个用户由于在私有云环境中无法统一管理一个license软件的授权，造成license滥用，每年损失超过100万美金（该用户对license的合规做的真不错！）。
- 对软件供应商来说，可以将自己的knowhow打包成产品卖给客户，同时由于Operator是标准的格式，可以在不同的云“底座”上发布，不会与“底座”绑定。
- 对于最终云的使用者来说，不管是服务种类还是使用感受，都是类似公有云的。
那么企业私有云建设需要什么样的“底座”呢？
- 首先，需要兼容Kubernetes API，使得Operator可以部署。
- 其次，兼容容器和虚拟机，可以通过Kubernetes API创建容器或者虚拟机，从而在更多场景下，提供更广泛的云服务。
- 作为云平台的基础，需要有广泛的硬件生态系统，和成熟企业环境运行的经验。
- “底座”需要提供完善的租户管理、权限控制、配额管理等通用的资源管理机制，使软件供应商只需关注在自己提供服务的业务逻辑上。
如果您认同以上企业私有云建设的思路，并且在寻找符合条件的“底座”，敬请留意本周VMworld上发布的黑科技 Project Pacific。
技术细节可参考，容器与虚拟化的完美融合 - VMware Project Pacific
