对于每个 Kubernetes 资源，您可以配置两种类型的要求 - 请求和限制。 第一个描述了运行容器或 Pod 所需的可用节点资源的最低要求，第二个严格限制容器可用的资源。
当 Kubernetes 调度 pod 时，容器有足够的资源来正常运行非常重要。 如果您计划在资源受限的节点上部署大型应用程序，则该应用程序可能无法运行，因为该节点内存不足或 CPU 资源不足。 在本文中，我们将了解如何使用资源请求和限制来解决计算能力短缺问题。
请求和限制是 Kubernetes 用于管理 CPU 和内存等资源的机制。 请求确保容器接收到所请求的资源。 如果容器请求资源，Kubernetes 只会将其调度到可以提供该资源的节点上。 Limits控制容器请求的资源永远不会超过某个值。
容器只能将计算能力提高到一定限度，超过限度后计算能力就会受到限制。 让我们看看它是如何工作的。 因此，有两种类型的资源：处理器和内存。 Kubernetes 调度程序使用有关这些资源的数据来确定在哪里运行 Pod。 Pod 的典型资源规范如下所示。
Pod 中的每个容器都可以设置自己的查询和限制，这些都是附加的。 处理器资源以毫核为单位定义。 如果您的容器需要两个完整核心来运行，则将该值设置为 2000m。 如果容器只需要1/4核心的功率，则该值为250m。 请记住，如果您分配的 CPU 资源值大于最大节点的核心数，则您的 pod 根本不会被安排启动。 如果您有一个需要四个核心的 Pod，并且 Kubernetes 集群仅由两个主虚拟机组成，也会出现类似的情况。
除非您的应用程序是专门为利用多核而设计的（例如复杂的科学计算和数据库操作之类的程序），否则最佳实践是将 CPU 请求设置为 1 或更低，然后运行更多副本以实现可扩展性。 该解决方案将赋予系统更大的灵活性和可靠性。
当谈到 CPU 限制时，事情变得更有趣，因为它被认为是可压缩资源。 如果您的应用程序开始接近处理器功率限制，Kubernetes 将开始使用 CPU 限制来减慢您的容器 - 降低处理器频率。 这意味着 CPU 将被人为限制，从而使应用程序的性能可能更差，但进程不会被终止或取出。
内存资源以字节为单位定义。 通常设置中的值以兆字节 Mib 为单位，但您可以设置从字节到拍字节的任何值。 这里适用与 CPU 相同的情况 - 如果您发出的内存量请求大于节点上的内存量，则不会安排该 pod 执行。 但与 CPU 资源不同的是，内存不会被压缩，因为无法限制其使用。 因此，一旦超出分配给它的内存，容器的执行就会停止。
请务必记住，您配置的请求不能超出节点可以提供的资源。 GKE 虚拟机的共享资源规范可以在此视频下面的链接中找到。
在理想情况下，容器的默认设置足以保持工作流程顺利运行。 但现实世界并非如此，人们很容易忘记配置资源的使用，或者黑客会设置超出基础设施实际能力的请求和限制。 为了防止这种情况发生，您可以配置ResourceQuota和LimitRange资源配额。
创建命名空间后，可以使用配额来阻止它。 例如，如果您有 prod 和 dev 命名空间，则模式是根本没有生产配额，并且有非常严格的开发配额。 这使得 prod 在流量急剧激增的情况下可以接管整个可用资源，完全阻塞 dev。
资源配额可能如下所示。 在此示例中，有 4 个部分 - 这些是最后 4 行代码。
让我们逐一看看。 Requests.cpu 是来自命名空间中所有容器的最大组合 CPU 请求数。 在此示例中，您可以有 50 个具有 10m 请求的容器、100 个具有 500m 请求的容器，或者只有 500 个具有 XNUMXm 请求的容器。 只要给定命名空间的requests.cpu总数小于XNUMXm，就一切正常。
内存请求 requests.memory 是命名空间中所有容器可以拥有的最大组合内存请求量。 与前面的情况一样，只要命名空间中请求的内存总量小于 50 MB，您就可以拥有 2 个 20 mib 容器、五个 100 mib 容器或一个 100 mib 容器。
Limits.cpu 是命名空间中所有容器可以使用的最大 CPU 功率组合。 我们可以认为这是处理器功率请求的限制。
最后，limits.memory 是命名空间中所有容器可以使用的最大共享内存量。 这是对总内存请求的限制。
因此，默认情况下，Kubernetes 集群中的容器以无限的计算资源运行。 通过资源配额，集群管理员可以基于命名空间限制资源消耗和资源创建。 在命名空间中，Pod 或容器可以消耗由命名空间资源配额确定的尽可能多的 CPU 功率和内存。 然而，人们担心一个 Pod 或容器可能会垄断所有可用资源。 为了防止这种情况，使用了限制范围——一种限制命名空间中资源分配（针对 Pod 或容器）的策略。
限制范围提供的限制可以：
- 确保命名空间中每个模块或容器计算资源的最小和最大使用量；
- 对命名空间中的每个 PersistentVolumeClaim 强制执行最小和最大 Starage Request 存储请求；
- 强制命名空间中资源的请求和限制之间的关系；
- 为命名空间中的计算资源设置默认请求/限制，并在运行时自动将它们注入到容器中。
这样您就可以在命名空间中创建限制范围。 与适用于整个命名空间的配额不同，限制范围适用于单个容器。 这可以防止用户在命名空间内创建非常小的或相反的巨大容器。 极限范围可能如下所示。
与前面的情况一样，这里可以区分 4 个部分。 让我们逐一看看。
default 部分设置 pod 中容器的默认限制。 如果将这些值设置为极限范围，则任何尚未显式设置这些值的容器都将遵循默认值。
默认请求部分defaultRequest配置Pod中容器的默认请求。 同样，如果将这些值设置为极限范围，则任何未显式设置这些选项的容器都将默认为这些值。
max 部分指定可以为 pod 中的容器设置的最大限制。 默认部分和容器限制中的值不能设置超过此限制。 需要注意的是，如果该值设置为 max 并且没有默认部分，则最大值将成为默认值。
min 部分指定可以为 pod 中的容器设置的最小请求。 但是，容器的默认部分和查询中的值不能设置低于此限制。
再次需要注意的是，如果设置了该值，而默认值未设置，则最小值将成为默认提示。
这些资源请求最终由 Kubernetes 调度程序用来执行您的工作负载。 为了正确配置容器，了解其工作原理非常重要。 假设您想在集群中运行多个 Pod。 假设 Pod 规范有效，Kubernetes 调度将使用循环平衡来选择一个节点来运行工作负载。
Kubernetes 将检查节点 1 是否有足够的资源来满足 pod 容器的请求，如果没有，它将转移到下一个节点。 如果系统中没有一个节点能够满足请求，Pod 将进入 Pending 状态。 使用 Google Kubernetes 引擎功能（例如节点自动缩放），GKE 可以自动检测等待状态并创建更多节点。
如果您随后耗尽了节点容量，自动扩展将减少节点数量以节省资金。 这就是 Kubernetes 根据请求来调度 pod 的原因。 然而，限制可能高于请求，并且在某些情况下，节点实际上可能耗尽资源。 我们称这种状态为过度承诺状态。
正如我所说，当涉及到 CPU 时，Kubernetes 将开始限制 Pod。 每个 pod 将接收其请求的数量，但如果未达到限制，将开始应用限制。
当涉及到内存资源时，Kubernetes 被迫决定删除哪些 pod，保留哪些 pod，直到释放系统资源，否则整个系统将崩溃。
让我们想象一个场景，如果您的机器内存不足 - Kubernetes 将如何处理？
Kubernetes 将查找使用的资源多于其请求的 pod。 因此，如果您的容器根本没有请求，这意味着它们默认使用超出其要求的数量，仅仅是因为它们根本没有要求任何东西！ 此类容器成为关闭的主要候选者。 下一个候选者是已满足所有请求但仍低于最大限制的容器。
因此，如果 Kubernetes 发现多个 pod 超出了其请求参数，它会按优先级对它们进行排序，然后删除优先级最低的 pod。 如果所有 pod 都具有相同的优先级，那么 Kubernetes 将终止那些超出其请求次数的 pod。
在极少数情况下，Kubernetes 可能会中止仍在其请求范围内的 pod。 当关键系统组件（例如 Kubelet 代理或 Docker）开始消耗比为其保留的资源更多的资源时，就会发生这种情况。
所以，在小公司的早期阶段，Kubernetes 集群可以在不设置资源请求和限制的情况下正常工作，但随着你的团队和项目开始规模增长，你就有在这方面遇到问题的风险。 向模块和命名空间添加查询和约束只需很少的额外工作，并且可以节省很多麻烦。
一些广告🙂
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的内容？ 通过下订单或推荐给朋友来支持我们， , 我们为您发明的入门级服务器的独特模拟： （适用于 RAID1 和 RAID10，最多 24 个内核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 数据中心便宜 2 倍？ 只有这里 在荷兰！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 阅读
来源： habr.com