你可能听过Kubernetes中Operator的概念，Operator可以帮助我们扩展Kubernetes功能，包括管理任何有状态应用程序。我们看到了它被用于有状态基础设施应用程序的许多可能性，包括版本升级、节点恢复、调整集群大小等。
本文我们将揭开Operator的神秘面纱，为如何构建可应用于实际的自定义Operator打下坚实的基础。
为了说明operator到底是什么，让我们回到Kubernetes的架构上来，Kubernetes本质上是理想的状态管理器。你为你的应用程序提供了所需的状态（实例数，磁盘空间，使用的镜像等），并且如果任何事情失控，它都会尝试保持该状态。Kubernetes在Master节点上使用控制面，控制面包含许多控制器，这些控制器的工作是按照下面的方式与期望的状态进行协调（Reconcile）:
- 监视现有的K8S对象（pods,deployments等）去确定他们的状态
- 比较该对象和它的K8s yaml配置
- 如果状态和配置不同，控制器将尝试进行修复（remedy）
进行协调的一个常见的场景是：
一个pod被定义了三个副本，当一个挂了，K8s控制器的监视（watching）下，它意识到应该运行三个pod,而不是两个，然后，它将创建一个新的pod实例。
下图简单展示了控制器在K8s架构中的作用：
- kubectl CLI发送一个对象配置(Pod,Deployment等)到Master Node的API Server以便在集群运行
- Master Node将调度（schedule）对象去运行
- 一旦运行，一个控制器将持续件事这个对象并根据它的配置不断协调（Reconcile）
通过这种方式，Kubernetes方便的代替了大量手动工作，以维护运行时的无状态应用。然而，它仅限于K8S预定义的对象类型（Pod，Deployment,Namespace,Service,DaemonSet等），这些对象类型中的每一个都具有预定的行为和方式，如果它们和配置发生了偏离，他们就会与配置相协调（Reconcile），以达到所期望的配置。
现在，如果您的应用程序有更多复杂性，那么你需要自定义Operator以将达到期望的运行状态。
我们考虑一个有状态的应用程序，有一个运行在多个节点上的数据库应用程序。如果大多数节点出现故障，则需要按照特定步骤从指定快照重新加载数据库。使用Kubernetes中现有的对象类型和控制器，这是不可能实现的。再考虑节点扩容，升级新版本，或为我们的有状态应用程序进行灾难恢复。这些类型的操作通常需要非常具体的步骤，并且通常需要手动干预。
Kubernetes Operators允许你定义一个自定义控制器来watch你的应用程序并根据其状态执行自定义任务，从而扩展了Kubernetes（这是使我们上述的有状态应用程序自动维护的完美选择）。
你想要watch的应用程序在Kubernetes中被定义为一个新对象，一个CR（Custom Resource），它有自己的yaml spec和被API Server理解的对象类型（kind）。这样，你可以在自定义spec中定义任何需要关注的特定标准，并在实例与期望不匹配时进行协调。虽然Operator Controller主要使用自定义组件，但是它的spec和本地Kubernetes的控制器非常相似。
Operator 运行自定义控制器以协调spec。虽然API server能感知到自定义控制器，但是Operator是独立运行的，可以在集群内部或外部运行。
由于Operator是有状态应用程序的强大工具，因此我们看到CoreOS和其他贡献Etcd,Prometheus等提供了许多Operator，而这些是一个伟大的起点，但是Operator的价值实际上取决于你对它的处理方式：针对故障的具体做法是什么？以及Operator的功能如何与手动干预一起使用。
尝试构建Operator：
- 定义我们要watch的应用程序的自定义资源CR spec以及该CR的API
- 编写一个Custom Controller来监视我们的应用程序
- 新控制器中的自定义代码，让我们知道如何使我们的CR与spec一致。
- 管理自定义控制器中的Operator
- 为了Operator和CR的一个Deployment
以上这些都可以通过手动编写go代码和spec来实现，同时我们可以使用kubebuild、operator-sdk来生成骨架代码，让我们更方便的去关注核心代码的编写。
参考文章：
https://www.linux.com/topic/cloud/demystifying-kubernetes-operators-operator-sdk-part-1/