资源配额 vs. 限制范围? K8s 资源管理的正确打开方式

作为一名平台工程师，日常工作中避免不了与 Kubernetes 打交道。资源管理是 K8s 中至关重要的一环，用以保障集群稳定性和资源利用率。你是否也经常在 Resource Quotas（资源配额）和 Limit Ranges（限制范围）之间犹豫，不知道该如何选择？今天，我就来和你聊聊这两者的区别，并通过实际案例，帮你理清思路，找到最适合你的资源管理方案。

1. 资源配额 (Resource Quotas): 总量控制，防止“资源黑洞”

想象一下，你的团队有多个项目共享一个 Kubernetes 集群。如果没有资源配额，某个项目可能会无限制地占用资源，导致其他项目无法正常运行。资源配额就像一个“总闸门”，它定义了单个 Namespace 中可以使用的资源总量，例如 CPU、内存、存储等。简单来说，它限制的是“能用多少”。

1.1 资源配额能管什么？

• 计算资源：
  • requests.cpu：Pod 申请的 CPU 总量。
  • requests.memory：Pod 申请的内存总量。
  • limits.cpu：Pod 允许使用的 CPU 最大值。
  • limits.memory：Pod 允许使用的内存最大值。
• 存储资源：
  • requests.storage：PVC 申请的存储总量。
  • persistentvolumeclaims：PVC 的数量。
• 对象数量：
  • pods：Pod 的数量。
  • services：Service 的数量。
  • replicationcontrollers：ReplicationController 的数量。
  • deployments.apps：Deployment 的数量。
  • configmaps：ConfigMap 的数量。
  • secrets：Secret 的数量。

1.2 资源配额怎么用？

下面是一个资源配额的 YAML 示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: my-namespace
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi
    pods: "10"

这个例子定义了一个名为 compute-resources 的资源配额，它限制了 my-namespace 这个 Namespace 中所有 Pod 的 CPU request 总量不能超过 2 核，CPU limit 总量不能超过 4 核，内存 request 总量不能超过 4Gi，内存 limit 总量不能超过 8Gi，并且 Pod 的总数不能超过 10 个。

1.3 资源配额的注意事项

• Default Request/Limit： 当你开启了资源配额，强烈建议同时配置 Default Request 和 Limit。否则，用户创建 Pod 时如果没有显式设置 Request 和 Limit，Kubernetes 会拒绝创建该 Pod。
• 配额更新： 可以更新资源配额，但只能增加，不能减少。减少配额可能会导致现有 Pod 无法运行。
• 优先级： 资源配额是 Namespace 级别的，对该 Namespace 下的所有资源对象生效。

2. 限制范围 (Limit Ranges): “保底”机制，避免“饿死”现象

资源配额控制的是资源总量，而限制范围则更关注单个资源对象的资源限制。它可以为 Namespace 中的 Pod、Container 等资源对象设置默认的 Request 和 Limit，以及允许使用的 Request 和 Limit 的最大值和最小值。简单来说，它限制的是“单个能用多少”。

2.1 限制范围能管什么？

• Default Request/Limit： 为 Container 设置默认的 CPU 和内存 Request 和 Limit。
• Default Request/Limit 比例： 强制 Container 的 Limit 和 Request 之间的比例。
• Request/Limit 的最小值和最大值： 限制 Container 可以设置的 CPU 和内存 Request 和 Limit 的范围。

2.2 限制范围怎么用？

下面是一个限制范围的 YAML 示例：

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit-range
  namespace: my-namespace
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    max:
      cpu: "1"
      memory: 1Gi
    min:
      cpu: 100m
      memory: 100Mi
    type: Container

这个例子定义了一个名为 cpu-limit-range 的限制范围，它为 my-namespace 这个 Namespace 中的所有 Container 设置了默认的 CPU Request 为 200m，默认的 CPU Limit 为 500m，默认的内存 Request 为 256Mi，默认的内存 Limit 为 512Mi。同时，它还限制了 Container 的 CPU Request 最小值不能低于 100m，最大值不能超过 1 核，内存 Request 最小值不能低于 100Mi，最大值不能超过 1Gi。

2.3 限制范围的注意事项

• 优先级： 限制范围也是 Namespace 级别的，对该 Namespace 下的所有资源对象生效。
• 更新限制： 同样可以更新限制范围，但更新可能会影响到现有的 Pod，需要谨慎操作。
• 与资源配额配合使用： 限制范围通常与资源配额配合使用，以实现更精细化的资源管理。

3. 案例分析：选择合适的资源管理方案

为了更好地理解资源配额和限制范围的应用场景，我们来看几个实际的案例。

3.1 案例一：多租户环境下的资源隔离

假设你负责一个多租户的 Kubernetes 集群，不同的团队分别使用不同的 Namespace。为了防止某个团队占用过多资源，影响其他团队的业务，你可以使用资源配额来限制每个 Namespace 可以使用的资源总量。

例如，你可以为每个 Namespace 设置 CPU、内存、存储等资源的配额，确保每个团队都在自己的“资源池”中运行。

方案： 使用资源配额，为每个 Namespace 设置资源上限。

3.2 案例二：保障关键应用的资源需求

假设你的集群中运行着一些关键应用，这些应用对性能要求较高，需要保证足够的资源才能正常运行。为了避免这些应用因为资源不足而出现问题，你可以使用限制范围来为这些应用设置默认的 Request 和 Limit，确保它们始终能够获得足够的资源。

例如，你可以为关键应用的 Container 设置较高的 CPU 和内存 Request，确保它们在资源紧张的情况下也能优先获得资源。

方案： 使用限制范围，为关键应用设置较高的默认 Request 值。

3.3 案例三：防止资源浪费

有些开发者在创建 Pod 时，可能会忘记设置 Request 和 Limit，或者设置的值过大，导致资源浪费。为了避免这种情况，你可以使用限制范围来为所有 Container 设置默认的 Request 和 Limit，以及允许使用的 Request 和 Limit 的最大值和最小值。

例如，你可以设置一个较低的默认 CPU 和内存 Request，防止开发者过度申请资源。同时，你还可以设置一个最大 CPU 和内存 Limit，防止开发者申请过多的资源，导致资源浪费。

方案： 使用限制范围，设置合理的默认 Request 和 Limit，以及最大最小值。

4. 总结：没有银弹，只有最合适的方案

资源配额和限制范围都是 Kubernetes 中重要的资源管理工具，它们各有优缺点，适用于不同的场景。选择哪种方案，取决于你的实际需求和集群的特点。

• 资源配额： 适用于需要控制资源总量的场景，例如多租户环境下的资源隔离。
• 限制范围： 适用于需要保障关键应用的资源需求，或者防止资源浪费的场景。

在实际工作中，你通常需要将两者结合起来使用，才能实现更精细化的资源管理。例如，你可以先使用资源配额限制每个 Namespace 的资源总量，然后再使用限制范围为每个 Container 设置默认的 Request 和 Limit，以及允许使用的 Request 和 Limit 的最大值和最小值。

希望这篇文章能够帮助你更好地理解 Kubernetes 中的资源配额和限制范围，并在实际工作中选择最合适的资源管理方案。记住，没有银弹，只有最合适的方案！

作为一名 K8s 玩家，我一直秉持着“实践出真知”的理念。只有不断地尝试、踩坑、总结，才能真正掌握这些工具的精髓。希望你也能在实践中不断学习，成为一名优秀的 Kubernetes 工程师！

最后，如果你在资源管理方面还有其他疑问，欢迎在评论区留言，我们一起探讨！