初识 Operator

最近，我们会经常听到云原生一词，各类博客都云原生的定义理解可能有稍许不同，很多也会把“云原生”与容器甚至“docker”强绑定，其实个人觉得“云”是底座，“原生”是能力化，那么简单说来就是充分发挥云服务能力的场景都可以理解为“云原生”的应用，而不仅仅局限于容器，甚至是“docker”，即用户通过 Terraform进行IAC这种声明式编码工具来发挥多云场景进行业务的应用也可以理解为云原生的一种应用。
回到正题，说到 Operator，关注过 kubernetes 的同学应该多多少少都听说过，那么究竟什么是Operator，它究竟能做啥，解决了什么问题，对于一个“新生”概念的衍生必然有其存在的意义，至少来说是解决了某些痛点。

Operator

首先我们举个例子，很多朋友可能通过 prometheus-operator 部署过 prometheus，也部署过istio等相关组件，但是这些资源类型是不是kubernetes内置的Resource呢？ 当然不是，那么kuberentes是如何知道存在这些资源，并只是通过声明式的描述（yaml描述）能够达到我们所“期望”的状态的呢。
Operator本质上还是对 CRD + Controller的组合。

CRD： custom resource definition。

用户可以自定义资源。也许有朋友会问，目前用kubernetes的内置资源很好的完成了我的应用部署维护，比如非常典型的无状态服务的部署与维护，一个deployment yaml配合service、configmap等内置资源也能完成生产需求。
是的，对于一般来说内置资源能够覆盖大部分的场景，但是如果对于特殊场景，我们如果需要定制化更多精简配置，而且对于这些精简的配置能够达到可见即运行时结果呢？举个简单的例子，如果需要持久化的组件，我们需要配置的文件相当繁琐，一个命名的不匹配就可能导致某个组件配置失败，那么原则上我们的应用因为某个依赖资源失败了那么整个服务其实就是一个失败状态，那么维护人员就不得不手动的去查找对应的故障，依赖越多，维护人员维护的成本就越大。
回到CRD，自定义资源实际上就是开发人员根据业务资源描述去声明对基础资源的各种充分应用，最简单的就是基础内资资源的组装，也可以根据自己的需求去实现自己的特定实现，最终告知kubernetes，并且让kubernetes能够认知且能够对其全声明周期的管理。

Controller

对于资源的扩展定义只是第一步，那么如何对其进行全生命周期的管控以及对业务需求的才是我们的最终目的。
kubernetes能够实现对资源声明式描述之后即达到配置即运行结果，最大的功劳就在于控制器。
控制器能够根据业务需求进行相关处理，我们说的最多的比如业务组件的可用状态检查，组件的备份，组件集群的扩缩容等等。
对于内资资源的组合使用，是无法做到依赖异常时自动化的监控与告警的，或者说最大化利用原生能力的优势。但是我们可以在 Operator 的控制层面，根据自己的定义需求灵活进行开发，以满足自动化的处理，最大化的发挥kubernetes的原生能力，使那些具备基础架构能力的开发者聚焦于发挥infrastructure层最大能力，同时为后续的维护提供最大化的支撑。