在 Red Hat OpenShift 上部署 Ansible Automation Platform 2

有关资源管理的两个关键资源是您的 CPU 和内存(RAM)。Red Hat OpenShift 使用资源请求和资源限制来控制容器可在 pod 中消耗的资源量。

从概述部分查看 图 1.1 “自动化控制器架构”，您会注意到 control pod 包含 4 个容器：

这些容器在 Ansible 自动化控制器中执行一个唯一功能，了解资源配置如何影响控制 pod 至关重要。默认情况下，Red Hat OpenShift 提供了适用于最小测试安装的低值，但不建议在生产环境中运行 Ansible Automation Platform。

Ansible Automation Platform 的 Red Hat OpenShift 默认值是：

默认情况下，Red Hat OpenShift 不会配置任何最大资源限值，并将尝试分配 Ansible Automation Platform 控制 pod 请求的所有可能资源。此配置可能会导致资源不足，并影响在 Red Hat OpenShift 集群上运行的其他应用程序。

要演示控制 Pod 中容器的资源请求和限值的起点，我将使用以下假设：

在调整控制 pod 中的容器大小时，务必要考虑具体工作负载。虽然我进行了性能测试，它们为这个参考环境提供特定建议，但这些建议可能不适用于所有类型的工作负载。

作为起点，我决定利用 性能集合 playbook，特别是 chatty_tasks.yml。

性能基准包括：

chatty_tasks 作业模板使用 ansible.builtin.debug 模块来生成每个主机的一组调试消息，并生成必要的清单。通过使用 ansible.builtin.debug 模块，我可以在不引入任何其他开销的情况下获得自动化控制器性能的准确表示。

作业模板使用指定的并发级别执行，范围从 10 到 50，表示作业模板的同时调用数量。

以下 资源请求和资源限制 是性能基准的结果，可用作使用类似资源的 Red Hat OpenShift 集群运行 AAP 的起始基准。

spec:
...
  ee_resource_requirements:
    limits:
      cpu: 500m
      memory: 400Mi
    requests:
      cpu: 100m
      memory: 400Mi
  task_resource_requirements:
    limits:
      cpu: 4000m
      memory: 8Gi
    requests:
      cpu: 1000m
      memory: 8Gi
  web_resource_requirements:
    limits:
      cpu: 2000m
      memory: 1.5Gi
    requests:
      cpu: 500m
      memory: 1.5Gi
  redis_resource_requirements:
    limits:
      cpu: 500m
      memory: 1.5Gi
    requests:
      cpu: 250m
      memory: 1.5Gi

spec:
...
  ee_resource_requirements:
    limits:
      cpu: 500m
      memory: 400Mi
    requests:
      cpu: 100m
      memory: 400Mi
  task_resource_requirements:
    limits:
      cpu: 4000m
      memory: 8Gi
    requests:
      cpu: 1000m
      memory: 8Gi
  web_resource_requirements:
    limits:
      cpu: 2000m
      memory: 1.5Gi
    requests:
      cpu: 500m
      memory: 1.5Gi
  redis_resource_requirements:
    limits:
      cpu: 500m
      memory: 1.5Gi
    requests:
      cpu: 250m
      memory: 1.5Gi

在使用 chatty_task playbook 执行性能基准测试后，观察到 500m 以下的 CPU 资源请求可能会导致 Postgres pod 中的 CPU 节流，因为初始资源请求上方请求的其他资源（在资源限值下）不能保证 pod。但是，CPU 限值被设置为 1000m (1 vCPU)，因为测试过程中会出现超过 500m 请求的突发。

对于内存，因为内存不是可压缩的资源，因此在 chatty_task 性能测试 Postgres pod 在测试中其最高级别的测试中略消耗了 650Mi RAM。

因此，根据结果，对于此参考环境，我的内存资源请求和限制推荐 1Gi 提供足够的缓冲区，并避免 Postgres pod 的潜在内存不足(OOM) Kill。

以下 资源请求和资源限制 是性能基准测试的结果，可用作运行 Postgres Pod 的起始基准。

spec:
...
  postgres_resource_requirements:
    limits:
      cpu: 1000m
      memory: 1Gi
    requests:
      cpu: 500m
      memory: 1Gi

spec:
...
  postgres_resource_requirements:
    limits:
      cpu: 1000m
      memory: 1Gi
    requests:
      cpu: 500m
      memory: 1Gi

Ansible Automation Platform 作业是针对主机清单启动 Ansible playbook 的自动化控制器实例。当 Ansible Automation Platform 在 Red Hat OpenShift 上运行时，默认执行队列是 Operator 在安装时创建的容器组。

