如何开始编写K8s操作符
操作员是新的热门话题。有很多可供选择的。他们可以帮助你管理你的服务和照顾你的集群。
但是，并不是所有的操作符都适用。你的组织可能有一个自定义的操作员用例。或者你正在自己开发一项服务，在那里，运营商模式可能是有意义的。不管是哪种情况，都有很多事情需要首先考虑。以下是我们在开始使用运营商时的一些注意事项。
1.你真的需要一个运营商吗？
有很多方法可以安装服务或管理集群中的组件。决定编写你自己的操作员是一个大问题。除了实现所有的功能外，你还得考虑管理运营商本身，操作你的运营商和修复错误。操作员也许能够解决你的问题，但你也只是增加了一个你现在完全拥有的组件。
替代方案可以是。
- 检查是否已经有一个好的运营商在做这项工作了
- 你的CI/CD能否很好地处理这项工作？
2.注意操作者的目标和目的
不要编写一个什么都能做的操作者。操作员应该是一次只能照顾一个问题。例如，"为我管理Redis集群的生命周期"。
另外，根据目标，尽早决定你的操作符是否可以在一个命名空间内使用，或者是否需要在集群内使用。
3.3.利用操作符框架
有一个用GoLang编写的操作符框架sdk会给你带来很大的帮助！ 让自己熟悉设置和使用操作符框架。最初让它做一些非常简单的事情，然后从那里开始。
操作员SDK有一些重要的值得注意的功能。
观察资源
利用该框架，您可以轻松地观察资源，并对变化做出相应的反应。这通常是触发调和循环的方式。
比如说
//+kubebuilder:rbac:groups=apps,resources=deployments,verbs=get;list;watch;patch;update; func (r *DeploymentWatcher) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { // Do your magic return ctrl.Result{}, nil } func (r *DeploymentWatcher) SetupWithManager(mgr ctrl.Manager) error { return ctrl.NewControllerManagedBy(mgr). For(&v1.Deployment{}). Complete(r) }一个非常基本的结构。有了正确的RBAC，只要集群中的任何部署有变化，就会触发Reconcile()。
Reconcile
这是你的主循环（或循环，可以有多个），可以被各种不同的控制器触发，这些控制器反过来可以观察资源。在调和中，你正在决定应该发生什么，或者是否应该发生任何事情。在你的调节循环结束时，你很可能会改变集群中的一些东西，处理错误并向度量、日志和事件报告。
客户端
当然，也有一个与集群API本身互动的客户端。你可以用客户端做所有常见的事情，如列表、获取、更新、删除，它将是你与集群对话的方式。还有一些有用的方法，比如框架可以提供的重试机制。另外，客户端是缓存的，这有助于你不至于过多地滥用你的实际集群API。
该框架本身是开源的，并且有一个非常活跃的社区，如果你遇到任何问题，有许多例子、指南和有帮助的成员。
如果GoLang不是你的那杯茶，我们实际上有我们自己的基于Java的运营商SDK。
4.使之成为开放源码
真的。做到这一点。
开源你的运营商只会有好处。在开发运营商时一定要考虑到第三方的使用、采用和开发。所以基本上你的受众将是 "所有人"。你也会从别人的伟大反馈、错误报告和拉动请求中受益。
如果有一个功能是专有的，要考虑如何将其通用化和抽象化，以便使其成为开源的。
5.尽早决定你想支持的k8s版本和发行版本
尽早决定你是否要支持多个发行版，如果是的话，是哪些。(例如OpenShift)。尽量减少特定发行版的代码，同时还要符合所有发行版的要求。在早期花一些时间找到一个尽可能普遍适用于所有发行版的解决方案。这将使你以后的生活更轻松。
6.假设事情可能而且会 出错
在分布式系统中，任何事情都可能发生。输入可能丢失、不完整或配置错误。操作员可能突然不能工作了，因为有人删除了它的角色。或者操作者可能依赖于一个没有正常工作的前一个步骤，从而将问题连带下去。
其他领域不一定是你的操作员的错。例如，当集群的API开始节流或拒绝你的请求时会发生什么？当API需要比平时长3倍的时间来响应时会发生什么？(提示：事情可能 出错)
验证你的输入和行动是否是他们应该做的。总是假设事情可能出错，并在你的代码中添加适当的错误处理和恢复方法。没有什么比操作者做了不应该做的事情更快侵蚀对你的信任了。
7.测试测试测试
编写适当的单元和e2e测试，并将其集成到你的CI中。幸运的是，运营商框架可以帮助你做到这一点。它提供了一个测试套件，可以使用一个假的api（如果你愿意，也可以是真的），有不同的阶段、测试表、评估等（EnvTest）。最流行的测试框架是ginkgo和omega的组合，它也很好地与operator sdk集成。
测试你的操作员的工作流程和行为对于检测边缘案例和处理它们非常重要。随着新功能的出现，你的操作员的形状会改变，行为也会改变。通过测试有一个接地气的评价和肯定会对你有很大的帮助。特别是当你在一个团队中工作时。
8.简化你的CRD创建和部署
保持所有这些东西大部分是自动化的。我想到了Kustomize或Helm。有一个坚实的框架来让你的操作员进入集群并工作，不仅在开发过程中对你有帮助，而且对其他采用该操作员的人也有帮助。
(操作运营商的人将会感谢你！）。
9.权限和文档
操作员很强大，他们经常在集群层面上生活和工作。有了巨大的权力，就有了巨大的责任。你不仅需要将你的RBAC权限保持在最低限度，而且你还需要详细描述你的操作者的行为。详细说明你的操作者的目标是什么（这又回到了第1点），并描述它做什么，还有它不做什么。对第三方来说，运营商的边界是很重要的。
10.遵循12要素应用原则
运营商是一个完美的例子，12因素应用原则可以很容易地应用于此。他们会使你的运营商更有弹性，更稳定，更容易工作。总是假设其他人和第三方会使用运营商。因此，它应该在支持它的地方很好地整合，而不需要过多的定制。
---
这肯定不是全部。另一个好的资源是运营商的最佳实践。
但我相信最重要的是这一点。只要开始实验并获得乐趣就可以了!
