在 Operator 里,你提交的 API 对象不再是一个单体应用的描述,而是一个完整的分布式应用集群的描述。这里的区别在于,整个分布式应用集群的状态和定义,都成了Kubernetes 控制器需要保证的“终态”。比如,这个应用有几个实例,实例间的关系如何处理,实例需要把数据存储在哪里,如何对实例数据进行备份和恢复,都是这个控制器需要根据 API 对象的变化进行处理的逻辑。
从上述叙述中,你就应该能够明白, Operator 其实就是一段代码,这段代码 Watch 了 etcd 里一个描述分布式应用集群的API 对象,然后这段代码通过实现 Kubernetes 的控制器模式,来保证这个集群始终跟用户的定义完全相同。而在这个过程中,Operator 也有能力利用 Kubernetes 的存储、网络插件等外部资源,协同的为应用状态的保持提供帮助。
所以说,Operator 本身在实现上,其实是在 Kubernetes 声明式 API 基础上的一种“微创新”。它合理的利用了 Kubernetes API 可以添加自定义 API 类型的能力,然后又巧妙的通过 Kubernetes 原生的“控制器模式”,完成了一个面向分布式应用终态的调谐过程。
etcd operator管理部署到Kubernetes的 etcd集群,并自动执行与操作etcd集群相关的任务。
获取github上最新的Etcd-Operator代码。
将其example目录上传到k8s master相关目录。
运行rbac目录下的create_role.sh脚本,创建基本的rbac角色。
将如下三个镜像导入harbor仓库备用。
1, xxxx/3rd_part/quay.io/coreos/etcd-operator:v0.9.3
2, xxxx/3rd_part/busybox:1.28.0-glibc(initial container需要)
3, xxxx/3rd_part/k8s.gcr.io/etcd-amd64:v3.1.12(根据具体情况调整)
运行example目录下的deployments.yaml文件,建立operator的deployment。
运行example目录下的example-etcd-cluster.yaml文件,建立etcd集群。
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
name: "xxx-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: 1
version: "3.1.12"
repository: "harbor/3rd_part/k8s.gcr.io/etcd-amd64"
pod:
busyboxImage: "harbor/3rd_part/busybox:1.28.0-glibc"
验证。
1, 生成一个临时pod
kubectl run --rm -i --tty fun --image k8s.gcr.io/etcd-amd64:v3.1.12 --restart=Never -- /bin/sh
2, 在此pod里运行如下命令验证
ETCDCTL_API=3 etcdctl --endpoints http://etcd-cluster-client.default:2379 put foo bar
3, 返回OK结果即为OK。
4, 如果需要集群外访问,可仿如下yaml开通nodeport。
apiVersion: v1
kind: Service
metadata:
labels:
name: xxx-etcd-cluster
name: xxx-etcd-cluster
spec:
ports:
- port: 2379
targetPort: 2379
selector:
name: xxx-etcd-cluster