Kubernetes 资源管理与调度策略

CarlowZJ

于 2025-05-16 00:01:51 发布

阅读量663

点赞数 14

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/csdn122345/article/details/147994728

版权

1. 节点亲和性（Node Affinity）

2. Pod 亲和性（Pod Affinity）

3. Pod 反亲和性（Pod Anti-Affinity）

摘要：资源管理是 Kubernetes（K8s）的核心功能之一，本文详解资源请求与限制、调度策略，以及如何优化资源分配，保障集群稳定运行与应用性能。通过实际配置示例和应用场景分析，帮助读者掌握 K8s 资源管理与调度的关键技术，提升集群资源利用率和应用服务质量。

一、Kubernetes 资源管理基础

（一）资源类型与单位

在 K8s 中，主要的资源类型包括 CPU 和内存。CPU 资源以 CPU 核心数为单位进行计量，内存资源则以字节（Byte）为单位。在实际配置中，通常使用一些简化单位，如 CPU 使用 “m” 表示千分之一核（1000m = 1 核），内存常用 “Gi”（ Gibibyte，等于 230 字节）等单位。

（二）资源管理对象

资源管理主要针对容器进行配置，Pod 作为最小部署单元，其资源限制由内部容器的资源限制共同决定。在定义容器时，可以通过资源请求（requests）和资源限制（limits）两个参数来指定容器所需的资源。

（三）资源管理的重要性

合理的资源管理能够避免因资源不足导致容器无法正常运行，或因资源过度使用影响其他容器的问题。它有助于保障应用的稳定性和集群资源的高效利用。

二、资源请求与限制详解

（一）资源请求的作用与配置

资源请求是指容器启动时所需的最小资源量，调度器（Scheduler）会根据这一参数为容器分配合适的节点。如果资源请求设置过低，可能导致容器被调度到资源不足的节点上，影响性能；设置过高则可能导致资源浪费或调度失败。

在 Pod 的 YAML 配置文件中，资源请求的配置示例如下：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"

上述配置中，容器请求 64MiB 的内存和 250m 的 CPU（即 0.25 核）。

（二）资源限制的作用与配置

资源限制是指容器可使用的最大资源量，防止容器过度消耗资源影响其他容器。当容器试图使用的资源超过限制值时，Kubelet 会采取措施限制其资源使用，如限制 CPU 使用率或终止容器（对于内存超额情况）。

资源限制同样在 Pod 的 YAML 配置文件中设置，示例如下：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"

此配置中，容器的内存使用上限为 128MiB，CPU 使用上限为 500m（0.5 核）。

（三）资源请求与限制的合理配置策略

基于历史数据和性能测试：通过分析应用的历史资源使用数据和性能测试结果，确定合理的资源请求和限制值。例如，对于一个已知在运行过程中平均 CPU 使用率为 300m、峰值为 600m 的应用，可以将 CPU 请求设置为 300m，限制设置为 600m；内存平均使用为 128MiB，峰值为 256MiB，则相应设置内存请求和限制。
考虑业务的重要性和优先级：对于关键业务应用，适当提高资源请求和限制，保障其在资源竞争中的优先级；对于次要应用，可适当降低设置，但要确保其在正常负载下能够稳定运行。
为资源预留一定的缓冲空间：避免将资源限制设置得过于接近请求值，留出一定的缓冲空间以应对突发负载。例如，将 CPU 限制设置为请求值的 1.5 至 2 倍，内存限制设置为请求值的 1.2 至 1.5 倍，具体倍数根据应用特点和集群资源状况调整。

三、调度策略详解

（一）默认调度器的工作原理

K8s 的默认调度器基于一系列预定义的规则和算法进行资源调度。其主要工作步骤如下：

预选（Predicates）：
- 过滤掉明显不符合条件的节点。预选规则包括节点的资源是否充足、节点是否处于健康状态、Pod 的节点选择器（NodeSelector）与节点的标签是否匹配等。
评估（Priorities）：
- 对通过预选的节点进行打分，综合考虑资源需求匹配程度、亲和性与反亲和性规则的匹配度、节点负载水平以及数据本地性等因素。每个评估函数会给节点分配一个分数，最后将所有评估函数的分数加权求和，得到节点的综合评分。
选择目标节点：
- 根据节点的综合评分排序，选择评分最高的节点作为 Pod 的目标节点。

（二）亲和性与反亲和性规则

亲和性规则用于将具有相似特征或关联性的 Pod 调度到同一个节点或特定的节点组上，反亲和性规则则旨在避免将某些 Pod 调度到同一节点上。

1. 节点亲和性（Node Affinity）

节点亲和性允许用户根据节点的标签选择将 Pod 调度到特定的节点上。配置示例如下：

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
  containers:
  - name: with-node-affinity
    image: nginx

