Kubernetes在CentOS上的资源调度是如何进行的 - 问答

Kubernetes 在 CentOS 上的资源调度机制

一调度流程与核心组件

在 CentOS 上，Kubernetes 的调度由控制平面的 kube-scheduler 完成，遵循“两阶段”机制：先进行 Predicate 预选（过滤不满足条件的节点，如资源不足、端口冲突、亲和/反亲和不匹配等），再进行 Priority 优选（按策略为候选节点打分，如资源余量、亲和性权重、拓扑分布等），最终选出得分最高的节点并执行 Bind 将 Pod 与 Node 绑定。调度器持续监听 API Server，只对 spec.nodeName 为空 的待调度 Pod 进行上述流程。这套机制与操作系统发行版无关，在 CentOS 上的行为与在其他 Linux 发行版一致。

二调度依据与常用策略

资源请求与可分配量：调度以容器的 requests 为依据，结合节点的 allocatable 资源进行可行性过滤；limits 主要用于运行时限制（CPU 限流、内存 OOM 等）。合理设置 requests/limits 是调度成功与稳定运行的前提。
节点选择：
- nodeSelector：按节点标签进行基础定向调度。
- nodeAffinity：更灵活的节点选择，支持硬性/软性规则，可按地域、机型、硬件特性（如 SSD）定向。
污点与容忍：通过 Taints/Tolerations 实现节点专用化（如 GPU 节点）、隔离与驱逐控制（如 NoExecute 对不健康节点的快速驱逐）。
Pod 间布局：
- podAffinity/podAntiAffinity：让相关或互斥的 Pod 共置或分散，降低网络时延或提升容灾。
- Topology Spread Constraints：按 zone/rack/hostname 等拓扑域均匀打散，控制最大不均衡度（maxSkew）。
批量与高级调度：对 Gang Scheduling（关联任务“全或全不”）与 Capacity Scheduling（容量感知）等批量作业场景，原生调度能力有限，通常借助调度器插件或云厂商扩展能力实现。

三资源请求 Limits 与 QoS 对调度与运行的影响

定义方式：在容器上设置 requests/limits（CPU 与 Memory），例如 requests 用于调度与 Guaranteed 判定，limits 用于运行时上限与 QoS 归类。
QoS 类别与驱逐顺序：
- Guaranteed（requests == limits）：最高优先级，节点资源紧张时最后被驱逐。
- Burstable（requests < limits）：中等优先级。
- BestEffort（未设 requests/limits）：最低优先级，最先被驱逐。
运行影响：
- CPU 为可压缩资源，超限会被限流（throttling）。
- 内存为不可压缩资源，超限可能触发 OOMKilled。
实践要点：为关键负载设置合理 requests（保障调度与稳定性），为突发场景设置适度 limits，避免无限制导致节点不稳定或被优先驱逐。

四拓扑感知与专用资源调度

CPU 拓扑感知：启用 CPU Manager 与 NUMA 拓扑感知，将关键负载固定到特定 CPU 核心/NUMA 节点，减少跨 NUMA 访存与上下文切换抖动，提升延迟敏感型应用性能。
GPU 拓扑感知：在多 GPU 节点上按拓扑合理放置 Pod，减少 GPU/NUMA 间切换开销，提升训练/推理性能。
动态资源与混部：结合 动态资源超卖、CPU QoS、内存 QoS、L3 Cache/内存带宽隔离 等策略，在保证高优任务性能的同时提升集群利用率（适用于在离线混部等场景）。

五在 CentOS 上的落地配置示例

示例一基础资源配置（requests/limits）

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
  - name: app
    image: nginx:1.25
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"

示例二亲和性与反亲和性（分散部署 + 定向节点）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values: ["web"]
              topologyKey: kubernetes.io/hostname
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: disktype
                operator: In
                values: ["ssd"]
      containers:
      - name: app
        image: nginx:1.25
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"

示例三污点与容忍（GPU 节点）

# 给节点打上污点
kubectl taint nodes node-gpu1 accelerator=nvidia:NoSchedule

# Pod 容忍该污点以调度到 GPU 节点
# tolerations:
# - key: "accelerator"
#   operator: "Equal"
#   value: "nvidia"
#   effect: "NoSchedule"

示例四拓扑分布约束（跨节点均匀）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web
      containers:
      - name: app
        image: nginx:1.25
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"

上述示例覆盖了调度所需的关键维度：requests/limits（调度与 QoS）、亲和/反亲和（布局策略）、污点/容忍（专用节点）、拓扑分布（容错与均衡）。

0 赞

0 踩