1. Kubernetes调度的基础逻辑

Kubernetes集群中的资源管理就像是机场调度中心的任务分配器：它需要将不同航班的飞机（Pod）分配到合适的跑道（节点）上。默认的调度器kube-scheduler依据节点的资源余量（CPU、内存）和Pod的请求值执行分配，但这仅仅是基础操作。**亲和性（Affinity/Anti-affinity）和污点与容忍（Taints and Tolerations）**相当于调度策略的高级导航系统，能够实现精细化控制。

2. 亲和性调度：让Pod学会"找朋友"

2.1 概念说明

亲和性分为两类：

  • 节点亲和性（Node Affinity）：让Pod偏好或必须运行在特定标签的节点上
  • Pod亲和性/反亲和性（Pod Affinity/Anti-affinity）：根据其他Pod的分布调整自己的部署位置

2.2 配置示例（YAML技术栈）

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  affinity:
    # 节点亲和性：优先选择带有"env=prod"标签的节点
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 80
        preference:
          matchExpressions:
          - key: env
            operator: In
            values: ["prod"]
    # Pod反亲和性：禁止与同类型Pod共享节点
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values: ["web"]
        topologyKey: "kubernetes.io/hostname"
  containers:
  - name: nginx
    image: nginx:latest

代码解析：

  • preferredDuringScheduling：软约束，调度器尽量满足但不保证
  • requiredDuringScheduling：硬约束，不满足则Pod无法调度
  • topologyKey定义拓扑域（如主机名、机架名称）

3. 反亲和性：远离"竞争对手"的策略

3.1 场景案例

假设有一个分布式数据库，需要保证同一分片的多个副本不在同一个物理机架上（防止区域性故障）。此时可通过podAntiAffinity配合topologyKey实现跨机架部署。

3.2 强化版配置

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cassandra
spec:
  serviceName: "cassandra"
  replicas: 3
  template:
    metadata:
      labels:
        app: cassandra
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values: ["cassandra"]
            topologyKey: "failure-domain.beta.kubernetes.io/zone"
      containers:
      - name: cassandra
        image: cassandra:4.0

功能亮点：

  • 使用failure-domain标签表示故障域（例如AWS的可用区）
  • 确保三个Pod分布在三个不同的可用区

4. 污点与容忍：为节点设立"禁区"

4.1 核心机制

  • 污点（Taint）：节点的"臭味标记"，阻止未授权的Pod进驻
  • 容忍（Toleration）：Pod的"防毒面具"，允许其进入污染区

4.2 GPU节点保护示例

# 标记GPU节点（操作节点）
kubectl taint nodes node01 gpu=true:NoSchedule

# 声明容忍的Pod
apiVersion: v1
kind: Pod
metadata:
  name: ai-model
spec:
  tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  containers:
  - name: tensorflow
    image: tensorflow/gpu:latest

参数解析：

  • effect的类型：
    • NoSchedule：禁止新Pod调度
    • PreferNoSchedule：尽量不调度
    • NoExecute：驱逐现有Pod

5. 关联技术：节点选择器与拓扑分布

5.1 节点选择器（nodeSelector）对比

# 简单场景替代方案
spec:
  nodeSelector:
    disktype: ssd

适用简单标签匹配场景，但缺少复杂的逻辑运算符。

5.2 拓扑分布约束（Topology Spread Constraints）

spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: web

优势分析：

  • maxSkew定义最大不平衡度
  • 配合亲和性可实现全局平衡策略

6. 技术优缺点分析

6.1 亲和性体系

优点：

  • 支持软硬混合策略
  • 基于拓扑的隔离能力
  • 支持权重系数精细控制

缺点：

  • 复杂规则可能引发调度失败
  • 反亲和性过度使用导致资源碎片

6.2 污点系统

优势：

  • 节点级别的资源隔离
  • 支持分阶段驱逐机制
  • 与节点维护操作深度集成

缺陷：

  • 全局污染可能导致资源浪费
  • 容忍度配置不当引发安全风险

7. 生产环境注意事项

  1. 标签管理规范

    • 建立命名规则（如team=dev, env=prod）
    • 避免使用动态生成标签（如IP地址）

  2. 资源预热策略

    • 为关键Pod配置priorityClassName
    • 预留缓冲资源应对调度延迟

  3. 容忍度安全控制

    • 限制NoExecute容忍的权限
    • 使用准入控制器校验配置

  4. 监控维度

    • 跟踪Unschedulable事件
    • 分析节点利用率与亲和性分布的关联性

8. 实战场景总结

场景一：微服务共置优化

前端服务（frontend）需要与缓存服务（redis）部署在同一可用区以降低延迟：

podAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  - labelSelector:
      matchLabels:
        app: redis
    topologyKey: topology.kubernetes.io/zone

场景二：金丝雀发布防护

隔离新版本Pod到特定节点池：

kubectl taint nodes canary-pool version=beta:NoSchedule

9. 文章总结

Kubernetes调度机制的高级功能如同交通管制系统中的智能信号灯系统：亲和性让关键服务"抱团取暖"，反亲和性确保关键业务保持安全距离，污点与容忍则像设立特殊车道，只有获得许可的车辆才能通行。掌握这些工具的组合用法需要深入理解业务特性，例如在混合云环境中，可通过污点区分本地IDC节点与公有云节点，同时为跨云同步服务配置双向亲和性规则。