此配置表示 Pod 只会调度到标签键为 “disktype”、值为 “ssd” 的节点上。

2. Pod 亲和性（Pod Affinity）

Pod 亲和性将 Pod 调度到与某些已有 Pod 相邻的节点上。例如，将多个关联的微服务 Pod 调度到靠近彼此的节点，以减少通信延迟。

3. Pod 反亲和性（Pod Anti-Affinity）

Pod 反亲和性用于避免将多个副本的 Pod 调度到同一个节点上，提高应用的高可用性。例如，对于有多个副本的 Web 服务 Pod，通过反亲和性规则将其分散调度到不同的节点上，防止因单节点故障导致多个副本同时失效。

（三）自定义调度器的开发与应用

在一些特殊场景下，如需要根据应用特定指标（如数据局部性、业务优先级等）进行调度时，可以开发自定义调度器。自定义调度器与 K8s 集群集成后，可以与默认调度器同时运行，根据 Pod 的调度策略选择不同的调度器。

开发自定义调度器的步骤包括：

实现调度器接口：根据 K8s 的调度器接口规范，开发调度器的核心逻辑，包括预选、评估、选择节点等方法。
集成到 K8s 集群：将自定义调度器部署到 K8s 集群中，并配置相关权限和认证信息，使其能够与 API Server 等组件进行通信。

为 Pod 指定调度器：在 Pod 的 YAML 配置文件中，通过 schedulerName 参数指定使用自定义调度器。例如

apiVersion: v1
kind: Pod
metadata:
  name: custom-scheduled-pod
spec:
  schedulerName: custom-scheduler
  containers:
  - name: custom-scheduled-pod
    image: nginx

四、资源优化分配策略与实践

（一）基于应用负载的动态资源调整

监控应用负载：利用监控工具（如 Prometheus + Grafana）实时收集应用的资源使用情况、请求数量、响应时间等指标，分析应用负载的变化趋势。
自动扩缩容：根据监控数据，结合 K8s 的 Horizontal Pod Autoscaler（HPA）实现自动扩缩容。HPA 会根据指定的指标（如 CPU 使用率、自定义指标等）自动调整 Deployment 的副本数量。例如，当应用的 CPU 使用率持续高于 80% 时，HPA 自动增加副本数量；当使用率低于 30% 时，减少副本数量。
资源请求与限制的动态调整：在某些情况下，除了调整副本数量，还可以根据负载变化动态调整 Pod 的资源请求和限制。这需要结合自定义控制器或脚本，根据监控数据修改 Pod 的资源配置，并触发重新部署。

（二）资源配额管理

在多租户环境下，通过资源配额（Resource Quota）对不同命名空间的资源使用进行限制，避免某个租户过度使用资源。例如，为开发部门的命名空间设置 CPU 总量限制为 10 核，内存总量限制为 20Gi；为测试部门的命名空间设置相应限制。

资源配额的配置示例如下：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: dev-namespace
spec:
  hard:
    limits.cpu: "10"
    limits.memory: 20Gi
    requests.cpu: "5"
    requests.memory: 10Gi

此配置对 dev-namespace 命名空间设置了 CPU 和内存的资源配额。

（三）节点资源的合理分配与规划

节点选型与资源配置：根据应用的特点和需求，选择合适的节点类型（如计算优化型、内存优化型、存储优化型等）。对于大数据处理应用，选择内存充足、CPU 核心数多的节点；对于高并发的 Web 应用，选择网络带宽高、CPU 性能好的节点。
节点资源预留：为节点系统进程和 Kubernetes 系统组件预留一定的资源，确保节点本身的稳定运行。通常建议为节点预留 10% 至 20% 的 CPU 和内存资源。
资源分配的均衡性：在规划集群资源时，考虑将不同资源需求的应用合理分布到各个节点上，避免某些节点资源过度紧张而其他节点资源闲置。可以利用 K8s 的亲和性与反亲和性规则，以及资源配额等机制，实现资源分配的均衡性。

五、应用场景与案例分析

（一）在线电商平台的资源管理与调度

