《深入剖析Kubernetes》总结七：Operator

权限控制

Kubernetes 中所有的 API 对象，都保存在 Etcd 里;
对这些 API 对象的操作，一定都是通过访问 kube-apiserver 实现的，其中一个非常重要的原因，就是需要 APIServer 来帮助你做授权工作；
在 Kubernetes 项目中，负责完成授权（Authorization）工作的机制，就是 RBAC：基于角 色的访问控制（Role-Based Access Control）。

RBAC：

1. Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。
2. Subject：被作用者，既可以是“人”，也可以是“机器”，也可以使你在 Kubernetes 里 定义的“用户”。
3. RoleBinding：定义了“被作用者”和“角色”的绑定关系。

在kubernetes中，Role 本是一个 Kubernetes 的 API 对象：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: mynamespace
 name: example-role
rules: #定义了规则
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "watch", "list"]

RoleBinding 本身也是一个 Kubernetes 的 API 对象：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: example-rolebinding
 namespace: mynamespace
subjects: #被作用者
- kind: User
 name: example-user
 apiGroup: rbac.authorization.k8s.io
roleRef: #关联的角色，即规则
 kind: Role
 name: example-role
 apiGroup: rbac.authorization.k8s.io

而被作用者，可以使用总结四里提到的ServiceAccount对象，Pod进行声明使用即可

Operator

在 Kubernetes 中，管理“有状态应用”是一个比较复杂的过程，尤其是编 写 Pod 模板的时候，总有一种“在 YAML 文件里编程序”的感觉，如果感觉不适应，则可以使用相对更加灵活和编程友好的管理“有状态应用”的解决方案：Operator

以Etcd Operator为例

Etcd Operator 需要访问 Kubernetes 的 APIServer 来创建对象。因此首先要创建RBAC规则：

$ example/rbac/create_role.sh

其工作原理为：

实际上是利用了 Kubernetes 的自定义 API 资源（CRD），来描述想要部署的“有状态应用”；然后在自定义控制器里，根据自定义 API 对象的变化，来完成具体的部署和运维工作

Etcd Operator 的启动流程也是围绕着 Informer 展开的；
Etcd Operator首先创建 EtcdCluster 对象所需要的 CRD；
接下来Etcd Operator 会定义一个 EtcdCluster 对象的 Informer；

而业务逻辑的实现方式则如下：

Etcd Operator 的特殊之处在于它为每一个 EtcdCluster 对象，都启动了一个控制循环，“并发”地响应这些对象的变化。

当 YAML 文件第一次被提交到 Kubernetes 之后，Etcd Operator 的 Informer，就会立 刻“感知”到一个新的 EtcdCluster 对象被创建了出来，EventHandler 里的“添加”事 件会被触发；
Handler则在 Etcd Operator 内部创建一个对应的 Cluster 对 象（cluster.New），比如流程图里的 Cluster1。

而一个 Cluster 对象需要具体负责的有两个工作：
1 只在该 Cluster 对象第一次被创建的时候才会执行创建一个单节点的种子集群
2 启动该集群所对应的控制循环，控制循环每隔一定时间，就会执行一次 Diff 流程，即实际状态和期望状态的对比

如果现在要部署的应用，既需要用 StatefulSet 的方式维持拓扑状态和存储状态，又有大量的编程工作要做，那么可以编写一个 Operator，然后在 Operator 的控制循环里创建和控制 StatefulSet 而不是 Pod