WEBKT

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

55 0 0 0

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

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

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

4. 总结:没有银弹,只有最合适的方案

作为一名平台工程师,日常工作中避免不了与 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 工程师!

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

K8s探索者 Kubernetes 资源管理Resource QuotasLimit Ranges

评论点评

打赏赞助
sponsor

感谢您的支持让我们更好的前行

分享

QRcode

https://www.webkt.com/article/9786