Kubernetes是一个开源项目，可“包含”工作负载和服务，并管理部署和配置。Google于2015年发布了Kubernetes，现在由Cloud Native Computing Foundation维护。自发布以来，它已成为一种全球现象。大多数云原生公司都在使用它，SaaS供应商提供商业的预构建版本，甚至还有年度大会！
是什么使Kubernetes成为如此基本的服务？一个主要因素是其自动化功能。Kubernetes可以根据其跟踪的指标或工程师的要求自动更改已部署容器的配置，甚至可以部署新容器。让Kubernetes处理这些过程可以节省时间，消除劳累并提高一致性。
如果这些好处听起来很熟悉，那可能是因为它们与SRE的理念重叠。但是，如何将Kubernetes的自动化纳入您的SRE实践中？在这篇博客中，我们将解释Kubernetes Operator（Kubernetes功能是自定义自动化的核心），并讨论它如何发展您的SRE解决方案。
Kubernetes Operator可以做什么？
Jason Dobies和Joshua Wood 在Kubernetes的《运营商：自动化容器编排平台》一书中将运营商描述为“针对其应用的自动化站点可靠性工程师”。考虑到SRE的丰富经验和多样化的工作量，这是一个大胆的声明。那么操作员到底能做什么？
Kubernetes操作员完成复杂的任务
操作员可以完成复杂的任务，以在应用程序的输出中实现所需的更改。它可以自动处理以下任务：
部署应用
将应用程序更新到新版本
重新配置应用程序设置
根据使用情况上下扩展应用程序
故障处理
建立监控基础架构
没有Kubernetes操作员，工程师将需要完成这些任务。使它们自动化可以节省时间和精力，并使过程和结果一致。
Kubernetes Operator控制自定义资源和应用程序
Kubernetes允许您基于特定的应用程序创建和定义自定义资源。定制资源是您的应用程序生成的数据对象，其中包含有关应用程序状态的指标。假设您有一个根据使用情况生成新服务器实例的应用程序。您可以定义自定义资源来检查每个新实例的RAM和磁盘空间。您还可以将自定义资源定义为应用程序尝试匹配的目标。然后，Kubernetes Operator可以控制应用程序以实现目标自定义资源。如果应用程序正在拆分RAM或磁盘空间不足的服务器，则操作员可以重新配置设置以匹配所需的数量。
Kubernetes Operator做出有状态的决策
Kubernetes Operator可以根据应用程序的输出来修改应用程序的配置和用法。这由为该应用程序定义的自定义资源确定。显示所需状态的自定义资源和显示当前状态的自定义资源形成一个循环。操作员观察当前状态，然后采取措施使应用程序产生所需状态。执行动作后，将重新评估当前状态，并再次开始循环。
例如，自定义资源可以根据新服务器实例的物理资源将其定义为某种负载能力。然后，操作员将调整配置，直到新实例达到这些标准。
Kubernetes Operator和SRE
如果您使用的是Kubernetes，您会发现构建和实现Operators与您的SRE目标保持一致。
操作员监控，SLI和SLO
在为应用程序开发自定义资源时，您需要选择资源将监视应用程序输出中的哪些信号，以及操作员将应用程序导向的目标。这类似于创建SLI和SLO。
对于Operator和SLI，确定影响最大的指标的过程相似。在Kubernetes Operator教科书中，Dobies和Wood建议首先查看“四个黄金信号”（来自Google SRE书中的一个概念），以确定Operator应监控的内容。这些是：
潜伏
交通
失误
饱和
为您的应用程序创建操作员将帮助您了解应为它们设置哪些SLI和SLO。同样，设置SLI和SLO可以帮助您了解操作员应监视的内容。
您可能会注意到，当服务器过载时，您的客户对应用程序的可用性不满意。
您可以设置自定义资源来监视可用磁盘空间。在剩余容量为5％的情况下，您的自定义资源将启动新的服务器实例，从而为客户提供更好的服务。您的SLI将基于可用性并监视磁盘空间。您的SLO可能会指示您需要达到99.9％的可用性以使客户满意，并告知操作员的干预要点。
自动化SRE应用程序部署
您的SRE实践将涉及为服务的每个新实例定期部署应用程序。例如，您可能希望在每次实现系统体系结构的新区域时都部署监视应用程序。Kubernetes Operator可以加快这一过程并使之自动化。为了进行监视，Prometheus操作员是Kubernetes开发的首批操作员之一。它会自动将开源监控软件Prometheus的新实例部署并控制到任何目标集群上。
SRE工具代表着对可靠性的投资。实施它们所花费的时间由它们节省的时间支付。创建Operator是一项类似的投资。通过创建操作员，可以节省每个部署的时间。此外，部署是一致且可靠的。您的SRE实践具有较少的开销，并且可以随您的组织扩展。
操作员与事件管理
可以设置操作员进行调整以处理故障。如果应用程序的自定义资源与期望的结果有所不同，则操作员将进行更改以进行补偿，直到达到期望的状态。变化的原因与操作员无关。它仅基于当前和所需状态进行操作。您仍然需要进行事件回顾，以增加影响因素。
在制定事件响应计划时，操作员的行为可能是宝贵的资源。如果您知道操作员将自动尝试纠正此行为，则可以将其纳入您的期望和过程中。例如，如果您有针对饱和服务器的事件响应计划，那么您的操作员可以启动新服务器实例或重新配置负载平衡。您的响应计划将考虑到这一点，从而节省了一些故障排除步骤，并使您可以专注于始发问题。通过组合操作员和自动运行手册，可以最大程度地减少手动上报的数量，并解决许多事件，而无需人工干预。由于自动化是SRE的另一个核心目标，因此这是Kubernetes Operator适合您的可靠性策略的另一种方式。
随着您将服务转换为基于容器的模型并且Kubernetes对您的DevOps实践变得更加重要，将运营商纳入您的可靠性策略中非常重要。操作员允许您使用自定义资源和响应扩展Kubernetes，从而实现更高的自动化程度和更少的工作量。