天助网站洛阳app制作公司

k8s资源管理

在 Kubernetes 集群的资源管理中，ResourceQuota、LimitRange 和 QoS 服务质量是三个核心概念。它们从不同层面和角度对资源进行管控，既相互独立又协同工作，共同确保集群资源的合理分配与高效利用，是保障集群稳定运行的重要机制。

ResourceQuota（资源配额）

概念

ResourceQuota 是 Kubernetes 提供的一种命名空间级别的资源总量管控机制，用于为特定命名空间（Namespace）设置资源使用的硬性约束。它不仅能限制命名空间内所有 Pod 对 CPU、内存等计算资源的总使用量，还能对 Pod、Service、ConfigMap、Secret 等 Kubernetes 对象的数量进行限制，防止资源滥用和过度分配。

层级关系与作用范围

• 层级：作用于命名空间层级，是对整个命名空间的资源总量进行全局性约束，属于宏观层面的资源控制。

• 作用范围：仅在设置了 ResourceQuota 的命名空间内有效，对其他命名空间无任何影响。其核心作用是在多团队、多项目共享集群资源的场景下，防止某个命名空间过度占用集群资源，保证不同命名空间之间资源分配的公平性，避免因个别命名空间资源耗尽而影响整个集群的稳定性。

配置方法

1. 创建 YAML 文件（如 resource-quota.yaml）：

apiVersion: v1
kind: ResourceQuota
metadata:name: example-quotanamespace: my-namespace  # 指定作用的命名空间
spec:hard:  # 硬性限制条件pods: "10"  # 限制该命名空间内Pod总数不超过10个replicationcontrollers: "5"  # 限制复制控制器数量requests.cpu: "10"  # 所有Pod的CPU请求总量不超过10核requests.memory: 10Gi  # 所有Pod的内存请求总量不超过10Gilimits.cpu: "20"  # 所有Pod的CPU限制总量不超过20核limits.memory: 20Gi  # 所有Pod的内存限制总量不超过20Giconfigmaps: "10"  # 限制ConfigMap数量

1. 执行命令创建：kubectl apply -f resource-quota.yaml

2. 验证配置：kubectl get resourcequota -n my-namespace，可查看配额的使用情况和限制值。

LimitRange（限制范围）

概念

LimitRange 是命名空间内针对单个 Pod 或容器的资源精细化管控机制，用于为其设置资源请求（Request）和限制（Limit）的默认值、最小值和最大值。当用户创建 Pod 或容器未指定资源配置时，它会自动填充默认值；若用户指定了资源配置，则会校验其是否在规定的最小和最大范围内，若超出范围则创建会失败。

层级关系与作用范围

• 层级：作用于命名空间层级，但聚焦于命名空间内单个 Pod 或容器的资源约束，属于微观层面的资源控制。

• 作用范围：仅在设置了 LimitRange 的命名空间内有效。其主要作用是规范单个 Pod 或容器的资源使用边界，避免单个 workload 过度占用资源而影响同命名空间内其他 workload；同时为资源配置不规范的 Pod 提供合理默认值，减少人为配置失误。

配置方法

1. 创建 YAML 文件（如 limit-range.yaml）：

apiVersion: v1
kind: LimitRange
metadata:name: example-limit-rangenamespace: my-namespace
spec:limits:- type: Container  # 针对容器的限制default:  # 容器未指定limit时的默认值cpu: "1"memory: 1GidefaultRequest:  # 容器未指定request时的默认值cpu: "500m"  # 500毫核memory: 512Mimax:  # 容器资源的最大值cpu: "2"memory: 2Gimin:  # 容器资源的最小值cpu: "200m"memory: 256Mi- type: Pod  # 针对Pod的限制（所有容器资源总和）max:cpu: "4"memory: 4Gi

1. 执行命令创建：kubectl apply -f limit-range.yaml

2. 验证配置：kubectl get limitrange -n my-namespace，可查看限制范围的具体规则。

QoS（服务质量）

概念

QoS（Quality of Service）服务质量是 Kubernetes 根据 Pod 的资源请求（Request）和限制（Limit）自动划分的优先级类别，用于在集群资源（CPU、内存）紧张时决定 Pod 的驱逐顺序。它通过资源配置定义 Pod 的重要程度，确保核心业务在资源竞争时优先存活。Kubernetes 定义了三种 QoS 级别：

• Guaranteed（保证型）：Pod 中所有容器的 CPU 和内存的 Request 与 Limit 均相等（且不为空）。这类 Pod 资源需求明确且有保障，在资源紧张时最后被驱逐，适用于核心业务。

• Burstable（突发型）：Pod 中至少有一个容器设置了 Request，但 Request 不等于 Limit（或部分容器未设置）。其资源需求有一定弹性，优先级低于 Guaranteed，在资源紧张时可能被驱逐，但优先于 BestEffort，适用于非核心但需要一定资源保障的业务。

• BestEffort（尽力而为型）：Pod 中所有容器均未设置 Request 和 Limit。这类 Pod 对资源没有保障，在资源紧张时最先被驱逐，适用于低优先级的测试或临时任务。

层级关系与作用范围

• 层级：作用于Pod 层级，是对单个 Pod 基于资源配置的优先级划分。

• 作用范围：覆盖集群中所有 Pod，直接影响 Pod 在资源竞争场景下的存活概率。它是 Kubernetes 调度和驱逐机制的重要依据，确保资源优先分配给更重要的业务。

配置方法与验证

QoS 级别由 Pod 中容器的资源 Request 和 Limit 自动决定，无需直接配置，只需正确设置资源参数：

• Guaranteed 配置示例：

apiVersion: v1
kind: Pod
metadata:name: guaranteed-pod
spec:containers:- name: example-containerimage: nginxresources:requests:  # request与limit相等cpu: "1"memory: 1Gilimits:cpu: "1"memory: 1Gi

• Burstable 配置示例：

apiVersion: v1
kind: Pod
metadata:name: burstable-pod
spec:containers:- name: example-containerimage: nginxresources:requests:  # request小于limitcpu: "500m"memory: 512Milimits:cpu: "1"memory: 1Gi

• BestEffort 配置示例：

apiVersion: v1
kind: Pod
metadata:name: best-effort-pod
spec:containers:- name: example-containerimage: nginx  # 未设置任何request和limit

• 验证 QoS 级别：执行 kubectl describe pod ，在输出的 “QoS Class” 字段可查看该 Pod 的 QoS 级别。

三者的层级关系与协同作用

• 层级递进：ResourceQuota（命名空间总量）→ LimitRange（命名空间内单个 Pod / 容器）→ QoS（单个 Pod 优先级），形成从宏观到微观、从总量到个体的资源管控链条。

• 协同逻辑：

1. ResourceQuota 划定命名空间的资源 “总池子”，确保集群资源在不同命名空间间的公平分配；

2. LimitRange 细化 “总池子” 内单个 Pod / 容器的资源边界，避免个体过度占用；

3. QoS 基于前两者的资源配置，定义 Pod 优先级，在资源不足时保障核心业务存活。

通过三者的配合，Kubernetes 实现了资源从分配、约束到调度的全流程管理，既保证资源利用效率，又确保集群稳定性和业务可用性。