5.4. 创建基于 Ansible 的 Operator
本指南概述了 Operator SDK 中的 Ansible 支持，通过一些示例指导 Operator 作者通过使用 Ansible playbook 和模块的 operator-sdk CLI 工具来构建和运行基于 Ansible 的 Operator。
5.4.1. Operator SDK 中的 Ansible 支持
Operator Framework 是一个开源工具包，用于以有效、自动化且可扩展的方式管理 Kubernetes 原生应用程序，即 Operator。该框架中包含 Operator SDK，可协助开发人员利用自己的专业知识来引导和构建 Operator，而无需了解 Kubernetes API 复杂性。
通过 Operator SDK 生成 Operator 项目的其中一种方案是利用现有 Ansible playbook 和模块来部署 Kubernetes 资源作为统一应用程序，而无需编写任何 Go 代码。
5.4.1.1. 自定义资源文件
Operator 会使用 Kubernetes 的扩展机制，即自定义资源定义 (CRD)，这样您的自定义资源 (CR) 的外观和行为均类似于内置的原生 Kubernetes 对象。
CR 文件格式是一个 Kubernetes 资源文件。该对象具有必填和选填字段：
| 字段 | 描述 |
|---|---|
|
| 要创建 CR 的版本。 |
|
| 要创建 CR 的类型。 |
|
| 要创建的 Kubernetes 特定元数据。 |
|
| 传输至 Ansible 的变量键值列表。本字段默认为空。 |
|
|
总结对象的当前状态。对于基于 Ansible 的 Operator， |
|
| 要附于 CR 的 Kubernetes 特定注解。 |
以下 CR 注解列表会修改 Operator 的行为：
| 注解 | 描述 |
|---|---|
|
|
为 CR 指定协调间隔。该值将通过标准 Golang 软件包 |
基于 Ansible 的 Operator 注解示例
apiVersion: "test1.example.com/v1alpha1" kind: "Test1" metadata: name: "example" annotations: ansible.operator-sdk/reconcile-period: "30s"
5.4.1.2. watches.yaml file
group/version/kind (GVK) 是 Kubernetes API 的唯一标识符。watches.yaml 文件包含从自定义资源（CR）中标识的自定义资源（CR）到 Ansible 角色或 playbook 的映射列表。Operator 期望这个映射文件位于 /opt/ansible/watches.yaml 的预定义位置。
| 字段 | 描述 |
|---|---|
|
| 要监视的 CR 组。 |
|
| 要监视的 CR 版本。 |
|
| 要监视的 CR 类型 |
|
|
添加至容器中的 Ansible 角色的路径。例如：如果您的 |
|
|
添加至容器中的 Ansible playbook 的路径。期望这个 playbook 作为一种调用角色的方法。该字段与 |
|
| 给定 CR 的协调间隔，角色或 playbook 运行的频率。 |
|
|
如果设置为 |
watches.yaml 文件示例
- version: v1alpha1 1 group: test1.example.com kind: Test1 role: /opt/ansible/roles/Test1 - version: v1alpha1 2 group: test2.example.com kind: Test2 playbook: /opt/ansible/playbook.yml - version: v1alpha1 3 group: test3.example.com kind: Test3 playbook: /opt/ansible/test3.yml reconcilePeriod: 0 manageStatus: false
5.4.1.2.1. 高级选项
高级功能可通过添加至每个 GVK 的 watches.yaml 文件中来启用。它们可放在 group、version、kind 和 playbook 或 role 字段下方。
可使用 CR 上的注解覆盖每个资源的一些功能。可覆盖的选项会指定以下注解。
| 功能 | YAML 密钥 | 描述 | 覆盖注解 | 默认值 |
|---|---|---|---|---|
| 协调周期 |
| 特定 CR 的协调运行间隔时间。 |
|
|
| 管理状态 |
|
允许 Operator 管理每个 CR |
| |
| 监视依赖资源 |
| 支持 Operator 动态监视由 Ansible 创建的资源。 |
| |
| 监控集群范围内的资源 |
| 支持 Operator 监视由 Ansible 创建的集群范围的资源。 |
| |
| 最大运行程序工件 |
| 管理 Ansible Runner 在 Operator 容器中为每个单独资源保存的构件目录的数量。 |
|
|
带有高级选项的 watches.yml 文件示例
- version: v1alpha1 group: app.example.com kind: AppService playbook: /opt/ansible/playbook.yml maxRunnerArtifacts: 30 reconcilePeriod: 5s manageStatus: False watchDependentResources: False
5.4.1.3. 发送至 Ansible 的额外变量
额外变量可发送至 Ansible，然后由 Operator 管理。自定义资源 (CR) 的 spec 部分作为额外变量按照键值对传递。等同于传递给 ansible-playbook 命令的额外变量。
Operator 还会在 meta 字段下传递额外变量，用于 CR 的名称和 CR 的命名空间。
对于以下 CR 示例：
apiVersion: "app.example.com/v1alpha1" kind: "Database" metadata: name: "example" spec: message: "Hello world 2" newParameter: "newParam"
作为额外变量传递至 Ansible 的结构为：
{ "meta": {
"name": "<cr_name>",
"namespace": "<cr_namespace>",
},
"message": "Hello world 2",
"new_parameter": "newParam",
"_app_example_com_database": {
<full_crd>
},
}
message 和 newParameter 字段在顶层被设置为额外变量，meta 则为 Operator 中定义的 CR 提供相关元数据。meta 字段可使用 Ansible 中的点符号来访问，如：
- debug:
msg: "name: {{ meta.name }}, {{ meta.namespace }}"5.4.1.4. Ansible Runner 目录
Ansible Runner 会将与 Ansible 运行相关的信息保存至容器中。具体位于：/tmp/ansible-operator/runner/<group>/<version>/<kind>/<namespace>/<name>。
其他资源
-
要了解有关
runner目录的更多信息，请参阅 Ansible Runner 文档。
