6. 集群

集群是在主机之间共享负载。每个实例都应该能够充当 UI 和 API 访问的入口点。这应该使 AWX 管理员能够在其希望的任意数量的实例前面使用负载均衡器，并保持良好的数据可见性。

注意

负载均衡是可选的，并且完全可以在一个或所有实例上根据需要进行入口。如果您在负载均衡器后面使用 AWX，则可能需要 CSRF_TRUSTED_ORIGIN 设置。有关更多详细信息，请参阅 CSRF_TRUSTED_ORIGIN 设置。

每个实例都应该能够加入 AWX 集群并扩展其执行作业的能力。这是一个简单的系统，作业可以在任何地方运行，而不是被指示在哪里运行。此外，集群实例可以分组到不同的池/队列中，称为实例组。

6.1. 设置注意事项

本节仅介绍集群的初始设置。有关升级现有集群的信息，请参阅《AWX 升级和迁移指南》。

在新的集群环境中需要注意的重要事项

PostgreSQL 仍然是一个独立的实例，并且未进行集群化。AWX 不管理副本配置或数据库故障转移（如果用户配置了备用副本）。
在启动集群时，数据库节点应为独立服务器，并且不应在 AWX 节点之一上安装 PostgreSQL。
对于与 AWX 的连接池，不建议使用 PgBouncer。目前，AWX 严重依赖 pg_notify 来发送各种组件之间的消息，因此，PgBouncer 无法在事务池模式下轻松使用。
集群中支持的最大实例数为 20。
所有实例都应能够从所有其他实例访问，并且它们应该能够访问数据库。主机具有稳定的地址和/或主机名（取决于 AWX 主机的配置方式）也很重要。
所有实例必须位于地理位置上，并且实例之间具有可靠的低延迟连接。
为了升级到集群环境，您的主实例必须是清单中 default 组的一部分 *并且* 需要是 default 组中列出的第一个主机。
手动项目必须由客户手动同步到所有实例，并同时在所有实例上更新。
平台部署的 inventory 文件应保存/持久化。如果要预配新实例，则必须将密码和配置选项以及主机名提供给安装程序。

6.2. 独立扩展 Web 和任务 Pod

您可以分别使用 web_replicas 或 task_replicas 将每个部署的副本扩展或缩减。您还可以使用 replicas 扩展两个部署中的所有 Pod。这些 CRD 密钥背后的逻辑如下

如果您指定 replicas 字段，则传递的密钥将使 web 和 task 副本都扩展到相同的数量。
如果传递了 web_replicas 或 task_replicas，它将使用新的密钥值覆盖特定部署上现有的 replicas 字段。

通过在使用的约束前面附加特定的部署名称，可以以类似于以前单个部署的方式来约束这些新副本。有关这些新约束的更多信息，请参见下面的将 AWX Pod 分配到特定节点部分。

6.3. 将 AWX Pod 分配到特定节点

您可以约束由操作符创建的 AWX Pod 以在节点的特定子集上运行。 node_selector 和 postgres_selector 约束 AWX Pod 仅在与所有指定的键/值对匹配的节点上运行。 tolerations 和 postgres_tolerations 允许 AWX Pod 调度到具有匹配污点的节点上。还允许通过 topology_spread_constraints 指定 topologySpreadConstraints 的能力。如果您想对 AWX Pod 使用亲和性规则，则可以使用 affinity 选项。

如果您想单独约束 Web 和任务 Pod，则可以通过在特定设置前指定部署类型来实现。例如，指定 task_tolerations 将允许 AWX 任务 Pod 调度到具有匹配污点的节点上。

名称	描述	默认值
postgres_image	要拉取的镜像的路径	postgres
postgres_image_version	要拉取的镜像版本	13
node_selector	AWX Pod 的 nodeSelector	‘’
web_node_selector	AWX Web Pod 的 nodeSelector	‘’
task_node_selector	AWX 任务 Pod 的 nodeSelector	‘’
topology_spread_constraints	AWX Pod 的 topologySpreadConstraints	‘’
web_topology_spread_constraints	AWX Web Pod 的 topologySpreadConstraints	‘’
task_topology_spread_constraints	AWX 任务 Pod 的 topologySpreadConstraints	‘’
affinity	AWX Pod 的亲和性规则	‘’
web_affinity	AWX Web Pod 的亲和性规则	‘’
task_affinity	AWX 任务 Pod 的亲和性规则	‘’
tolerations	AWX Pod 的容忍度	‘’
web_tolerations	AWX Web Pod 的容忍度	‘’
task_tolerations	AWX 任务 Pod 的容忍度	‘’
annotations	AWX Pod 的注释	‘’
postgres_selector	Postgres Pod 的 nodeSelector	‘’
postgres_tolerations	Postgres Pod 的容忍度	‘’

