Kubernetes 请求和限制揭秘
每天分享最新软件开发，Devops，敏捷，测试以及项目管理最新，最热门的文章，每天花3分钟学习何乐而不为，希望大家点赞，评论，加关注，你的支持是我最大的动力。下方抖音有我介绍自动化测试，以及google cloud 相关视频课程，欢迎观看。
注意：这是涵盖 Kubernetes 资源管理和优化的五部分系列的第二部分。在本文中，我们将解释 Kubernetes 请求和限制。你可以 看看 第一部分 解释 Kubernetes 资源类型。
Kubernetes 提供了一个共享资源池，它根据我们配置容器化应用程序的方式进行分配。当调度程序将 pod 放置在节点上时，就会发生分配过程。调度器检查完容器的资源配置后，选择一个可以保证容器配置指定的资源可用的节点。然后它将容器的 pod 放置在合适的节点上。通常，这可以确保部署的微服务不会遇到资源短缺。
但是，某些工作负载可能需要比容器化应用程序配置使用的资源更多的资源。如果无法限制应用程序可以请求使用的资源，我们的应用程序可能会导致成本过高、资源浪费、应用程序性能不佳甚至应用程序故障的任何组合。因此，必须实施边界系统以防止资源浪费和代价高昂的故障。
这就是为什么资源请求和限制是 Kubernetes 环境的重要组成部分。
资源请求请求是指必须为容器保留的资源。包含资源请求可确保容器至少接收请求的内容。
当容器包含资源请求时，调度程序可以确保它分配 pod 的节点将保证必要资源的可用性。
资源限制限制是允许容器使用的最大资源量。当我们不配置限制时，Kubernetes 会自动选择一个。因此，当限制配置不当时——无论是开发人员还是 Kubernetes——我们可能会遇到许多不愉快且代价高昂的后果。
这些后果，我们稍后将更深入地探讨，包括不必要的高云成本和由于 CPU 节流和内存不足 (OOM) 错误导致的性能不佳。
虽然有多种类型的资源，但在本文中，我们将重点关注 CPU 和内存。我们将这些资源统称为“计算资源”。
CPU 和内存请求和限制中央处理器在 Kubernetes 环境中，CPU 代表整体处理能力。我们在 Kubernetes CPU 中测量它，其中一个 CPU 单元代表一个物理 CPU 或虚拟内核。
为了适应各种应用程序类型，我们可以非常精确地表达 CPU 测量值——低至 CPU 或内核的 1/1000。例如，如果我们想要请求 0.5 个 CPU，我们应该将其表示为 500m——其中 m 代表毫核：
cpu: "500m"在创建容器时，我们可以在 manifest 中使用resources:requestsandresources:limits来指定 CPU 资源：
apiVersion: v1kind: Podmetadata: name: example-pod namespace: example-namespacespec: containers: - name: example-name image: repo/example-image resources: limits: cpu: "500m" requests: cpu: "250m"在上面的示例中，我们将容器请求的 CPU 指定为 250m，限制为 500m。这意味着将为容器保留的处理能力为 250m。此外，如果一个进程需要超过 250m，它可以访问调度程序将确保在节点上可用的额外 CPU 资源——最多 500m 限制。
内存内存资源以字节为单位，可以表示为定点数、整数或 2 的幂等值。我们将使用最常见的表达式类型——2 的幂等价，Mi. 这代表一个兆字节，或 2个 20字节。
例如：
memory: “258Mi”就像我们对 CPU 所做的那样，我们可以在清单中使用resources:requestsandresources:limits来指定内存资源请求和限制。
让我们在下面的清单中添加内存请求和限制：
apiVersion: v1kind: Podmetadata: name: example-pod namespace: example-namespacespec: containers: - name: example-name image: repo/example-image resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"使用此清单创建的容器将保证和保留 64Mi 的内存。如果一个进程需要更多并且它在节点上可用，它可以访问额外的数量，只要它不超过 128Mi 限制。
此外，如果容器指定了它的计算资源限制但没有指定资源请求，那么 Kubernetes 会自动将请求配置为等于限制。
请求和限制的重要性请求是 Pod 调度的关键组成部分，是由 Kube-scheduler 执行的任务。
调度是在 Kubelet 运行 Pod 之前将它们匹配到正确节点的过程。这个过程考虑了 pod 的资源需求和可用节点上的可用资源。在我们的示例中（通常情况下），pod 的资源包括容器所需的资源和 pod 本身所需的资源。
在集群中，具有容纳新 pod 的资源容量的节点称为可行节点。调度程序负责评估这些节点并为 pod 选择最佳节点。评估过程要求调度程序考虑几个因素，包括：
资源需求亲和和反亲和规范工作负载间硬件和软件限制然后将 pod 放置在选定的节点上。然后，Kubelet 通过将容器的内存和 CPU 限制以及请求传递给容器运行时来启动 pod 内的容器。
如果容器内的某个进程超出了请求的内存并且其节点内存不足，则托管该进程的 pod 可能会被驱逐。
但是，重要的是要注意在驱逐 pod 时要遵循一个顺序。这一切都取决于吊舱的服务质量。
Pod 的服务质量创建 Pod 时，它会根据其资源规范接收分配的服务质量 (QoS) 类。QoS 分为三类：
BestEffort：这个类被分配给一个 Pod，它的容器没有指定的内存和 CPU 请求和限制。Burstable：如果其中一个容器具有指定的内存或 CPU 请求和限制，则 pod 接收此分配的类。Guaranteed：如果 Pod 满足以下条件，则为该 Pod 分配此类：pod 中的所有容器都有内存和 CPU 请求和限制。所有容器的内存请求都等于限制。所有容器的 CPU 请求都等于限制。QoS 在确定 Kubelet 可以在计算资源耗尽时从节点中驱逐哪些 pod 方面非常重要。当一个节点想要回收一些资源以确保剩余 pod 的继续运行时，就会发生驱逐。
Kubelet 将在 Burstable pod 之前驱逐 BestEffort pod。然后它将在保证 pod 之前驱逐 Burstable pod。
不设定限制和要求的后果如果我们未能设置资源限制和请求，Kubernetes 会自动为我们设置它们。这听起来可能很方便，但 Kubernetes 旨在确保应用程序不会失败。结果，它将分配不合理的慷慨限制。
例如，如果我们没有为只需要 250m CPU 资源的集群指定请求或限制，Kubernetes 可能会将 CPU 请求设置为 900m。这将使我们集群的资源需求膨胀，使其运行成本过高。
此外，如果 Kubernetes 不必要地预留了大量资源，我们可能会遇到频繁的 OOM 错误。
此外，当被驱逐的 pod 堆积时，我们的集群变得不整洁。即使被驱逐的 pod 不再消耗节点的资源，它们也需要 Kubernetes 环境中的额外资源。
CPU 节流是未能设置或不正确设置 CPU 限制的另一个后果。当我们指定 CPU 限制时，Kubernetes 会附加一个允许该 CPU 容量的时间范围。如果容器在循环结束之前超过了限制，它必须暂停并等待下一个循环开始才能继续执行。这会导致响应时间显着增加。
准确性对于确定请求和限制至关重要。将限制设置得太高会导致资源浪费，而将其设置得太低会大大增加 CPU 限制的可能性。
从配置良好的请求和限制中获益如果正确执行，设置计算资源请求和限制会以低成本实现平稳、快速的性能。但要做到正确可能会很棘手。
因此，在提供建议时采用可以考虑应用程序性能的资源优化解决方案是非常有益的。StormForge 就是这样一种解决方案。
StormForge使用机器学习来自动确定最佳配置。从它推荐的选项中，我们可以选择优化我们集群的性能或成本的 CPU 限制，确保我们可以使我们的 Kubernetes 环境与我们的业务目标保持一致。根据我们的选择，StormForge 采用以下方式之一：
如果性能优先于成本，则建议使用更高的 CPU 限制以防止限制。如果成本优先于性能，它会确定较低的 CPU 限制，从而在必要时进行节流。结论Kubernetes 集群消耗的资源越多，运行成本就越高。如果我们分配最少的资源来节省成本，我们将面临性能不佳和频繁且代价高昂的 OOM 错误。
通过正确指定我们的计算资源请求和限制，我们可以最大限度地减少超支、优化性能并确保最有效地使用我们的 Kubernetes 资源。然而，试图确定最佳平衡可能是艰巨的。
请继续关注本系列的后续文章，我们将在其中解释如何设置优化目标以及如何解决一些最困难的优化挑战。
爱资源吧版权声明：以上文中内容来自网络，如有侵权请联系删除，谢谢。