第 3 章 开始前

资源请求是容器正确运行和正常工作所需的最小资源量。Kubernetes 调度程序使用这个值来确保有足够的资源可供容器使用。

另一方面，资源限值是容器可以使用的最大资源量。设置资源限值可确保容器不会消耗的资源超过应该的资源，这可能会导致其他容器遭遇资源不足。

当它指向 AAP 时，设置正确的资源请求和限值至关重要。资源分配可能会导致控制 pod 终止，从而导致自动化控制器中的所有自动化作业丢失。

在设置正确的资源管理值时，组织需要根据可用资源考虑最适合其需求的架构。例如，确定其 Ansible Automation Platform 环境的高可用性是否比最大化运行自动化作业的容量更重要。

为了更好地说明，让我们获得此参考架构中使用的现有 Red Hat OpenShift 环境。它由以下几项组成：

这些节点由 4 个 vCPU 和 16 GiB RAM 组成。

由于 Red Hat OpenShift 集群的 control plane 节点没有运行任何应用程序，因此示例侧重于可用的 3 个 worker 节点。

对于这 3 个 worker 节点，我们需要确定更重要的信息：最大化 Ansible Automation Platform 的可用性或运行尽可能多的自动化作业？

如果可用性非常重要，则重点是确保两个控制 pod 在单独的 worker 节点上运行（如 worker0 和 worker1），而所有自动化作业都在剩余的 worker 节点上运行（如 worker2）。

但是，这可减少运行自动化作业的资源（以半计），因为推荐的做法是将控制 pod 和自动化 pod 分隔开来。

如果要最大化运行自动化作业的数量是主要目标，那么对控制 pod 使用一个 worker 节点（如 worker0）并使用剩余的两个 worker 节点（例如， worker1 和 worker2）来运行自动化作业会加倍可用的资源，但代价是 control pod 的冗余。

当然，解决方案可能同样重要，在这种情况下，额外的资源（例如添加更多 worker 节点）需要满足这两个要求。