🥇Kubernetes 的 Operator：如何运行有状态应用程序

Kubernetes 中有状态应用程序的问题

当涉及到无状态（即无状态）的情况时，应用程序和服务的配置、启动和进一步扩展很容易。不保存数据。使用其标准 API 在 Kubernetes 中运行此类服务很方便，因为一切都是“开箱即用”的：根据标准配置，不涉及任何细节或魔法。

简而言之，要在容器集群中再启动五个 PHP/Ruby/Python 后端副本，只需设置新服务器 5 次并复制源即可。由于源代码和初始化脚本都在映像中，因此扩展无状态应用程序变得完全简单。正如容器和微服务架构的爱好者所熟知的那样，困难始于 有状态应用程序， IE。具有数据持久性，例如数据库和缓存（MySQL、PostgreSQL、Redis、ElasticSearch、Cassandra...）。这适用于独立实现仲裁集群的软件（例如 Percona XtraDB 和 Cassandra），以及需要单独管理实用程序的软件（例如 Redis、MySQL、PostgreSQL...）。

困难的出现是因为源代码和启动服务已经不够了——您需要执行更多步骤。至少，复制数据和/或加入集群。更准确地说，这些服务需要了解如何正确扩展、更新和重新配置它们，而不会丢失数据或暂时不可用。考虑到这些需求称为“操作知识”。

CoreOS 操作员

为了“编程”操作知识，去年年底的CoreOS项目提交 Kubernetes 平台的“一类新软件”——Operators（源自英文“operation”，即“操作”）。

使用和扩展 Kubernetes 核心功能（包括 有状态集，请参阅下面的差异）允许 DevOps 专家将操作知识添加到应用程序代码中。

运营商的目的 — 为用户提供一个 API，允许您管理 Kubernetes 集群中的多个有状态应用程序实体，而无需考虑幕后内容（哪些数据以及如何处理它们，仍需要执行哪些命令来维护集群））。事实上，Operator 旨在尽可能简化集群内应用程序的工作，自动执行以前必须手动解决的操作任务。

操作员如何工作

副本集 Kubernetes 允许您指定所需的运行 pod 数量，控制器确保维持其数量（通过创建和删除 pod）。 Operator 以类似的方式工作，将一组操作知识添加到标准 Kubernetes 资源和控制器，使您可以执行其他操作来支持所需数量的应用程序实体。

这与 有状态集，专为需要集群为其提供有状态资源（例如数据存储或静态 IP）的应用程序而设计？对于此类应用，运营商可以使用 有状态集 （而不是 副本集）作为基础，提供 额外的自动化：在崩溃时执行必要的操作、进行备份、更新配置等。

因此， 这一切是如何运作的？ 操作员是一个管理器守护进程，它：

订阅 Kubernetes 中的事件 API；
从它接收有关系统的数据（关于其 副本集, 豆荚, 特色服务 等等。）;
接收有关的数据 第三方资源 （参见下面的示例）；
对外观/变化做出反应 第三方资源 （例如，更改尺寸、更改版本等）；
对系统状态的变化做出反应（关于它的 副本集, 豆荚, 特色服务 等等。）;
最重要的：
1. 调用 Kubernetes API 来创建它需要的一切（同样，它自己的 副本集, 豆荚, 特色服务...），
2. 执行一些魔法（为了简化，您可以认为 Operator 进入 Pod 本身并调用命令，例如，加入集群或在更新版本时升级数据格式）。

事实上，从图中可以看出，只是在 Kubernetes 中添加了一个单独的应用程序（一个常规的应用程序）部署 с 复制集），称为运算符。它生活在一个普通的 Pod 中（通常只有一个），通常只负责它的 命名空间。这个运营商应用程序实现了它的API——虽然不是直接的，但是通过 第三方资源 在 Kubernetes 中。

因此，在我们创建之后 命名空间 运算符，我们可以添加它 第三方资源.

etcd 示例 （详情见下文）:

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

Elasticsearch 的示例：

apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
  name: example-es-cluster
spec:
  client-node-replicas: 3
  master-node-replicas: 2
  data-node-replicas: 3
  zones:
  - us-east-1c
  - us-east-1d
  - us-east-1e
  data-volume-size: 10Gi
  java-options: "-Xms1024m -Xmx1024m"
  snapshot:
    scheduler-enabled: true
    bucket-name: elasticsnapshots99
    cron-schedule: "@every 2m"
  storage:
    type: gp2
    storage-class-provisioner: kubernetes.io/aws-ebs

对运营商的要求

