Kubernetes Operator，为生产运维做好准备

作者： Michael Haigh (NUTANIX), Rahul Dabke (D2iQ)

本文由D2iQ负责整理翻译

大多数时候，企业在Kubernetes上部署有状态的数据服务是需要人工干预的，所以常常会出现一些问题。Operators正是解决这些问题非常有效的模式，而且Operators还可以协助管理应用的生命周期，将Kubernetes的协调水平提升至新的层次。

为了打造一个满足生产水平的Operator，开发者常常要编写数万行的代码。编写、管理，然后实施大量的代码是非常繁重而艰苦的工作。编写一个Operator要求对底层服务和Kubernetes有深入的理解。尽管Kubernetes的数据服务Operators和底层服务有共通之处，但是由于不同的编排也使实施具有显著的差别。企业需要的是一套打包好的Operator，用来简化对任何Kubernetes集群的部署和管理。

用Helm还是不用Helm？

Helm是首个在Kubernetes上运行的应用包管理器，可以解决在Kubernetes安装服务的需求，但却不包括全生命周期管理。Helm Chart仅为打包工作负载和部署提供基本的功能。大多数的开发者在刚开始使用时会觉得很好用，但对于规模较大的环境就会发现Helm Chart难以管理，也不适用于有状态数据服务的部署。相反，Operator包含了应用的整个生命周期，从部署到升级，以及恢复、扩展等。

Operators由谁来搭建？如何搭建？

开发者需要搭建Operator，尤其是在分布式计算系统部署有状态数据服务的时候。在Kubernetes的测试阶段（Day 0），部署大多是围绕无状态应用的。实际上，Kubernetes能够很好地管理无状态应用，难点是在部署基于Kubernetes的有状态应用和工作流，比如数据库、信息队列等，而且需要大量的人工介入。有状态应用是程序化的，要求更多手动工作，生命周期管理也有难度。然而，Operator可以很好地实现有状态数据服务部署，还能高效管理应用的生命周期。

Operator帮助独立软件厂商（ISV）将Kubernetes上的产品操作自动化，用户无需具备Kubernetes相关的专业技能。早期有ISV们曾尝试编写Operator，但最终只做出了脚本。部署Operator有不同的方法，但经常还是停留在Kubernetes初级集成水平。除了要编写上万行的代码、与Kubernetes API周旋之外，开发者还需要知道什么时候这些API会发生变化以及是否会发生故障。作为一个开发者，除了面对以上所有这些挑战，还要需要针对集成测试、RBAC配置、存档整合解决方案。

Operator SDK现状

在开发者和用户的共同努力下，Kubernetes Operator生态系统正在快速发展。 Operator生态系统中的杰出方法包括：

Prominent

1、Kubernetes通用声明性框架Operator；

2、Google云平台的Kubebuilder；

3、CoreOS的Operator SDK。

通过Operator SDK框架，开发者可利用Ansible、Helm Charts或Go搭建Operator。Operator SDK要求透彻掌握Kubernetes API，编写一个Operator也需要大量的代码。Kubebuilder为通用Operator模式提供了模板和解决方案。KUDO Operator则是被编写为模版化的YAML文件，只需要实施极少量的代码。

Operator可以部分解决基于Kubernetes部署有状态数据服务的难题，有助于建立起若干个数据服务，在后期的支撑中减少人工干预。在不同的Operator方法中，编写代码的水平也不尽相同，因此管控水平也不一样。