容器组由 Kubernetes 凭证和默认 Pod 规格组成。当作业启动到容器组时，由容器组 pod 规格指定的命名空间中的自动化控制器创建 pod。这些 pod 被称为自动化作业 pod。

要确定用于自动化作业 pod 的大小，必须首先了解自动化控制器 control plane 可同时启动的作业数量。

在本例中，有 3 个 worker 节点（每个 4 个 vCPU 和 16GiB RAM）。一个 worker 节点托管 control pod，另一个两个 worker 节点用于自动化作业。

根据这些值，我们可以确定自动化控制器 control plane 可以运行的控制容量。

以下公式提供分类：

control capacity = Total Memory in MB / Fork size in MB

基于 worker 节点，这可表达为：

总控制容量 = 16,000 MB / 100 MB = 160

这意味着自动化控制器被配置为同时启动 160 个作业。但是，需要对这个值进行调整才能与我们的容器组/execution plane 容量相匹配。

现在，我们计算了可用的控制容量，我们就可以确定并发自动化作业的最大数量。

要确定这一点，我们必须注意，容器组/execution plane 中的自动化作业 pod 规格具有 vCPU 250m 和 100Mi RAM 的默认请求。

使用一个 worker 节点的总内存：

16,000 MB / 100 MiB = 160 个并发作业

使用一个 worker 节点的总 CPU：

4000 millicpu / 250 millicpu = 16 个并发作业

根据以上值，我们必须将节点上的最大并发作业设置为两个并发作业值的最小 - 16。因为有两个 worker 节点分配给在我们的示例中运行自动化作业，这个数字会加倍到 32 （每个 worker 节点有 16 个并发作业）。

自动化控制器的配置目前设置为 160 个并发作业，可用的 worker 节点容量只允许 32 个并发作业。这是一个问题，因为数字没有平衡。

这意味着自动化控制器的 control plane 认为它可以同时启动 160 个作业，而 Kubernetes 调度程序只会在 Container Group 命名空间中同时调度最多 32 个自动化作业 pod。

control plane 和容器组/execution plane 之间的未平衡值可能会导致问题：

为了避免中止的作业或未使用资源的风险，建议把有效的控制容量与默认容器组支持的最大并发作业数量相平衡。

使用术语"有效控制容量"，因为 control plane 将启动的最大作业数量受名为 AWX_CONTROL_NODE_TASK_IMPACT 的设置的影响。AWX_CONTROL_NODE_TASK_IMPACT 变量定义了每个自动化作业可在控制 pod 上消耗的容量量，从而有效地控制控制 pod 将启动的自动化作业数量。

要在有效控制容量和可用执行容量之间实现平衡，我们可以将 AWX_CONTROL_NODE_TASK_IMPACT 变量设为限制要在自动化控制器 control plane 上运行的并发作业数量的值。

要计算 AWX_CONTROL_NODE_TASK_IMPACT 的最佳值，以避免启动比容器组支持的更并发自动化作业，我们可使用以下公式：

AWX_CONTROL_NODE_TASK_IMPACT = 控制容量/容器组可以启动的最大并发作业

对于我们的参考环境，这是：

AWX_CONTROL_NODE_TASK_IMPACT = 160 / 32 = 5

本参考环境的此结束，XX _CONTROL_NODE_TASK_IMPACT 应该等于 5。此值将在 第 6 章 安装自动化控制器 章节的 extra_setting 部分中设置，我们将在本文档的后面部分介绍。

正确设置 control plane (control pod)和容器组/execution plane （自动化作业 pod）的资源请求和限值，以确保控制和执行容量是均衡的。正确的配置可由以下决定：

在概述部分中所述的 图 1.2 “Automation hub 架构” 中，您会注意到部署由 7 个 pod 组成，每个 pod 托管一个容器。

pod 列表包括：

组成自动化中心架构的七种 pod 可以一起工作，以高效管理和分发内容，并且对自动化中心环境的整体性能和可扩展性至关重要。

在这些 pod 中，worker pod 特别重要，因为它们负责处理、同步和分发内容。因此，务必要将适当的资源设置为 worker pod，以确保它们能够执行任务。

在这个参考环境中，为了确定 pod 的大小，预先精简测试是使用在自动化中心环境中进行的最高内存消耗任务之一来实现的。

该发现确定，在自动化中心中成功同步远程仓库，需要为每个 pod 设置以下资源请求和资源限制：

spec:
...
content:
  resource_requirements:
    limits:
      cpu: 250mm
      memory: 400Mi
    requests:
      cpu: 100m
      memory: 400Mi

redis:
  resource_requirements:
    limits:
      cpu: 250m
      memory: 200Mi
    requests:
      cpu: 100m
      memory: 200Mi