CoreOS 制定了工程师在 Operator 工作时获得的主要模式。尽管所有 Operator 都是独立的（为具有自身特征和需求的特定应用程序创建），但它们的创建必须基于一种强加以下要求的框架：

安装必须通过单个部署: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - 并且不需要额外的操作。
在 Kubernetes 中安装 Operator 时，必须创建新的第三方类型 （第三方资源）。为了启动应用程序实例（集群实例）并进一步管理它们（更新版本、调整大小等），用户将使用此类型。
只要有可能，您应该使用 Kubernetes 内置的原语，例如 特色服务 и 副本集使用经过充分测试且易于理解的代码。
需要 Operator 向后兼容并支持旧版本的用户创建的资源。
如果 Operator 被删除，应用程序本身应该继续运行而无需更改。
用户必须能够定义所需的应用程序版本并协调应用程序版本更新。缺乏软件更新是操作和安全问题的常见根源，因此运营商必须在这方面协助用户。
操作员应该使用 Chaos Monkey 等工具进行测试，该工具可以识别 Pod、配置和网络中的潜在故障。

etcd 操作员

算子实现示例 - etcd 操作员，准备在这个概念宣布的当天。由于需要维护仲裁、需要重新配置集群成员资格、创建备份等，etcd 集群配置可能很复杂。例如，手动扩展 etcd 集群意味着您需要为新集群成员创建 DNS 名称，启动新的 etcd 实体，并向集群发出有关新成员的警报（etcdctl 成员添加）。对于 Operator，用户只需要更改集群大小 - 其他一切都会自动发生。

由于 etcd 也是在 CoreOS 中创建的，因此看到它的 Operator 首先出现是很合乎逻辑的。他如何工作？ etcd 运算符逻辑 由三个部分决定：

观察。操作员使用 Kubernetes API 监控集群的状态。
分析。查找当前状态与所需状态（由用户配置定义）之间的差异。
行动。使用 etcd 和/或 Kubernetes 服务 API 解决检测到的差异。

为了实现这个逻辑，Operator 中准备了函数 创建/销毁 （创建和删除etcd集群成员）和 调整大小 （集群成员数量的变化）。使用类似于 Netflix 的 Chaos Monkey 创建的实用程序来检查其操作的正确性，即随机杀死 etcd pod。

为了充分运行 etcd，Operator 提供了附加功能： 备份工具 （自动且对用户不可见的备份副本创建 - 在配置中足以确定创建备份副本的频率以及存储的数量 - 以及随后从中恢复数据）和升级（无需停机即可更新 etcd 安装）。

与操作员一起工作是什么样的？

$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
etcd-cluster-0000                1/1       Running   0          23s
etcd-cluster-0001                1/1       Running   0          16s
etcd-cluster-0002                1/1       Running   0          8s
etcd-cluster-backup-tool-rhygq   1/1       Running   0          18s

etcd Operator 当前状态是 beta 版本，需要 Kubernetes 1.5.3+ 和 etcd 3.0+ 才能运行。源代码和文档（包括使用说明）可在以下位置获取： GitHub上.

CoreOS 的另一个示例实现已经创建 - 普罗米修斯算子，但仍处于 alpha 版本（并非所有计划的功能都已实现）。

现状与前景

自 Kubernetes Operator 宣布以来已经过去了 5 个月。官方 CoreOS 存储库中仍然只有两种实现（用于 etcd 和 Prometheus）。两者都尚未达到稳定版本，但每天都会观察到提交。

开发人员设想“未来，用户在其 Kubernetes 集群上安装 Postgres Operators、Cassandra Operators 或 Redis Operators，并像今天部署无状态 Web 应用程序的副本一样轻松地使用这些应用程序的可扩展实体。” 第一的 来自第三方开发商的运营商 真正开始出现：

弹性搜索运算符来自 UPMC Enterprise；
PostgreSQL 运算符来自 Crunchy Data（2017 年 XNUMX 月下旬发布）；
车操作员来自基于 Ceph 的分布式数据存储系统的作者（Rook 处于 alpha 状态）；
Openstack 运营商来自 SAP CCloud。

在 2017 年 XNUMX 月于布鲁塞尔举行的欧洲最大自由软件会议 FOSDEM 上，来自 CoreOS 的 Josh Wood 宣布了 Operators 报告（链接上有视频！），这应该有助于提高这个概念在更广泛的开源社区中的受欢迎程度。

PS 感谢您对本文的兴趣！ 订阅我们的中心，以免错过有关 DevOps 和 GNU/Linux 系统管理的新材料和秘诀 - 我们将定期发布它们！

来源： habr.com

Kubernetes 的 Operator：如何运行有状态应用程序