场景描述：一个大型在线电商平台，包含前端展示服务、后端业务逻辑处理服务、数据库服务、缓存服务等多个组件。在促销活动期间，流量会出现爆发式增长，对资源的需求也会急剧增加。
资源管理与调度策略：
- 资源请求与限制设置：为前端展示服务和后端业务逻辑处理服务的容器设置合理的资源请求和限制，确保在正常负载下能够稳定运行，并预留一定的缓冲空间应对流量高峰。例如，前端服务容器的 CPU 请求设置为 300m，限制为 600m；内存请求设置为 256MiB，限制为 512MiB。
- 自动扩缩容：利用 HPA 根据 CPU 使用率和自定义的请求数量指标进行自动扩缩容。在促销活动前，设置 HPA 的最小副本数为 5，最大副本数为 20，当 CPU 使用率超过 60% 或请求数量每秒超过 1000 时，触发扩容操作；当使用率和请求数量低于设定阈值时，触发缩容操作。
- 节点资源规划：为电商平台的业务应用划分专门的节点池，与集群中的其他应用隔离。根据历史数据预测促销活动期间的资源需求，提前扩容节点池，并合理分配不同类型服务的容器到合适的节点上。例如，将数据库服务部署到配置了高性能存储设备的节点上，将缓存服务部署到内存充足的节点上。

（二）大数据分析集群的资源管理与调度

场景描述：大数据分析集群用于运行各种数据处理任务，如数据清洗、转换、机器学习模型训练等。这些任务对 CPU 和内存资源的需求差异较大，且任务的执行时间和资源占用具有不确定性。
资源管理与调度策略：
- 资源隔离与优先级设置：为不同类型的数据分析任务创建不同的命名空间，并设置资源配额和优先级。对于紧急且重要的数据分析任务（如实时数据监控任务），分配较高的优先级和相对宽松的资源配额；对于离线批处理任务（如夜间数据汇总任务），分配较低的优先级和严格的资源配额。
- 自定义调度器开发：开发自定义调度器，根据任务的数据本地性需求和资源需求进行调度。例如，对于需要处理存储在特定分布式文件系统节点上的数据的任务，自定义调度器会优先将任务调度到靠近数据存储节点的计算节点上，减少数据传输开销，提高任务执行效率。
- 资源回收与再利用：对于长时间运行且资源占用较高的任务，设置资源使用超时策略。当任务运行时间超过设定阈值且资源使用率持续较高时，调度器会尝试将任务暂停，回收部分资源用于其他高优先级任务，待资源充足时再恢复任务执行。

（三）多租户企业级应用的资源管理与调度

场景描述：在一个大型企业中，多个部门共享一个 K8s 集群运行各自的业务应用。例如，研发部门运行多个开发测试环境的微服务应用，运维部门运行监控和日志收集服务，市场部门运行营销活动相关应用。
资源管理与调度策略：
- 命名空间与资源配额：为每个部门创建独立的命名空间，并设置资源配额。研发部门的命名空间根据开发项目的数量和规模分配适量的 CPU 和内存资源；运维部门的命名空间保证基本的系统监控和日志收集服务的资源需求；市场部门的命名空间根据营销活动的计划和预期规模分配资源。
- 网络策略与资源隔离：通过网络策略限制不同部门命名空间之间的流量访问，保障各部门应用的安全性和独立性。同时，利用 K8s 的资源隔离机制（如 RuntimeClass）为不同部门的应用分配不同的运行环境和资源，防止资源互相干扰。
- 调度策略调整：根据各部门应用的特点和需求，调整调度策略。例如，为运维部门的监控服务设置较高的调度优先级，确保其能够及时部署和运行；为市场部门的营销活动应用设置亲和性规则，将其调度到具有较高网络带宽的节点上，保障活动期间的用户体验。

六、注意事项

（一）资源请求与限制设置的平衡

在设置资源请求和限制时，需要在保障应用性能和资源利用率之间找到平衡。设置过高的资源请求会导致资源浪费和调度困难，设置过低的资源限制可能影响应用的正常运行。建议通过逐步调整和性能测试来确定最合适的值。

（二）调度策略的合理选择与配置

选择合适的调度策略并进行合理配置至关重要。对于简单的应用场景，K8s 默认调度器通常能够满足需求；但对于复杂业务场景，可能需要结合亲和性规则或开发自定义调度器。在配置调度策略时，应充分考虑应用的特点和集群的资源状况，避免因不合理的调度导致资源分配不均或应用性能下降。

（三）资源监控与调整的及时性

资源管理是一个动态的过程，需要持续监控集群和应用的资源使用情况，并根据实际情况及时调整资源分配和调度策略。建立完善的资源监控和告警系统，能够在资源紧张或出现异常时及时通知运维人员进行处理，避免对应用服务造成影响。

七、总结

本文深入探讨了 Kubernetes（K8s）的资源管理与调度策略，包括资源请求与限制的配置、调度策略的选择与应用、资源优化分配的方法以及实际应用场景中的案例分析。通过合理设置资源请求和限制，利用 K8s 的默认调度器和自定义调度器，结合资源配额管理等手段，可以有效优化集群资源利用率，保障应用的稳定运行和服务质量。在实际应用中，应根据业务需求和集群资源状况，灵活运用各种资源管理与调度策略，不断提升 K8s 集群的管理水平和资源使用效率。