Kubernetes支持哪些调度模式

Kubernetes（K8s）的调度模式围绕Pod 如何被分配到节点（Node）展开，核心分为自动调度、手动调度、高级调度策略三大类，其中高级调度策略又包含多种细分模式。以下是详细说明：

一、默认自动调度（Default Scheduling）

这是K8s最基础的调度模式，由kube-scheduler组件负责，无需用户额外配置。

1. 工作原理

kube-scheduler监听未调度的Pod（即spec.nodeName为空），通过预选（Filtering）和优选（Scoring）两个阶段选择最优节点：

• 预选：过滤掉不满足Pod需求的节点（如资源不足、端口冲突、污点不匹配等）。
• 优选：对通过预选的节点打分，选择得分最高的节点（如资源均衡、亲和性匹配等）。

2. 适用场景

无特殊调度需求的普通Pod，例如Web服务、无状态应用等。

二、手动调度（Manual Scheduling）

用户直接指定Pod运行的节点，绕过kube-scheduler。

1. 方式：nodeName字段

在Pod的spec.nodeName中直接填写目标节点的名称，Pod会被直接调度到该节点（即使节点不满足资源需求，也会强制调度）。
示例：

apiVersion: v1
kind: Pod
metadata:
name: manual-scheduled-pod
spec:
nodeName: node-01  # 直接指定节点
containers:
- name: nginx
image: nginx

2. 适用场景

• 测试环境强制Pod运行在特定节点。
• 节点维护时临时指定Pod位置。

三、高级调度模式（Advanced Scheduling）

通过标签（Label）、污点（Taint）、容忍（Toleration）等机制实现更灵活的调度策略，是生产环境最常用的模式。

1. 节点亲和性（Node Affinity）

通过节点标签定义Pod与节点的亲和关系，比nodeSelector更灵活（支持条件表达式、软/硬约束）。

分类：

• requiredDuringSchedulingIgnoredDuringExecution（硬亲和）：

必须满足的条件，否则Pod无法调度（类似nodeSelector但更强大）。

• preferredDuringSchedulingIgnoredDuringExecution（软亲和）：

优先满足的条件，不满足时仍可调度到其他节点。
示例（硬亲和：Pod必须运行在zone=us-east的节点）：

apiVersion: v1
kind: Pod
metadata:
name: node-affinity-pod
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: zone
operator: In
values:
- us-east
containers:
- name: nginx
image: nginx

2. Pod亲和性与反亲和性（Pod Affinity/Anti-Affinity）

基于其他Pod的标签定义调度规则，控制Pod之间的位置关系（同节点/不同节点）。

分类：

• Pod亲和性（Pod Affinity）：

让Pod与特定Pod运行在同一拓扑域（如节点、可用区）。

• Pod反亲和性（Pod Anti-Affinity）：

让Pod与特定Pod运行在不同拓扑域，实现高可用（如避免同一服务的Pod集中在单个节点）。
示例（Pod反亲和：同一Deployment的Pod不运行在同一节点）：

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: nginx
topologyKey: kubernetes.io/hostname  # 拓扑域为节点（hostname唯一）
containers:
- name: nginx
image: nginx

3. 污点（Taint）与容忍（Toleration）

节点通过污点拒绝不合适的Pod，Pod通过容忍声明自己可以接受特定污点，从而被调度到该节点。

核心逻辑：

• 污点（Taint）：给节点打“标记”，格式为key=value:effect，effect有三种：
• NoSchedule：Pod不容忍则无法调度到该节点。
• PreferNoSchedule：尽量不调度，但不是强制。
• NoExecute：不仅不调度，还会驱逐节点上已存在的、不容忍该污点的Pod。
• 容忍（Toleration）：Pod声明接受节点的污点，从而绕过限制。

示例（节点打污点，Pod通过容忍调度）：

# 给node-01打污点：key=dedicated, value=GPU, effect=NoSchedule
kubectl taint nodes node-01 dedicated=GPU:NoSchedule

# Pod声明容忍该污点
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
spec:
tolerations:
- key: "dedicated"
operator: "Equal"
value: "GPU"
effect: "NoSchedule"
containers:
- name: cuda
image: nvidia/cuda:11.0-base

典型场景：

• Master节点隔离：默认Master节点有node-role.kubernetes.io/master:NoSchedule污点，普通Pod无法调度。
• 专用节点：如GPU节点、高内存节点，仅允许特定Pod调度。

4. 自定义调度器（Custom Scheduler）

当K8s默认调度器无法满足需求时，可开发自定义调度器，并通过Pod的schedulerName字段指定使用它。

工作原理：

自定义调度器需实现kube-scheduler的接口，监听未调度的Pod，执行预选/优选逻辑，最终将Pod绑定到节点。
示例（Pod指定自定义调度器）：

apiVersion: v1
kind: Pod
metadata:
name: custom-scheduled-pod
spec:
schedulerName: my-custom-scheduler  # 指定自定义调度器名称
containers:
- name: nginx
image: nginx

适用场景：

• 特殊调度需求（如基于机器学习模型预测节点负载、跨集群调度等）。
• 企业级定制调度策略（如结合内部资源管理系统）。

5. 优先级调度（Priority Scheduling）

通过优先级（Priority）控制Pod的调度顺序，高优先级Pod会优先被调度，甚至在资源不足时驱逐低优先级Pod。

核心组件：

• PriorityClass：定义优先级（值越高优先级越高，范围1~1000000000）。
• Pod引用PriorityClass：通过spec.priorityClassName指定。

示例（定义高优先级，Pod优先调度）：

# 定义PriorityClass
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 1000
globalDefault: false  # 不设为默认优先级
description: "High priority for critical pods"

# Pod引用该PriorityClass
apiVersion: v1
kind: Pod
metadata:
name: high-priority-pod
spec:
priorityClassName: high-priority
containers:
- name: nginx
image: nginx

注意：

优先级调度需配合资源配额（ResourceQuota）和驱逐策略（Eviction）使用，避免高优先级Pod过度占用资源。

四、特殊场景调度模式

1. 静态Pod（Static Pod）

由kubelet直接管理，不经过API Server，也不由kube-scheduler调度。通常存放在节点的/etc/kubernetes/manifests目录下，用于部署控制平面组件（如kube-apiserver、etcd）。

2. DaemonSet调度

DaemonSet确保每个节点（或匹配标签的节点）运行一个Pod副本，由DaemonSet控制器负责调度，而非kube-scheduler。常用于日志采集（如Fluentd）、监控（如Node Exporter）等场景。

总结：调度模式对比

通过组合以上调度模式，可以覆盖从简单到复杂的各种场景，满足生产环境对Pod调度的灵活需求。