自定义示例可能是

---
spec:
    ...
    node_selector: |
      disktype: ssd
      kubernetes.io/arch: amd64
      kubernetes.io/os: linux
    topology_spread_constraints: |
      - maxSkew: 100
      topologyKey: "topology.kubernetes.io/zone"
      whenUnsatisfiable: "ScheduleAnyway"
      labelSelector:
        matchLabels:
            app.kubernetes.io/name: "<resourcename>"
    tolerations: |
      - key: "dedicated"
      operator: "Equal"
      value: "AWX"
      effect: "NoSchedule"
    task_tolerations: |
      - key: "dedicated"
      operator: "Equal"
      value: "AWX_task"
      effect: "NoSchedule"
    postgres_selector: |
      disktype: ssd
      kubernetes.io/arch: amd64
      kubernetes.io/os: linux
    postgres_tolerations: |
      - key: "dedicated"
      operator: "Equal"
      value: "AWX"
      effect: "NoSchedule"
    affinity:
      nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
            matchExpressions:
            - key: another-node-label-key
              operator: In
              values:
              - another-node-label-value
              - another-node-label-value
      podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
            labelSelector:
              matchExpressions:
              - key: security
                operator: In
                values:
                - S2
            topologyKey: topology.kubernetes.io/zone

6.4. 通过浏览器 API 查看状态和监控

AWX 本身通过 /api/v2/ping 处的可浏览 API 报告尽可能多的状态，以便提供集群健康状况的验证，包括

提供 HTTP 请求的实例
集群中所有其他实例的最后一次心跳的时间戳
实例组和这些组中的实例成员资格

在 /api/v2/instances/ 和 /api/v2/instance_groups/ 中查看有关实例和实例组的更多详细信息，包括正在运行的作业和成员资格信息。

6.5. 实例服务和故障行为

每个 AWX 实例都由几个不同的服务协同工作组成

HTTP 服务 - 这包括 AWX 应用程序本身以及外部 Web 服务。
回调接收器 - 从正在运行的 Ansible 作业接收作业事件。
调度程序 - 处理和运行所有作业的工作队列。
Redis - 此键值存储用作从 ansible-playbook 传播到应用程序的事件数据的队列。
Rsyslog - 用于将日志传递到各种外部日志记录服务的日志处理服务。

AWX 的配置方式是，如果这些服务或其组件中的任何一个发生故障，则所有服务都将重新启动。如果这些服务在短时间内频繁发生故障，则整个实例将以自动方式脱机，以便允许进行修复，而不会导致意外行为。

6.6. 作业运行时行为

作业的运行方式和向 AWX 的“普通”用户报告的方式没有改变。在系统方面，一些差异值得注意

当从 API 接口提交作业时，它会被推送到调度程序队列中。每个 AWX 实例都将使用特定的调度算法连接到该队列并接收作业。集群中的任何实例都有可能接收工作并执行任务。如果实例在执行作业时发生故障，则该工作将被标记为永久失败。

An illustration depicting job distribution in an AWX cluster.

项目更新在任何可能运行作业的实例上都成功运行。项目将在运行作业之前立即将自身同步到实例上的正确版本。如果所需的修订版本已在本地签出，并且不需要 Galaxy 或 Collections 更新，则可能不会执行同步。
当同步发生时，它会在数据库中记录为项目更新，其中 launch_type = sync 且 job_type = run。项目同步不会更改项目的狀態或版本；相反，它们只会更新运行它们的实例上的源代码树。
如果需要从 Galaxy 或 Collections 更新，则会执行同步操作以下载所需的 roles，这会占用更多 /tmp 文件中的空间。在项目较大的情况下（约 10 GB），/tmp 上的磁盘空间可能会成为问题。

6.6.1. 作业运行

默认情况下，当作业提交到 AWX 队列时，任何工作节点都可以获取它。但是，您可以控制特定作业的运行位置，例如限制作业运行的实例。

为了支持临时使实例脱机，每个实例上都定义了一个名为 enabled 的属性。当此属性被禁用时，不会将任何作业分配给该实例。现有作业将完成，但不会分配新的工作。