如果没有真正的自动化，你就无法充分发挥容器的潜力。这就是Kubernetes Operator越来越重要的原因。
Kubernetes的一个关键优势是，它使现代应用程序和基础设施带来的许多运维工作实现自动化。而Kubernetes Operator被认为是实现这一优势的重要手段。
什么是Kubernetes Operator？
让我们回顾一下，什么是Kubernetes Operator，并给出它们如何工作的示例。
“Operator是控制用户资源的Kubernetes API的客户端。”Nexient的DevOps主管Matthew Dresden说，“此功能通过监控事件而不编辑Kubernetes代码，实现部署、备份和升级等任务的自动化。”
这是一个重要的功能，尤其是在运行容器化的工作负载和服务时——这是一条实现在Kubernetes上运行的应用程序更完全自动化的途径。
正如红帽产品经理Rob Szumski在博客中指出的那样，“Operator的关键属性是对应用程序的主动、持续管理，包括故障转移、备份、升级和自动缩放，就像云服务一样。当然，如果你的应用程序不存储状态数据，则备份可能不适用，但日志处理或警报会很重要。Operator的用户体验目标是通过专家提供的知识获得类似云的自我管理体验。”
如果你不能完全自动化，那你就浪费了容器和其他云原生技术的潜力。
举个例子
Nexient的Dresden分享了一个Operator工作的场景：“如果Kubernetes检测到一个节点的丢失，Operator可以自动地从另一个在Kubernetes中运行的集群节点复制数据，同时保持一个法定数，使集群返回到期望的奇偶校验级别。”这个例子可能相当简单，但其意义不小。
Dresden说：“Operator在全面生产中十分重要。想一下如何管理一个高可用、容错、多区域的数据库，该数据库使用有状态集，需要备份、滚动升级和扩展。现在想象一下在Kubernetes中运行它，并记住有数百个微服务，每一个都在几秒钟内动态地伸缩。”
这并不容易。然而，Operator可以使这种工作更易于管理。
IT领导者应该知道的
“Operator通过自动化原本需要手动执行的困难、易出错的工作，使大规模的Kubernetes部署变得切实可行。”
下面是关于Operator的四个重要信息。
一、Kubernetes Operator的数量和流行度都在增加
随着Kubernetes的发展，对Operator的兴趣也在增长。CoreOS早在2016年就首次引入Operator，2018年3月推出Operator Framework。
Aqua Security开源工程副总裁Liz Rice表示，最近对Operator的兴趣和实施有了明显的提升。Rice还是CNCF技术监督委员会主席。
“在CNCF，我们看到人们对与管理和发现Kubernetes Operator有关的项目很感兴趣，也看到正在实施的Operator数量激增。项目维护人员和供应商正在构建Operator，以使人们更容易在Kubernetes部署中使用他们的项目或产品。”
越来越多的Operator意味着需要一个menu。“Operator的激增为目录或发现机制创造了一个缺口，以帮助人们找到并轻松安装可用的内容。”
http://OperatorHub.io是Kubernetes社区成员可以找到现有Operator或共享自己的Operator的地方。
二、Kubernetes Operator需要持续关注
使用Operator来更全面地自动化Kubernetes应用程序时，你需要监控它们。
Instaclustr首席技术官Ben Bromhead表示：“要明白，与Kubernetes本身一样，Kubernetes Operator也在不断发展。试图在内部管理它们的开发团队必须密切跟踪其变化，并主动计划升级。当出错时，它们绝对需要手动干预。”
Bromhead建议先制定一个计划，对Operator进行持续的监督。
“这个工作流程应该在投入生产前就弄清楚，否则你可能会发现自己有麻烦。你仍然需要管理Operator，确保它是最新的，打了正确的补丁等。Operator不能写了就忘，而是必须不断改进。”
此外，Dresden指出，你是在自动化复杂性，而不是消除复杂性，而出错是在所难免的。
“复杂性不会因为自动化而消失。问题往往出乎意料地在最糟糕的时候突然出现。随着自动化程度的提高，人不可能跟得上一切。”
根据他的说法，全面的遥测是这里的关键；否则，当用户抱怨QQ账号卖号时，你会发现瓶颈服务，而不是主动监控和缓解此类问题。Dresden还强调了编写声明式Operator的重要性。
“Operator可以极大地提高生产率，但前提是托管服务的提供者和用户都能看到Operator在做什么。”
三、Kubernetes Operator不仅仅用于数据库
Operator主要是面向数据库吗？并不是的，这是一个误解。
在早期，Kubernetes被认为非常适合管理无状态应用程序。对于像数据库这样的有状态应用程序来说，就没那么好了，而Operator是救星。
因此，早期的Operator通常专注于数据库应用，并帮助将Kubernetes的功能扩展到这一关键类别。
AllCloud的DevOps团队负责人Yossi Jana说：“早期人们会创建Operator，主要用来管理有状态的数据库工作负载，如MongoDB、Cassandra和Redis。”
是的，如果你扫描http://OperatorHub.io注册表，你会看到大量与数据库相关的Operator。但Operator并不是只为数据库服务的。
“随着Operator越来越容易开发并成为主流，越来越多的公司在Operator注册中心提供他们的云原生解决方案。你可以根据需要找到（并使用）Operator，满足安全（如Aqua Security Operator）、网络（如Istio Operator）和CI/CD（如Spinnaker Operator）的需要。”
四、Operator不一定适合每个作业
Operator很重要，但并不意味着它总是最好的选择。CloudBolt软件公司产品营销总监Nilesh Deo将“Kubernetes Operator将解决我所有的Kubernetes问题”列为最大误解之一。
根据Deo的说法，其他常见的误解是：Operator设置好了就不用管了，Operator需要大量的繁重的开发工作。是的，必须有人编写Operator，但不一定是你——这要感谢像http://OperatorHub.io这样的存储库。此外，像Operator Framework和Kubebuilder这样的工具包和sdk可以减少开发工作量。
Alcide的创始人兼首席技术官Gadi Naor举了一个例子，从安全的角度来看，Operator可能不是最合适的选择，cron作业就做得很好。
Naor解释说，通过设计，Operator可以提供、更新和删除Kubernetes资源。“这意味着，Operator代表了集群中的持久风险；因此，就威胁和风险建模而言，我们必须认真对待它。”
根据Naor的说法，如果可以用cron作业适当地处理任务，那么它可能是更好的选择。
Naor解释说：“这减少了特权组件运行的时间，同时又不影响所需的功能。选择Operator之前的关键问题是：我们真的需要用Operator实现某些工作流或功能吗？我们可以使用cron作业，或者集群外部自动化实现同样的功能吗？”
当Operator与你的需求相匹配时，你就有了一个强大的杠杆来扩展Kubernetes功能，而不会破坏你的DevOps或SRE团队。
Naor说：“Operator作为一种软件模式，在Kubernetes中运行时，它在自动化整个应用程序和微服务生命周期方面，从安装、更新和扩展到备份和恢复，扮演着重要的角色。”
