Kubernetes 遇见事件驱动型 Ansible
Kubernetes 遇见事件驱动型 Ansible
在当今快节奏的世界里，每一秒都至关重要，及时响应活动的能力可能决定着能否满足消费者的需求和达成服务等级协议。这两者都是事件驱动型 Ansible的目标，它旨在通过响应满足特定条件的事件来进一步扩展基于 Ansible 的自动化的覆盖范围。这些事件可以源自各种来源，例如 HTTP 端点、队列或主题上的消息，或来自公共云资源。Kubernetes 已成为云原生架构中管理基础设施和应用程序的代名词，许多组织都依赖这些系统来运行其业务关键型工作负载。自动化和 Kubernetes 密不可分，Ansible 已经在该生态系统中发挥作用。现在提供了一种利用事件驱动型 Ansible 框架的新功能，扩展了 Ansible 和 Kubernetes 之间的集成，以便可以根据 Kubernetes 集群中发生的事件和操作触发 Ansible 自动化活动。
事件驱动型 Ansible 使用名为规则手册的概念进行设计，该概念包含三个主要组件
- 操作 - 触发资产的执行，包括 Ansible playbook 或模块
- 规则 - 确定接收到的事件是否与某些条件匹配
- 来源 - 来自外部实体的事件起源，这些事件将在 Ansible 事件框架中被使用和处理
可以使用各种解决方案来从 Ansible 管理 Kubernetes，这些解决方案主要通过kubernetes.core 集合提供。此集合包含从管理 Kubernetes 集群内资源的机制到对 Helm 包管理器支持以及利用 Kubernetes 集群作为清单源等各种功能。现在，通过 Kubernetes 和事件驱动型 Ansible 框架的集成提供了更多功能。事件源能够使用源自 Kubernetes 集群的变化，这些变化可用于触发自动化，以便根据接收到的内容和配置的规则做出响应和采取行动。让我们探讨如何利用此新创建的功能来进一步增强 Kubernetes 和 Ansible 之间的集成。
与事件驱动型 Ansible 和 Kubernetes 相关的资产位于 Ansible Galaxy 中的sabre1041.eda 集合内。确保将执行 Ansible 自动化的控制节点安装并配置了必要的工具。这包括 Ansible Core、与事件驱动型 Ansible 相关的工具以及包含事件驱动型 Ansible Kubernetes 集成的集合。请查阅Ansible Core和事件驱动型 Ansible的相关文档，了解目标操作系统的安装方法。
安装并配置 Ansible Core 和事件驱动型 Ansible 后，通过执行以下命令安装 sabre1041.eda 集合
ansible-galaxy collection install sabre1041.eda
此集合还要求安装 Python requests 包，可以通过执行以下命令来完成
pip install requests
现在所有先决条件工具都已满足，可以将注意力转向如何配置规则手册以利用 Kubernetes 集成。事件驱动型 Ansible 架构中的事件在规则手册的 sources 部分进行配置。可以在规则手册中指定一个或多个来源，从而可以配置一组强大的条件和操作。
下面显示了一个利用集合中 k8s 事件源插件的基本规则手册
- name: Listen for newly added ConfigMap resources hosts: all sources: - sabre1041.eda.k8s: api_version: v1 kind: ConfigMap namespace: default rules: - name: Notify condition: event.type == "ADDED" action: debug:
k8s 插件的建模方式类似于 kubernetes.core 集合中的k8s 模块，因此任何熟悉此模块的人在使用此 k8s 源插件时都会感到很熟悉。
此规则手册的逻辑如下
- 连接到远程 Kubernetes 集群并使用默认命名空间中发生的 ConfigMap 资源的变化
- 每当 Kubernetes 集群中发生更改时，k8s 源插件都会将类型和内容包含到事件对象中
- 仅当事件上的 type 属性等于“ADDED”（每当向集群添加 ConfigMap 时），才执行调试操作，该操作将打印出事件和任何其他关联变量。
虽然此规则手册监视特定命名空间中的更改，但可以通过省略源插件中 namespace 参数来支持监视整个 Kubernetes 集群中的更改。如果禁止访问默认命名空间，请随时选择另一个可以访问的命名空间。
为了演示此规则手册的使用，将前面提供的內容添加到名为 k8s-eda-demo.yaml 的新规则手册文件。此外，确保本地机器已通过身份验证连接到 Kubernetes 集群，或自定义插件参数以指定应使用的 Kubernetes 集群的位置。请参阅插件文档以了解可用的选项。
在名为 inventory 的文件中创建一个简单的清单，内容如下
localhost
运行规则手册以开始使用事件，执行以下命令
ansible-rulebook -i inventory --rulebook k8s-eda-demo.yaml --verbose
由于规则手册监视默认命名空间中的 ConfigMap 更改，因此在默认命名空间中创建一个新的 ConfigMap 以演示是否正确捕获了事件。此任务可以通过使用 Kubernetes CLI（kubectl）执行以下命令来完成
kubectl create configmap -n default eda-example --from-literal=message="Kubernetes Meets Event-Driven Ansible"
观察以下内容已在执行 ansible-rulebook 命令的窗口中捕获并显示。
kwargs: {'facts': {}, 'hosts': ['all'], 'inventory': 'localhost', 'project_data_file': None, 'ruleset': 'Listen for newly added ConfigMap resources', 'source_rule_name': 'Notify', 'source_ruleset_name': 'Listen for newly added ConfigMap resources', 'variables': {'event': {'resource': {'apiVersion': 'v1', 'data': {'message': 'Kubernetes Meets ' 'Event-Driven ' 'Ansible'}, 'kind': 'ConfigMap', 'metadata': {'creationTimestamp': '2022-12-25T17:40:43Z', 'managedFields': [{'apiVersion': 'v1', 'fieldsType': 'FieldsV1', 'fieldsV1': {'f:data': {'.': {}, 'f:message': {}}}, 'manager': 'kubectl-create', 'operation': 'Update', 'time': '2022-12-25T17:40:43Z'}], 'name': 'eda-example', 'namespace': 'default', 'resourceVersion': '119407', 'uid': '2862db59-8990-4a37-9433-50dcfbaa6d71'}}, 'type': 'ADDED'}, 'fact': {'resource': {'apiVersion': 'v1', 'data': {'message': 'Kubernetes Meets ' 'Event-Driven ' 'Ansible'}, 'kind': 'ConfigMap', 'metadata': {'creationTimestamp': '2022-12-25T17:40:43Z', 'managedFields': [{'apiVersion': 'v1', 'fieldsType': 'FieldsV1', 'fieldsV1': {'f:data': {'.': {}, 'f:message': {}}}, 'manager': 'kubectl-create', 'operation': 'Update', 'time': '2022-12-25T17:40:43Z'}], 'name': 'eda-example', 'namespace': 'default', 'resourceVersion': '119407', 'uid': '2862db59-8990-4a37-9433-50dcfbaa6d71'}}, 'type': 'ADDED'}}}
如上输出所示，已捕获与 Kubernetes 集群中新创建的 ConfigMap 和事件关联的详细信息。
确认 Kubernetes 源插件已成功捕获事件后，让我们演示如何在 Ansible Playbook 中使用这些事件。创建一个名为 k8s-eda-demo-playbook.yaml 的新文件，内容如下。
- hosts: localhost connection: local tasks: - ansible.builtin.debug: msg: "ConfigMap in namespace '{{ event.resource.metadata.namespace }}' with name '{{ event.resource.metadata.name }} ‘{{ event.type | capitalize }}’ with the message ‘{{ event.resource.data.message}}'"
此 playbook 演示了如何获取捕获事件中包含的属性。type 属性将显示“Added”，因为 playbook 仅在创建 ConfigMap 时才会执行。可以通过引用事件上的 resource 属性来访问 ConfigMap 对象本身。然后可以遍历 ConfigMap 的标准 Kubernetes 清单，例如命名空间、名称以及特定的数据值。
更新 k8s-eda-demo.yaml 文件中规则手册的内容，以调用新创建的 playbook，而不是简单地打印出内容，方法是使用如下所示的 run_playbook 操作
- name: Listen for newly added ConfigMap resources hosts: all sources: - sabre1041.eda.k8s: api_version: v1 kind: ConfigMap namespace: default rules: - name: Execute Playbook condition: event.type == "ADDED" action: run_playbook: name: k8s-eda-demo-playbook.yaml
再次执行 k8s-eda-demo-playbook.yaml 规则手册以开始列出添加到default命名空间的 ConfigMap。
ansible-rulebook -i inventory --rulebook k8s-eda-demo.yaml --verbose
删除并重新创建 ConfigMap 以触发 playbook。
kubectl delete configmap -n default eda-example kubectl create configmap -n default eda-example --from-literal=message="Kubernetes Meets Event-Driven Ansible"
观察 playbook 已被触发并生成类似于以下内容的输出
TASK [ansible.builtin.debug] *************************************************** ok: [localhost] => { "msg": "ConfigMap in namespace 'default' with name 'eda-example ‘Added’ with the message ‘Kubernetes Meets Event-Driven Ansible'" }
虽然此示例仅打印出与接收到的事件内容相关的一个简单消息，但它演示了如何利用 Kubernetes 集成启用的功能。通过将 Kuberentes 作为事件源并集成到事件驱动型 Ansible 生态系统中，它成为支持利用 Kubernetes 维持其业务关键组件并根据需要触发自动化的组织必不可少的集成。
