6 张配图通俗易懂说透 K8S 请求和限制

关注公众号并添加到“星标⭐”，防止错过消息

后台回复【资料包】获取学习资料

在 Kubernetes 中使用容器时，了解涉及的资源是什么以及为何需要它们很重要。有些进程比其他进程需要更多的 CPU 或内存。这很关键，永远不应该让进程挨饿。知道了这一点，我们应该正确配置容器和 Pod，以便充分利用两者。

Kubernetes 限制和请求简介

使用 Kubernetes 时，限制和请求是重要的设置。本文将重点关注两个最重要的：CPU 和内存。

Kubernetes 将限制定义为 容器可以使用的最大资源量。这意味着容器永远不会消耗超过指示的内存量或 CPU 量。

另一方面，请求是为容器保留的最低保证资源量。

示例

让我们来看看这个部署，我们在 CPU 和内存上为两个不同的容器设置限制和请求。

kind: Deployment
apiVersion: extensions/v1beta1
# …
template:
  spec:
    containers:
      - name: redis
        image: redis:5.0.3-alpine
        resources:
          limits:
            memory: 600Mi
            cpu: 1
         requests:
            memory: 300Mi
            cpu: 500m
      - name: busybox
        image: busybox:1.28
        resources:
          limits:
            memory: 200Mi
            cpu: 300m
          requests:
            memory: 100Mi
            cpu: 100m

假设我们正在运行一个集群，例如，具有 4 核和 16GB RAM 节点。我们可以提取出很多信息：

Kubernetes Limits and Requests

1. Pod 有效请求 是 400 MiB 内存和 600 毫核 CPU。您需要一个具有足够可用可分配空间的节点来调度 Pod。
2. redis 容器的 CPU 份额 为 512，busybox 容器的 CPU 份额为 102。Kubernetes 总是为每个核心分配 1024 个份额，因此 redis：1024 * 0.5 个核心 ≅ 512 和 busybox：1024 * 0.1 个核心 ≅ 102
3. 如果 Redis 容器尝试分配超过 600MB 的 RAM，则它会被OOM 终止，很可能导致 pod 失败。
4. 如果 Redis 每 100 毫秒尝试使用超过 100 毫秒的 CPU，（因为我们有 4 个核，可用时间为每 100 毫秒 400 毫秒），Redis 将受到CPU 限制，从而导致性能下降。
5. 如果 Busybox 容器试图分配超过 200MB 的 RAM，它将被OOM 终止，从而导致 pod 失败。
6. 如果 Busybox 尝试每 100 毫秒使用超过 30 毫秒的 CPU，它将遭受CPU 限制，从而导致性能下降。

Kubernetes 请求

Kubernetes 将请求定义为容器使用的保证最小资源量。

基本上，它将设置容器消耗的最小资源量。

当一个 Pod 被调度时，kube-scheduler 将检查 Kubernetes 请求，以便将它分配给一个特定的节点，该节点至少可以满足 Pod 中所有容器的数量。如果请求的数量高于可用资源，则 Pod 将不会被调度并保持在 Pending 状态。

有关挂起(pending)状态的更多信息，请查看了解 Kubernetes Pod 挂起问题：

在此示例中，在容器定义中我们设置了 100m CPU 核和 4Mi 内存的请求：

resources:
   requests:
        cpu: 0.1
        memory: 4Mi

使用请求：

• 将 Pod 分配给 Node 时，满足 Pod 中容器指示的请求。
• 在运行时，指示的请求量将保证为该 Pod 中的容器的最小请求量。

Kubernetes 限制

Kubernetes 将限制定义为容器可以使用的最大资源量。

这意味着容器永远不会消耗超过指示的内存量或 CPU 量。

  resources:
      limits:
        cpu: 0.5
        memory: 100Mi

使用限制：

• 在运行时，Kubernetes 将检查 Pod 中的容器是否消耗了比限制中指示的更多的资源。

CPU 特性

Kubernetes requests for CPU

内存特性

内存是一种不可压缩的资源，这意味着它不能像 CPU 那样被拉伸。如果一个进程没有足够的内存来工作，这个进程就会被杀死。

内存在 Kubernetes 中以字节为单位。

• 您可以使用 E、P、T、G、M、k 来表示 Exabyte、Petabyte、Terabyte、Gigabyte、Megabyte 和 kilobyte，尽管通常只使用后四种。（例如，500M、4G）
• 警告：不要使用小写的 m 表示内存（这代表 Millibytes，低得离谱）
• 您可以使用 Mi 定义 Mebibytes，其余定义为 Ei、Pi、Ti（例如 500Mi）

最佳实践

在极少数情况下，您应该使用限制来控制 Kubernetes 中的资源使用。这是因为如果你想避免饥饿（确保每个重要进程都得到它的份额），你应该首先使用请求。

通过设置限制，你只是防止进程在异常情况下获取额外的资源，在内存的情况下导致 OOM kill，在 CPU 的情况下 Throttling（进程将需要等待直到 CPU 可以再次使用）。

