使用基于 Operator 的安装的 Red Hat Ansible Automation Platform 性能注意事项
本指南提供有关如何配置自动化控制器和容器组资源请求和其他 kubernetes 配置选项的建议,以根据基于自动化控制器的 Operator 安装,进行扩展来更有效地运行作业。
摘要
前言 复制链接链接已复制到粘贴板!
从操作的角度来看,将应用程序部署到容器编配平台(如 Red Hat OpenShift Container Platform)会有很多优点。例如,可以通过简单的原位升级对应用程序基础镜像进行更新,而无需中断。对于部署到传统虚拟机的应用程序所需的操作系统进行升级可能会对系统运行带来更多的破坏性和风险。
虽然应用程序和 Operator 开发人员可以为 OpenShift Container Platform 用户提供有关应用程序部署的许多选项,但这些配置必须由最终用户提供,因为它们依赖于 OpenShift Container Platform 的配置。
例如,在 Openshift 集群中使用节点标签有助于确保不同工作负载在特定节点上运行。这种类型的配置必须由用户提供,因为 Ansible Automation Platform Operator 无法实现这一点。
使开源包含更多 复制链接链接已复制到粘贴板!
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息。
第 1 章 Pod 规格的变化 复制链接链接已复制到粘贴板!
1.1. 简介 复制链接链接已复制到粘贴板!
pod 的 Kubernetes 概念是共同部署在同一主机上的一个或多个容器,也是可被定义、部署和管理的最小计算单元。
Pod 等同于一个容器的虚拟机实例(物理或虚拟)。每个 pod 分配有自己的内部 IP 地址,因此拥有完整的端口空间,并且 pod 内的容器可以共享其本地存储和网络。
Pod 具有生命周期。它们经过定义后,被分配到某一节点上运行,然后持续运行,直到容器退出或它们因为其他原因被删除为止。根据策略和退出代码,Pod 可在退出后删除,或被保留下来以启用对容器日志的访问。
Red Hat Ansible Automation Platform 提供了一个简单的默认 Pod 规格,但您可以提供一个自定义 YAML 或 JSON 文档来覆盖默认 Pod 规格。此自定义文档使用自定义字段,如 ImagePullSecrets,可序列化为有效的 Pod JSON 或 YAML。
可在 Openshift 文档中找到完整的选项列表。
提供长时间运行的服务的 pod 示例。
这个示例展示了 pod 的许多特性,其中大多数已在其他主题中阐述,因此这里仅简略提及:
| 标签 | 描述 |
|---|---|
|
|
pod 可以被“标上”一个或多个标签,然后使用这些标签在一个操作中选择和管理多组 pod。标签以 key:value 格式存储在 metadata 散列中。本例中的一个标签是 |
|
|
Pod 在其命名空间内需要具有唯一名称。pod 定义可以使用 |
|
|
|
|
| 环境变量将必要的值传递给每个容器。 |
|
| pod 中的每个容器使用自己的 Docker 格式的容器镜像进行安装。 |
|
| 容器可以绑定到 pod IP 上提供的端口。 |
|
| 指定 Pod 时,您可以选择性地描述容器需要的资源量。要指定的最常见资源是 CPU 和内存 (RAM)。其他资源可用。 |
|
| OpenShift Online 为容器定义了一个安全上下文,用于指定是否允许其作为特权容器运行,作为所选用户运行,等等。默认上下文的限制性比较强,但管理员可以根据需要进行修改。 |
|
| 容器指定外部存储卷应当挂载到容器内的什么位置上。在本例中,一个卷用于存储 registry 的数据,另一个卷则提供凭证的访问途径,registry 需要这些凭证来向 OpenShift Online API 发出请求。 |
|
|
一个 pod 可以包含一个或多个容器,这些容器必须从某些 registry 中拉取。如果容器来自需要身份验证的 registry,您可以提供一个 |
|
|
pod 重启策略,可能的值为 |
|
|
Pod 对 OpenShift Online API 发出请求是一种比较常见的模式,它有一个 |
|
| pod 定义了可供其容器使用的存储卷。在本例中,它提供了一个用于存储 registry 的临时卷,以及一个包含服务帐户凭证的 secret 卷。 |
您可以通过编辑自动化控制器 UI 中的 pod 规格来修改在基于 Kubernetes 的集群中运行作业的 pod。用于创建运行作业的 pod 的 pod 规格,采用 YAML 格式。有关编辑 pod 规格的更多信息,请参阅自定义 pod 规格。
1.1.1. 自定义 pod 规格 复制链接链接已复制到粘贴板!
您可以使用以下步骤自定义 pod。
流程
- 在自动化控制器 UI 中,进入到 → 。
- 检查。
- 在 Pod Spec Override 字段中,使用切换来指定命名空间来启用和扩展 Pod Spec Override 字段。
- 点击 。
- 可选:如果要提供额外的自定义,点 查看整个自定义窗口。
作业启动时使用的镜像由与作业关联的执行环境决定。如果 Container Registry 凭证与执行环境关联,则自动化控制器将使用 ImagePullSecret 来拉取镜像。如果您不想授予服务帐户管理 secret 的权限,您必须预先创建 ImagePullSecret,在 pod 规格中指定它,并从使用的执行环境省略任何凭证。
1.1.2. 启用 Pod 引用其他安全 registry 中的镜像 复制链接链接已复制到粘贴板!
如果容器组使用需要凭证的安全 registry 中的容器,您可以将 Container Registry 凭证与分配给作业模板的 Execution Environment 关联。自动化控制器使用它来在容器组作业运行的 OpenShift Container Platform 命名空间中创建 ImagePullSecret,并在作业完成后进行清理。
另外,如果容器组命名空间中已存在 ,您可以在 ContainerGroup 的自定义 pod 规格中指定 ImagePullSecret。
ImagePullSecret
请注意,容器组中运行的作业所使用的镜像始终被与作业关联的执行环境覆盖。
使用预先创建的 ImagePullSecrets (高级)
如果要使用此工作流并预先创建 ImagePullSecret,您可以提供所需的信息,以便从之前访问安全容器 registry 的系统上本地 .dockercfg 文件创建它。
流程
用于较新的 Docker 客户端的 .dockercfg 文件或 $HOME/.docker/config.json 是一个 Docker 凭证文件,如果您之前已登录到安全或不安全的 registry,则该文件会保存您的信息。
如果您已经为安全 registry 有一个
.dockercfg文件,您可以通过运行以下命令来从该文件中创建 secret:oc create secret generic <pull_secret_name> \ --from-file=.dockercfg=<path/to/.dockercfg> \ --type=kubernetes.io/dockercfg
$ oc create secret generic <pull_secret_name> \ --from-file=.dockercfg=<path/to/.dockercfg> \ --type=kubernetes.io/dockercfgCopy to Clipboard Copied! Toggle word wrap Toggle overflow 或者,如果您有一个
$HOME/.docker/config.json文件:oc create secret generic <pull_secret_name> \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
$ oc create secret generic <pull_secret_name> \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您还没有安全 registry 的 Docker 凭证文件,您可以通过运行以下命令来创建 secret:
oc create secret docker-registry <pull_secret_name> \ --docker-server=<registry_server> \ --docker-username=<user_name> \ --docker-password=<password> \ --docker-email=<email>
$ oc create secret docker-registry <pull_secret_name> \ --docker-server=<registry_server> \ --docker-username=<user_name> \ --docker-password=<password> \ --docker-email=<email>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要使用 secret 为 Pod 拉取镜像,您必须将 secret 添加到您的服务帐户中。本例中服务帐户的名称应与 Pod 使用的服务帐户的名称匹配。默认为 default 服务帐户。
oc secrets link default <pull_secret_name> --for=pull
$ oc secrets link default <pull_secret_name> --for=pullCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:要使用 secret 来推送和拉取 (pull) 构建镜像,该 secret 必须可在 pod 内挂载。您可通过运行以下命令实现这一目的:
oc secrets link builder <pull_secret_name>
$ oc secrets link builder <pull_secret_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 可选: 对于构建,还必须将 secret 引用为构建配置中的 pull secret。
成功创建容器组后,新创建的容器组的 Details 选项卡将保留,供您查看和编辑容器组信息。如果从 实例组 链接中点 ,则打开这个菜单。您还可以编辑实例,并查看与此实例组关联的作业。
1.2. pod 和容器的资源管理 复制链接链接已复制到粘贴板!
指定 Pod 时,您可以指定容器需要的每个资源量。要指定的最常见资源是 CPU 和内存 (RAM)。
当您为 Pod 中的容器指定资源请求时,kubenetes-scheduler 会使用此信息分配节点来放置 Pod。
当您为容器、kubelet 或节点代理指定资源限值时,会强制实施这些限制,以便不允许正在运行的容器使用该资源比您设置的限制更多。kubelet 还至少保留针对该容器使用的系统资源的请求数量。
1.2.1. 请求和限值 复制链接链接已复制到粘贴板!
如果运行 Pod 的节点有足够的可用资源,容器可以使用超过其对该资源的请求数量的资源。但是,容器不允许使用超过其资源的限值。
例如,如果您为容器设置了 256 MiB 的内存请求,且该容器位于调度到具有 8GiB 内存且没有其他 Pod 的节点的 Pod 中,则容器可以尝试使用更多 RAM。
如果为该容器设置了 4GiB 的内存限值,kubelet 和容器运行时会强制实施限制。运行时可防止容器使用超过配置的资源限值。
如果容器中的进程尝试消耗超过允许的内存量,系统内核会终止尝试分配的进程,并显示 Out Of Memory (OOM)错误。
您可以通过两种方式实施限制:
- 通过重新主动:系统在看到违反情况后进行干预。
- 通过强制:系统可防止容器超过限制。
不同的运行时可以有不同的方法来实施相同的限制。
如果您为资源指定限制,但没有指定任何请求,且没有为该资源应用一个默认请求,则 Kubernetes 会复制您指定的限制,并将它用作资源的请求值。
1.2.2. 资源类型 复制链接链接已复制到粘贴板!
CPU 和内存都是资源类型。资源类型具有一个基本单元。CPU 代表计算处理,并以 Kubernetes CPU 单位指定。内存以字节为单位指定。
CPU 和内存统称为计算资源或资源。计算资源是可请求、分配和消耗的可测量数量。它们与 API 资源不同。API 资源(如 Pod 和服务)是可通过 Kubernetes API 服务器读取和修改的对象。
1.2.3. 为 pod 和容器指定资源请求和限值 复制链接链接已复制到粘贴板!
对于每个容器,您可以指定资源限值和请求,包括:
spec.containers[].resources.limits.cpu spec.containers[].resources.limits.memory spec.containers[].resources.requests.cpu spec.containers[].resources.requests.memory
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
虽然您只能为单个容器指定请求和限值,但考虑 Pod 的整体资源请求和限值也很有用。对于特定资源,Pod 资源请求/limit 是 Pod 中每个容器这个类型的资源请求/限制总和。
1.2.4. Kubernetes 中的资源单元 复制链接链接已复制到粘贴板!
CPU 资源单元
CPU 资源的限制和请求以 CPU 单位计算。在 Kubernetes 中,1 个 CPU 单元相当于 1 个物理处理器内核,或者 1 个虚拟内核,具体取决于节点是物理主机还是在物理机中运行的虚拟机。
允许部分请求。当您定义将 spec.containers[].resources.requests.cpu 设置为 0.5 的容器时,如果您请求 1.0 CPU,将请求一半的 CPU 时间。对于 CPU 资源单元,数量表达式 0.1 等同于表达式 100m,它可以显示为一百个 millicpu 或一百个 millicores。millicpu 和 millicores 实际是相同的。CPU 资源始终指定为绝对数量的资源,而不是作为相对数量指定。例如,500m CPU 代表容器在单核、双核或 48 核机器上运行的计算能力。
要指定小于 1.0 或 1000m 的 CPU 单元,您必须使用 milliCPU 格式。例如,使用 5m,而不是 0.005 CPU。
内存资源单元
内存的限制和请求以字节为单位。您可以使用这些数量后缀之一将内存表示为普通整数或固定点号: E、P、T、G、M、k。您还可以使用两的指数:Ei、Pi、Ti、Gi、Mi Ki。例如,以下代表相同的值:
128974848, 129e6, 129M, 128974848000m, 123Mi
128974848, 129e6, 129M, 128974848000m, 123Mi
请注意它们的后缀。如果您请求 400m 内存,则请求为 0.4 字节,而不是 400 兆字节 (400Mi) 或 400 MB (400M)。
CPU 和内存规格示例
以下集群有足够的可用资源来调度带有专用 100m CPU 和 250Mi 的任务 pod。集群也可以超过该专用用量,最多 2000m CPU 和 2Gi 内存。
自动化控制器不会调度使用超过限制集的资源的作业。如果任务 pod 使用的资源超过限制集,则容器会由 kubernetes 和 restarted OOMKilled。
1.2.5. 资源请求的大小建议 复制链接链接已复制到粘贴板!
所有使用容器组的作业都使用相同的 Pod 规格。Pod 规格包括运行作业的 pod 的资源请求。
所有作业都使用相同的资源请求。pod 规格中特定作业的指定资源请求会影响 Kubernetes 根据 worker 节点上可用的资源调度作业 pod。这些是默认值。
-
一个分叉通常需要 100Mb 内存。这是使用
system_task_forks_mem设置的。如果您的作业有五个分叉,则作业 pod 规格必须请求 500Mb 内存。 - 对于具有特别高 fork 值或需要更大的资源请求的作业模板,您应该使用不同的 pod 规格创建单独的容器组,以指示更大的资源请求。然后,您可以将它分配给作业模板。例如,一个 fork 值为 50 的作业模板必须与请求 5GB 内存的容器组配对。
- 如果某个作业的 fork 值足够大,没有单个 pod 可以包含该作业,请使用作业分片功能。这会分割清单,使单个作业"slices"适合由容器组调配的自动化 pod。
第 2 章 控制平面(control plane)调整 复制链接链接已复制到粘贴板!
control plane 指的是包含 web 和任务容器(除其他方面)的自动化控制器 pod,它提供了用户界面并处理作业的调度和启动。在自动化控制器自定义资源上,副本数量 决定了自动化控制器部署中自动化控制器 pod 的数量。
2.1. 任务容器的请求和限值 复制链接链接已复制到粘贴板!
您必须为任务容器的 CPU 和内存限值设置一个值。对于在执行节点上运行的每个作业,必须在 control plane 上处理来调度、启动和接收该作业的回调事件。
对于自动化控制器的 Operator 部署,这个 control plane 容量使用量在 controlplane 实例组上跟踪。可用的容量取决于任务容器上的用户设置的限制,使用自动化控制器规格中的 task_resource_requirements 字段,或者在创建自动化控制器时在 OpenShift UI 中决定。
您还可以设置对集群有意义的内存和 CPU 资源限值。
2.2. 容器资源要求 复制链接链接已复制到粘贴板!
您可以在下限 (requests) 和上限 (limits) 和 Web 容器配置资源要求。执行环境 control plane 用于项目更新,但通常与作业的默认执行环境相同。
设置资源请求和限值是最佳实践,因为定义了这两个容器具有更高的 服务质量 类。这意味着,如果底层节点受资源约束,且集群必须获得 pod 以防止运行内存或其他故障,则 control plane pod 不太可能被获取。
这些请求和限值适用于自动化控制器的控制 pod,以及是否设置了限制,请确定实例 的容量。默认情况下,控制作业需要 1 个容量单元。任务容器的内存和 CPU 限制用于决定控制节点的容量。有关如何计算它的更多信息,请参阅 Resouce determination。
另请参阅 worker 节点上调度的作业
| 名称 | 描述 | default |
|---|---|---|
|
| Web 容器资源要求 | 请求:{CPU: 100m, memory: 128Mi} |
|
| 任务容器资源要求 | 请求:{CPU: 100m, memory: 128Mi} |
|
| EE control plane 容器资源要求 | 请求:{CPU: 100m, memory: 128Mi} |
|
| Redis control plane 容器资源要求 | requests: {CPU:100m, memory: 128Mi} |
因为使用 topology_spread_constraints 来最大将控制节点分散到单独的底层 kubernetes worker 节点上,因此合理的请求和限制集会限制其总和等于节点上实际资源的限制。如果只设定了 限制,则请求会自动设置为等于限制。但是,由于控制 pod 中容器之间的资源使用量有一些变量,因此您可以 将请求 设置为较低数量,例如,节点上可用的资源的 25%。对于 worker 节点有 4 个 CPU 和 16 GB RAM 的集群,容器自定义示例如下:
2.3. 使用自动化控制器设置的替代容量限制 复制链接链接已复制到粘贴板!
Openshift 中控制节点的容量由内存和 CPU 限值决定。但是,如果没有设置它们,则容量由文件系统上的 pod 检测到的内存和 CPU 决定,而这是底层 Kubernetes 节点的 CPU 和内存。
如果自动化控制器 pod 不是该节点上的唯一 pod,这可能会导致意外出现底层 Kubernetes pod 的问题。如果您不想直接在任务容器上设置限制,您可以使用 extra_settings,请参阅 Custom pod timeout 部分中的 Extra Settings 以了解如何配置以下内容
SYSTEM_TASK_ABS_MEM = 3gi SYSTEM_TASK_ABS_CPU = 750m
SYSTEM_TASK_ABS_MEM = 3gi
SYSTEM_TASK_ABS_CPU = 750m
这充当应用程序中的软限制,使自动化控制器能够控制它试图运行的工作量,同时不会面临 Kubernetes 本身的任何 CPU 节流,或者在内存使用量超过所需限制时获得。这些设置接受 kubernetes 资源定义中资源请求和限值接受的相同格式。
第 3 章 指定专用节点 复制链接链接已复制到粘贴板!
kubernetes 集群在多个虚拟机或节点之上运行(通常位于 2 到 20 个节点之间的任何位置)。pod 可以调度到其中任何节点上。当您创建或调度新 pod 时,请使用 topology_spread_constraints 设置来配置在调度或创建时如何在底层节点上分发新 pod。
不要将 pod 调度到单个节点上,因为如果该节点失败,则这些 pod 提供的服务也会失败。
将 control plane 节点调度到不同节点上运行到自动化作业 pod。如果 control plane pod 与作业 pod 共享节点,control plane 可能会成为资源不足并降低整个应用程序的性能。
3.1. 将 Pod 分配给特定的节点 复制链接链接已复制到粘贴板!
您可以将 operator 创建的控制器 pod 限制为在特定的节点子集中运行。
-
node_selector和postgres_selector将自动化控制器 pod 限制为仅在匹配所有指定键或值对的节点上运行。 -
tolerations和postgres_tolerations允许将自动化控制器 pod 调度到具有匹配污点的节点。如需了解更多详细信息,请参阅 Kubernetes 文档中的 污点和容限。
下表显示了可以在 YAML 的自动化控制器规格部分(或使用 Openshift UI 表单)上设置的设置和字段。
| 名称 | 描述 | default |
|---|---|---|
|
| 要拉取镜像的路径 | postgres |
|
| 要拉取的镜像版本 | 13 |
|
| Automationcontroller pod 的 nodeSelector | “”’’ |
|
| Automationcontroller pod 的 topologySpreadConstraints | “”’’ |
|
| Automationcontroller pod 的容限 | “”’’ |
|
| Automationcontroller pod 的注解 | “”’’ |
|
| Postgres pod 的 nodeSelector | “”’’ |
|
| Postgres pod 的容限 | “”’’ |
topology_spread_constraints 可帮助优化在与节点选择器匹配的计算节点上分散 control plane pod。例如,如果此选项的 maxSkew 参数设置为 100,这意味着最大地分散到可用节点上。因此,如果存在与计算节点和 3 个 pod 匹配的 3 个 pod,则会为每个计算节点分配 1 个 pod。此参数有助于防止 control plane pod 相互竞争资源。
将控制器 pod 限制到特定节点的自定义配置示例
3.2. 指定用于作业执行的节点 复制链接链接已复制到粘贴板!
您可以将节点选择器添加到容器组 pod 规格中,以确保它们仅针对某些节点运行。首先为您要对其运行作业的节点添加标签。
以下流程为节点添加标签。
流程
列出集群中的节点,及其标签:
kubectl get nodes --show-labels
kubectl get nodes --show-labelsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出结果与此相似(在此处显示在表中):
Expand 名称 Status 角色 年龄 Version 标签 worker0Ready
<none>
1d
v1.13.0
…,kubernetes.io/hostname=worker0worker1Ready
<none>
1d
v1.13.0
…,kubernetes.io/hostname=worker1worker2Ready
<none>
1d
v1.13.0
…,kubernetes.io/hostname=worker2选择其中一个节点,并使用以下命令向其添加标签:
kubectl label nodes <your-node-name> <aap_node_type>=<execution>
kubectl label nodes <your-node-name> <aap_node_type>=<execution>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如:
kubectl label nodes <your-node-name> disktype=ssd
kubectl label nodes <your-node-name> disktype=ssdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<your-node-name> 是您选择的节点的名称。验证您选择的节点是否具有
disktype=ssd标签:kubectl get nodes --show-labels
kubectl get nodes --show-labelsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出结果与此相似(在此处显示在表中):
Expand 名称 Status 角色 年龄 Version 标签 worker0Ready
<none>
1d
v1.13.0
…disktype=ssd,kubernetes.io/hostname=worker0worker1Ready
<none>
1d
v1.13.0
…,kubernetes.io/hostname=worker1worker2Ready
<none>
1d
v1.13.0
…,kubernetes.io/hostname=worker2您可以看到
worker0节点现在有一个disktype=ssd标签。- 在自动化控制器 UI 中,在容器组中自定义 pod 规格的 metadata 部分中指定该标签。
额外设置
使用 extra_settings 时,您可以使用 awx-operator 传递多个自定义设置。参数 extra_settings 附加到 /etc/tower/settings.py,并可替代 extra_volumes 参数。
| 名称 | 描述 | default |
|---|---|---|
|
| 额外设置 | ‘’ |
extra_settings 参数配置示例
3.3. 自定义 pod 超时 复制链接链接已复制到粘贴板!
在将 pod 提交到 Kubernetes API 之前,自动化控制器中的容器组作业会过渡到 running 状态。然后,自动化控制器需要 pod 在 AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT 秒前进入 Running 状态。如果您希望自动化控制器在取消无法进入 Running 状态的作业前,您可以将 AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT 设置为更高的值。AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT 是自动化控制器从创建 pod 等待多久,直到 Ansible 工作在 pod 中开始为止。如果 pod 无法调度资源限制,您也可以延长时间。您可以在自动化控制器规格中使用 extra_settings 完成此操作。默认值为 2 小时。
如果您始终启动更多作业,超过 Kubernetes 可调度的作业,并且作业会花费时间超过 pending 中的 AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT。
在控制容量可用前,才会启动作业。如果启动多个作业,超过容器组有能力运行,请考虑扩展 Kubernetes worker 节点。
3.4. 在 worker 节点上调度的作业 复制链接链接已复制到粘贴板!
自动化控制器和 Kubernetes 在调度作业时扮演一个角色。
启动作业时,其依赖项就会实现,这意味着作业模板、项目和清单设置的要求由自动化控制器启动任何项目更新或清单更新。
如果自动化控制器中的其他业务逻辑没有阻断作业,则 control plane 中有控制容量来启动作业,则会将作业提交到分配程序。控制作业的"成本"的默认设置是 1 个 容量。因此,具有 100 个容量的控制 pod 一次只能控制 100 个作业。给定控制容量,作业将从 pending 过渡到 等待。
分配程序(即控制计划 pod 中的后台进程)启动一个 worker 进程来运行作业。这通过使用与容器组关联的服务帐户与 kubernetes API 通信,并使用自动化控制器中的 Container Group 中定义的 pod 规格来置备 pod。自动化控制器中的作业状态显示为 运行。
Kubernetes 现在调度 pod。pod 可以保持 AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT 的 待处理状态。如果容器集通过 ResourceQuota 拒绝,则该作业将从 pending 开始。您可以在命名空间中配置资源配额,以限制命名空间中的 pod 可消耗的资源数量。有关 ResourceQuota 的更多信息,请参阅资源配额。
第 4 章 在 OpenShift Container Platform 中配置 Ansible 自动化控制器 复制链接链接已复制到粘贴板!
在 Kubernetes 升级过程中,自动化控制器必须正在运行。
4.1. 最小化 OpenShift Container Platform 升级过程中的停机时间 复制链接链接已复制到粘贴板!
在自动化控制器中进行以下更改,以便尽可能减少升级过程中的停机时间。
先决条件
- Ansible Automation Platform 2.4
- Ansible 自动化控制器 4.4
OpenShift Container Platform
- > 4.10.42
- > 4.11.16
- > 4.12.0
- Postgres 的高可用性(HA)部署
- 可以调度自动化控制器 pod 的多个 worker 节点
流程
在 AutomationController 规格中启用
RECEPTOR_KUBE_SUPPORT_RECONNECT:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 AutomationController 规格中启用安全终止功能:
termination_grace_period_seconds: <time to wait for job to finish>
termination_grace_period_seconds: <time to wait for job to finish>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为 Web 和任务 pod 配置
podAntiAffinity,将部署分散到 AutomationController 规格中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 OpenShift Container Platform 中配置
PodDisruptionBudget:Copy to Clipboard Copied! Toggle word wrap Toggle overflow