Coreos Operator
1. 零
Operator 是什么?
如果你还没有看过 coreos 的 operator，可以到 这里 进行一个短暂的阅读
2. 一
目前的 operator 是一个处于实验性、尚不成熟的运维经验流程化的方法论
3. 二
4. 三
拿 etcd-operator 来说，他实际上做了什么呢
1.输入 版本与集群规模创建/删除一个 etcd 集群
2.调整一个集群的大小
3.在 pod 意外丢失时重现创建
4.oprator 在被删除后的恢复 (与 4 相同)
5.升级 etcd 的版本
6.备份和恢复 etcd 集群
看起来是符合 operator 中描述的能力,但实际呢
实际上他仅能满足字面上的最小能力
如果我需要的的是仅在特定几台机器(小于集群规模且无统一标签)上的 etcd 集群呢？
如果我要在更换 etcd 的证书呢
如果我要将备份的数据存储到非 aws 的存储呢
有太多他做不到的事情了
5. 四
可能会有人认为,太多的自定义需求只要实现一个符合自己需求的 operator 不就可以了吗？
那么思考下面几个问题
1.谁来写这个 operator
2.写好了 operator 之后就能满足未来所有的需求吗
3.这个 operator 如何进行交接
6. 五
假设有这样一个人，有着丰富的运维经验，又愿意遵循着这样的规范来完成一个 operator
在一个人可以将运维经验抽象成一个 operator 这么长的时间内，他连一个用来简化操作的的脚本都没有写过吗？
当他学习了 operator 的 sdk 然后，将自己平时使用的脚本中的逻辑以 operator 的方式放到了集群中
新来的同事问他，这个服务该怎么运维啊
他会说
A.你看一下这个服务 operator 的使用文档
B.你要先明白这个服务的配置文件该怎么写
7. 六
operator 最大的矛盾是减少运维学习成本与保障服务稳定必须足够了解之间的矛盾
开发人员应该对写的代码负责，同样的是运维人员也要对维护的服务负责
operator 在以一种开发人员的视角做运维人员的工具
它是开发人员心中臆想的美好工具，妄图以程序来运维程序
这是在对与程序或系统足够的熟悉下，形成的盲目判断
运维人员的价值很多时候体现在预想之外的情况下作出最正确的决定
重要的决定需要人来作为最后一道关隘
也许它想构建心中的理想国，但它不能要求整个世界都能认同苏格拉底的观点
8. 七
有时间搞这些有的没的，不如多加两个监控告警实在
9. 参考资料
https://coreos.com/operators/prometheus/docs/latest/
https://coreos.com/blog/the-prometheus-operator.html
https://coreos.com/operators/etcd/docs/latest/
https://github.com/coreos/etcd-operator/
https://github.com/operator-framework/operator-sdk
https://github.com/operator-framework/operator-lifecycle-manager
https://github.com/operator-framework/getting-started
https://github.com/operator-framework/operator-sdk/blob/master/doc/user-guide.md