我们希望听到您的声音！帮助我们深入了解 Ansible 生态系统的现状。
参加 2024 年 Ansible 项目调查

Ansible 深入探究 Kubernetes Operators，第 1 部分

来源

Ansible 深入探究 Kubernetes Operators，第 1 部分

本深入探究系列假设读者可以访问 Kubernetes 测试环境。对于本文的目的而言，诸如 minikube 之类的工具是可以接受的平台。如果您是 Red Hat 的现有客户，另一种选择是通过 cloud.redhat.com 启动 OpenShift 集群。此 SaaS 门户使尝试 OpenShift 成为一项即用型操作。

在本深入探究系列的这一部分中，我们将

  1. 总体概述 Operators，以及它们在 OpenShift/Kubernetes 中的作用。
  2. 简要了解 Operator SDK，以及为什么您可能希望使用 Ansible Operator 而不是 SDK 提供的其他类型的 Operators。
  3. 最后，Ansible Operators 的结构以及 Operator SDK 创建的相关文件。

什么是 Operators？

对于那些可能不太熟悉 Kubernetes 的人来说，它在最简单的描述中是一个资源管理器。用户指定他们想要多少特定资源，Kubernetes 管理这些资源以实现用户指定的狀態。这些资源可以是 Pod（包含一个或多个容器）、持久卷，甚至由用户定义的自定义资源。

这使得 Kubernetes 非常适合于管理不包含任何状态的资源（例如 Web 服务器的 Pod 或负载平衡资源）。但是，Kubernetes 没有提供任何内置逻辑来管理诸如数据库或缓存之类的资源，这些资源是有状态的，并且对重启很敏感。创建 Operators 是为了弥合这一差距，为用户提供一种方法来指定与 Kubernetes 中的自定义资源定义 绑定的代码段（传统上是用 Golang 编写的）。

Operators之所以得名，是因为它们允许您将应用程序的操作逻辑嵌入到运行在 Kubernetes/OpenShift 上的自动化管理器中。

Operator SDK 以及 Ansible Operators 的简要概述

Red Hat 创建了 Operator Framework，以便在 Operators 的整个生命周期中，更容易创建和管理 Operators。作为框架的一部分，Operator SDK 的任务是自动地为用户创建和构建 Operators。随着时间的推移，它已经发展到添加了几种 Operator 类型。在 2018 年，我们开始着手将 Ansible Operator 类型添加到 SDK。我们希望简化在基于 Ansible 的 Kubernetes 环境中构建 Operators 的过程。

为什么要将 Ansible 用于 Operators？

最初，Operators是用 Golang 编写的。这立即将门槛提高到了一定程度，对于任何想要编写 Operator 的人来说，都需要了解一门相对低级的编程语言才能入门。除此之外，您还必须熟悉 Kubernetes 的内部结构，例如 API 以及如何为资源生成事件。

Ansible Operator 的创建是为了解决这个缺陷。Ansible Operator 由两个主要部分组成：

  1. 一小段 Golang 代码，它处理 Kubernetes/OpenShift 与 Operator 之间的接口。
  2. 一个容器，它接收来自上述代码的事件，并在需要时运行 Ansible Playbook。

就是这样！Ansible 和 Operator SDK 抽象了编写 Operator 的所有困难部分，让您专注于重要的事情——管理您的应用程序。如果您的组织已经拥有庞大的 Ansible 知识库，您可以立即开始使用 Ansible Operator 管理应用程序。使用 Ansible 进行 Operator 的另一个额外好处是，您可以立即访问 Ansible 可以运行的任何模块。这使人们能够将与应用程序相关的脱集群管理任务纳入其中。例如：

  1. 为新部署的应用程序创建 DNS 条目
  2. 启动集群外部的资源，例如存储或网络
  3. 更轻松地将脱机备份到外部云服务
  4. 根据自定义指标管理外部负载平衡

使用 Ansible 编写的 Kubernetes Operators 可以为许多可能性提供潜在的解决方案。

从头开始使用 Ansible 创建 Kubernetes Operator

首先，请按照他们的说明安装 Operator SDK。安装完成后，我们可以使用以下命令创建一个新的 Operator：

$ operator-sdk new test-operator \
    --api-version=test.ansible-operator.com/v1 \
    --kind=Test \
    --type=ansible

INFO[0000] Creating new Ansible operator 'test-operator'.
...
INFO[0000] Project creation complete.

$ cd test-operator/

Kubernetes Operator with Ansible 结构和文件