有关详细信息，请查看有关 OOM 和节流的文章：

如果您将 Pod 的所有容器中的请求值设置为等于限制，则该 Pod 将获得有保证的服务质量。

另请注意，资源使用率高于请求的 Pod 更有可能被驱逐，因此设置非常低的请求弊大于利。有关更多信息，请查看有关 Pod 驱逐和服务质量的文章：

命名空间资源配额

多亏了命名空间，我们可以将 Kubernetes 资源隔离到不同的组中，也称为租户。

使用ResourceQuotas，您可以为整个命名空间设置内存或 CPU 限制，确保其中的实体不能从该数量中消耗更多。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: 2
    requests.memory: 1Gi
    limits.cpu: 3
    limits.memory: 2Gi

• requests.cpu：此命名空间中所有请求总和的最大 CPU 量

然后，将其应用于您的命名空间：

kubectl apply -f resourcequota.yaml --namespace=mynamespace

您可以列出命名空间的当前 ResourceQuota：

kubectl get resourcequota -n mynamespace

请注意，如果您为命名空间中的给定资源设置 ResourceQuota，则需要相应地为该命名空间中的每个 Pod 指定限制或请求。否则，Kubernetes 将返回“failed quota”错误：

Error from server (Forbidden): error when creating "mypod.yaml": pods "mypod" is forbidden: failed quota: mem-cpu-demo: must specify limits.cpu,limits.memory,requests.cpu,requests.memory

如果您尝试添加容器限制或请求超过当前 ResourceQuota 的新 Pod，Kubernetes 将返回“超出配额”错误：

Error from server (Forbidden): error when creating "mypod.yaml": pods "mypod" is forbidden: exceeded quota: mem-cpu-demo, requested: limits.memory=2Gi,requests.memory=2Gi, used: limits.memory=1Gi,requests.memory=1Gi, limited: limits.memory=2Gi,requests.memory=1Gi

命名空间限制范围

如果我们想限制可分配给命名空间的资源总量，ResourceQuotas 很有用。但是如果我们想给里面的元素赋默认值会怎样呢？

LimitRanges是一种 Kubernetes 策略，用于限制命名空间中每个实体的资源设置。

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default:
      cpu: 500m
    defaultRequest:
      cpu: 500m
    min:
      cpu: 100m
    max:
      cpu: "1"
    type: Container

• default: 如果未指定，创建的容器将具有此值。
• min：创建的容器不能有小于此的限制或请求。
• max: 创建的容器不能有比这更大的限制或请求。

稍后，如果您创建一个没有设置请求或限制的新 Pod，LimitRange 会自动将这些值设置到它的所有容器：

   Limits:
      cpu:  500m
    Requests:
      cpu:  100m

现在，假设您添加了一个限制为 1200M 的新 Pod。您将收到以下错误：

Error from server (Forbidden): error when creating "pods/mypod.yaml": pods "mypod" is forbidden: maximum cpu usage per Container is 1, but limit is 1200m

请注意，默认情况下，即使未设置 LimitRanges，Pod 中的所有容器也实际上请求 100m CPU。

结论

为 Kubernetes 集群选择最佳限制是获得最佳能耗和成本的关键。

为 Pod 规模过大或投入过多资源可能会导致成本飙升。

过小的规模或者只占用很少的 CPU 或内存将导致应用程序不能正确执行，甚至会驱逐 Pods。

如前所述，可以不使用 Kubernetes 限制，除非在非常特殊的情况下，因为它们可能弊大于利。在内存不足的情况下，容器有可能被杀死，或者在 CPU 不足的情况下，容器可能会被限制。

对于请求，当您需要确保进程获得有保证的资源共享时请使用它。

作者：JAVIER MARTÍNEZ

原文：https://goo.gs/it0jx
译者：#公众号：进击云原生

---

后台回复“加群”，带你进入高手交流群

推荐阅读
K8S 节点 CPU 升级，导致 kubelet 无法启动排障
提高 K8S 监控可观察性最佳方式实战教程
10 万字技术电子书免费下载，涉及云原生、大数据、数据库
Kubernetes 1.26 中的删除、弃用和主要更改
25 张图详解 K8S 管理平台 Rancher 部署实践
稳定性和可扩展性更强 K8S 高可用实战操作
K8S master 节点更换 IP 与高可用故障模拟实战
46 张图详解 Zabbix 分布式监控平台建设
这 11 张图把 K8S 权限认证说的很清楚了
10 张图解 K8S CNI Calico 网络模型原理与功能实战
网关 Apache APISIX 3.0 版本发布！功能丰富
19 张图详解 Rsync 远程同步
企业级网关 Kong 部署 Spring Boot 项目实战K8S 1.25 中的重大更改和删除18 张图 Java 容器化最佳实践总结
17 张图解 Redis On K8S 编排部署与实战操作用 Grafana Mimir 可视化云原生监控报警Docker 镜像构建保姆级入门实战指南17 张图实战 + 理清 K8S 网络排错思路，硬核！16 张图硬核讲解 Kubernetes 网络模型