Ubuntu Kubernetes资源调度策略有哪些 - 问答

Ubuntu 上 Kubernetes 资源调度策略全览

在 Ubuntu 上运行的 Kubernetes 调度策略与操作系统无关，核心由 kube-scheduler 完成。调度器先通过一组**预选策略（Predicates）过滤节点，再用优选策略（Priorities）**打分排序，最终将 Pod 绑定到合适节点。常见预选包括基于资源请求的匹配，优选包括 LeastRequestedPriority、BalancedResourceAllocation、ImageLocalityPriority 等，用于在满足资源的前提下优化节点负载与镜像本地性。

常用调度策略与适用场景

策略	作用	关键字段或对象	典型场景
节点选择器 nodeSelector	按节点标签强制选择	spec.nodeSelector	将工作负载调度到带有特定标签（如 disktype=ssd、hardware-type=gpu）的节点
节点亲和 nodeAffinity	更强的节点选择，支持硬/软约束	spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution / preferredDuringSchedulingIgnoredDuringExecution	必须满足某些标签（硬约束），或优先选择某些标签（软约束，可设权重）
Pod 亲和/反亲和 podAffinity/podAntiAffinity	基于已运行 Pod 的标签进行协同/隔离	spec.affinity.podAffinity / podAntiAffinity	将频繁通信的前后端 Pod 放在一起（亲和），或将副本分散到不同节点/可用区（反亲和）
污点与容忍度 Taints/Tolerations	节点排斥 Pod，除非 Pod 明确容忍	node.spec.taints / pod.spec.tolerations	控制 master 节点准入、专用节点（如 GPU）隔离、节点维护时优雅驱逐
定向调度 nodeName	直接指定目标节点	spec.nodeName	调试、故障定位、特定硬件直连场景（绕过调度器）
资源请求与限制 requests/limits	影响调度与 QoS，保障关键负载	spec.containers[].resources.requests/limits	为 Pod 设置 CPU/Memory 的 request/limit，确保可被调度且获得承诺资源
命名空间配额 ResourceQuota	限制 Namespace 总资源用量	ResourceQuota	多团队/多项目环境下防止资源超卖
资源配额范围 LimitRange	为容器设置默认/最大/最小资源	LimitRange	统一 Pod/容器资源边界，避免异常配置
调度器优先级 PriorityClass	高优先级工作负载抢占	PriorityClass / spec.priorityClassName	核心系统组件、关键业务优先调度与保留

上述策略中，nodeSelector、nodeAffinity、podAffinity/podAntiAffinity、Taints/Tolerations 是最常用的精细化调度手段；亲和性规则支持“必须满足”（硬约束）与“尽量满足”（软约束，可配置权重）；污点的 NoSchedule、PreferNoSchedule、NoExecute 效果分别用于排斥调度、尽量不调度、以及不兼容时驱逐存量 Pod。

资源请求与服务质量 QoS

为容器设置 requests 与 limits 不仅影响调度（调度器依据 requests 匹配节点资源），也决定 QoS 等级：当节点资源紧张时，低 QoS 的 Pod 更易被终止以释放资源。通常建议为关键负载设置合理的 requests/limits，避免资源争用导致的不稳定。

配额与边界管理

在 Namespace 级别可用 ResourceQuota 限制该命名空间下所有 Pod 的 requests/limits 总量，防止超用；用 LimitRange 为容器设置默认/最大/最小资源边界，统一规范。例如：限定某命名空间的 requests.cpu=1000m、requests.memory=1000Mi、limits.cpu=2000m、limits.memory=2000Mi。

快速上手示例

节点选择器 nodeSelector

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector: { matchLabels: { app: my-app } }
  template:
    metadata: { labels: { app: my-app } }
    spec:
      containers:
      - name: app
        image: nginx:1.25
      nodeSelector:
        hardware-type: gpu

节点亲和 nodeAffinity（硬约束）

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: hardware-type
          operator: In
          values: ["gpu"]

污点与容忍度 Taints/Tolerations

# 给节点打污点
kubectl taint nodes node1 dedicated=gpu:NoSchedule

# Pod 容忍该污点
tolerations:
- key: dedicated
  operator: Equal
  value: gpu
  effect: NoSchedule

上述示例展示了通过 nodeSelector 定向到 GPU 节点，用 nodeAffinity 的硬约束保证调度到带指定标签的节点，以及用 Taints/Tolerations 将 GPU 节点专用于特定负载。

0 赞

0 踩