api:
  resource_requirements:
    limits:
      cpu: 250m
      memory: 400Mi
    requests:
      cpu: 150m
      memory: 400Mi

postgres_resource_requirements:
  resource_requirements:
    limits:
      cpu: 500m
      memory: 1Gi
    requests:
      cpu: 200m
      memory: 1Gi

worker:
  resource_requirements:
    limits:
      cpu: 1000m
      memory: 3Gi
    requests:
      cpu: 400m
      memory: 3Gi

spec:
...
content:
  resource_requirements:
    limits:
      cpu: 250mm
      memory: 400Mi
    requests:
      cpu: 100m
      memory: 400Mi

redis:
  resource_requirements:
    limits:
      cpu: 250m
      memory: 200Mi
    requests:
      cpu: 100m
      memory: 200Mi

api:
  resource_requirements:
    limits:
      cpu: 250m
      memory: 400Mi
    requests:
      cpu: 150m
      memory: 400Mi

postgres_resource_requirements:
  resource_requirements:
    limits:
      cpu: 500m
      memory: 1Gi
    requests:
      cpu: 200m
      memory: 1Gi

worker:
  resource_requirements:
    limits:
      cpu: 1000m
      memory: 3Gi
    requests:
      cpu: 400m
      memory: 3Gi

在专用节点上运行控制 pod 非常重要，以便分隔控制 pod 和自动化作业 pod，并防止这两种类型的 pod 间的资源争用。这种分离有助于维护控制 pod 及其提供的服务的稳定性和可靠性，而不会因为资源限制而造成降级风险。

在此参考环境中，重点是最大程度提高可以运行的自动化作业的数量。这意味着，在 Red Hat OpenShift 环境中可用的 3 个 worker 节点，一个 worker 节点专用于运行 control pod，而其他 2 个 worker 节点则用于执行自动化作业。

spec:
...
  node_selector: |
    aap_node_type: control

spec:
...
  node_selector: |
    aap_node_type: control

spec:
...
  topology_spread_constraints: |
    - maxSkew: 1
      topologyKey: "kubernetes.io/hostname"
      whenUnsatisfiable: "ScheduleAnyway"
      labelSelector:
        matchLabels:
          aap_node_type: control
  tolerations: |
    - key: "dedicated"
      operator: "Equal"
      value: "AutomationController"
      effect: "NoSchedule"

spec:
...
  topology_spread_constraints: |
    - maxSkew: 1
      topologyKey: "kubernetes.io/hostname"
      whenUnsatisfiable: "ScheduleAnyway"
      labelSelector:
        matchLabels:
          aap_node_type: control
  tolerations: |
    - key: "dedicated"
      operator: "Equal"
      value: "AutomationController"
      effect: "NoSchedule"

在 Ansible Automation Platform 中部署自动化控制器和自动化中心组件，可以利用其 PostgreSQL 数据库的 PVC。确保这些 PVC 的可用性对于运行 Ansible Automation Platform 的稳定性至关重要。

有几个策略可用于处理 Red Hat OpenShift 集群中的 PVC 可用性，如 Crunchy Data 通过 Postgres Operator (PGO)和 OpenShift Data Foundation (ODF)提供的 PVC 的可用性。

Crunchy Data 提供 PGO (Postgres Operator)，它为您提供了一个声明性 Postgres 解决方案，用于自动管理 PostgreSQL 集群。通过 PGO，用户可以创建其 Postgres 集群，扩展并创建高可用性(HA) Postgres 集群，并将其连接到 Ansible Automation Platform 等应用程序。

OpenShift Data Foundation (ODF)是一个高度可用的存储解决方案，可以管理容器化应用程序的持久性存储。它由多种开源操作器和技术组成，包括 Ceph、NooBaa 和 Rook。这些不同的 Operator 允许您置备和管理文件、块和对象存储，然后可以连接到 Ansible Automation Platform 等应用程序。

Prometheus 和 Grafana。

Prometheus 是一个用于收集和聚合指标的开源监控解决方案。通过 Grafana 合作伙伴 Prometheus 监控功能，这是运行数据分析的开源解决方案，并在可自定义仪表板中拉取指标，并实时视觉化指标来跟踪 Ansible Automation Platform 的状态和健康状况。

Grafana 预建仪表板显示：

可以自定义此 Grafana 仪表板，以捕获您可能感兴趣的其他指标。但是，自定义 Grafana 仪表板超出了此参考架构的范围。

使用自定义 Grafana 仪表板通过 Prometheus 监控 Ansible Automation Platform 的过程可在几分钟内安装。以下提供了利用预构建的 Ansible playbook 的步骤。

成功运行 Ansible Playbook 需要以下步骤：