[现在我们有了 Operator 骨架，让我们看一下在一般情况下部署 Operators 时使用的一些主要文件，以及 Ansible Operator 类型专门生成的哪些文件。这些是

  1. watches.yaml 文件。
  2. build 目录。
  3. deploy 目录。
  4. roles 目录。

这里还存在另一个目录：molecule 目录，它包含使用 Molecule 自动化测试您的角色/Playbook 的文件。这里不会介绍 Molecule 的用法，但为了完整起见，我们还是要提到它。

如果您在上述 test-operator 目录中运行 ls -l，您将在创建新的 Operator 骨架后看到这些文件/目录。

watches.yaml 文件

此文件由 Ansible Operator 用于告知 Kubernetes/OpenShift 哪个自定义资源（基于 Group/Version/Kind 字段）由 Operator 负责处理。它是将我们的自定义代码与 Kubernetes API 联系起来的粘合剂。

---
- version: v1
  group: test.ansible-operator.com
  kind: Test
  role: /opt/ansible/roles/test

指定任何其他 Playbook 模板。但是，如果您在 Operator 中运行多个角色，您可以将该行更改为

playbook: /opt/ansible/playbook.yaml

此外，您需要调整 build/Dockerfile（下面将详细介绍），将 Playbook 复制到容器中，因此请添加以下行：

COPY playbook.yaml ${HOME}/playbook.yaml

然后，您将在与 watches.yaml 文件相同的目录中创建指定的 Playbook。

build 目录

此目录包含一些与构建 Operator 构件相关的文件。由于 Operators 只是 OpenShift/Kubernetes 的另一个应用程序，因此此构件是一个使用 Dockerfile 构建的容器。这里的其他文件与使用 Molecule 进行测试有关，我们不会在本博文系列中介绍。

Dockerfile 非常简单，因此我们不会深入研究它，只会说它是基于来自 quay.io 的 ansible-operator 镜像，并将角色和 watches.yml 文件复制到容器镜像中。

deploy 目录

此目录包含使用 oc CLI 命令将 Operator 部署到 OpenShift/K8s 的 YAML 文件。

CustomResourceDefinition (CRD) 和 CustomResource (CR) 在 deploy/crds/ 目录中定义。CRD 是 watches.yaml 文件引用的内容，这意味着此定义的所有实例 (CR) 将由我们的 Operator 控制。

CRD 在 deploy/crds/test_v1_test_crd.yaml 中定义，它主要是 OpenShift/Kubernetes 的模板

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: tests.test.ansible-operator.com
spec:
  ...

您可以看到上面的 operator-sdk 命令使用我们指定的 value 填充了大多数字段。CRD 本身并没有什么用，您需要它们定义的实际实例——这就是 CustomResources 的作用。我们的 CustomResource (CR) 在 deploy/crds/test_v1_test_cr.yaml 中定义，而且相对较短（与其他 YAML 文件相比）。

apiVersion: test.ansible-operator.com/v1
kind: Test
metadata:
  name: example-test
spec:
  size: 3

spec 条目下设置的每个 value 都成为传递到 Ansible 中的额外变量。使用这些变量，我们可以自定义 Operator 的行为。默认示例创建了一个名为 size 的条目，我们可以使用它在我们的角色中动态地缩放 Operator 所管理的应用程序。

deploy/role.yaml 和 deploy/role_binding.yaml（未显示）定义了一些 RBAC 控制，这些控制允许您登录以管理上面定义的自定义资源。本文不会介绍基于角色的访问控制 (RBAC)，因此我们只是为了完整起见提及它们。

最后，deploy/operator.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-operator
spec:
  ...

此文件相当长，但主要是在 OpenShift/Kubernetes 中创建一个新的 Deployment 资源，这有助于确保我们的 Operator 一直保持运行。

roles 目录

这是您放置想要包含在 Operator 中的任何角色的目录，并且应该对经验丰富的 Ansible 用户来说很熟悉。如上所述，此目录将完全复制到 Ansible Operator 容器中，这里面的角色可以在 watches.yaml 文件或您包含的其他 Playbook 中引用。

角色通常使用 k8s 模块（从 2.6 版开始包含在 Red Hat Ansible Automation 中）来管理集群上的资源。如果您熟悉 Kubernetes 资源文件，那么此模块将非常直观（资源文件的 YAML 可以直接复制粘贴作为此模块的输入）。要了解更多信息，您可以阅读以下 k8s 模块的文档：

https://docs.ansible.org.cn/ansible/latest/modules/k8s_module.html

总结

到此，我们对 Operators、Operator SDK 以及 Ansible Operator 的创建和结构的深入探究就结束了。使用 Ansible 编写的 Operators 使您能够使用 Operators 的强大功能，同时允许您利用现有的 Ansible 专业知识，快速上手在 OpenShift 或 Kubernetes 上部署应用程序。

由 提供支持