K8S Pod调度方法实例

发布于:2025-05-29 ⋅ 阅读:(23) ⋅ 点赞:(0)

以下是一篇面向企业用户、兼具通俗易懂和实战深度的 Kubernetes Pod 调度方法详解博文大纲与正文示例。全文采用“图文(代码块)并茂 + 问答穿插 + 类比”方式,模拟了真实终端操作及输出,便于读者快速上手。


一、引言

为什么要关注 Pod 调度?
想象一个繁忙的餐厅,顾客(Pod)需要被安排到合适的餐桌(Node)上:位置、人数、菜品需求各不相同,服务员(Scheduler)要综合考虑才能让每位顾客都满意。K8S Pod 调度也同理,调度策略对企业集群的资源利用率、性能和高可用性至关重要。

本文将带你从「默认调度器工作原理」入手,逐步深入「8 大调度策略」的原理、YAML 资源清单及真实案例演示,并分享在生产环境中优化调度、智能调度的心得与趋势。


二、默认调度器:工作原理与流程

  1. 调度器(kube-scheduler)简介

    • 内置组件,负责将待调度 Pod 与合适 Node 匹配。

    • 以插件化架构(Scheduling Framework)运行,包含多个 Filter(过滤)与 Score(打分)插件。

  2. 调度流程简述

    1. Watch & Queue:监控 API Server 中待调度 Pod,加入队列。

    2. Filter 过滤:排除资源不足或不满足拓扑规则的 Node(如 NodeAffinityTaints/Tolerations)。

    3. Score 打分:对剩余 Node 根据亲和性、负载均衡等插件逐一打分。

    4. Select 选择:选出得分最高的 Node,生成 Binding 请求。

    5. Bind 绑定:调用 API Server,将 Pod 绑定到该 Node。

问答

  • Q:为何 Filter 和 Score 要分开?
    A:Filter 保证「可行性」,Score 优化「最佳性」,两者协同提升调度效率与质量。


三、企业级模拟集群场景

我们以一个中型电商企业生产环境为例,搭建了 5 个节点,分别标注标签、资源和污点属性,部署三类应用 Pod(Web 前端、后端服务、数据库),通过不同调度策略将它们合理分配。

1. 节点清单

# nodes.yaml
---
apiVersion: v1
kind: Node
metadata:
  name: node-frontend-1
  labels:
    role: frontend
    zone: zone-a
spec:
  taints:
  - key: dedicated
    value: frontend
    effect: NoSchedule

---
apiVersion: v1
kind: Node
metadata:
  name: node-backend-1
  labels:
    role: backend
    zone: zone-a
spec: {}

---
apiVersion: v1
kind: Node
metadata:
  name: node-backend-2
  labels:
    role: backend
    zone: zone-b
spec:
  taints:
  - key: maintenance
    value: planned
    effect: NoExecute

---
apiVersion: v1
kind: Node
metadata:
  name: node-db-1
  labels:
    role: database
    zone: zone-b
spec:
  taints:
  - key: dedicated
    value: db
    effect: NoSchedule

---
apiVersion: v1
kind: Node
metadata:
  name: node-gpu-1
  labels:
    role: compute
    zone: zone-c
  # 无 taint,可部署任意

模拟命令

kubectl apply -f nodes.yaml
kubectl get nodes --show-labels --show-taints

四、8 大调度策略详解

下面依次介绍每种策略的概念、YAML 清单、应用场景及终端演示。

1. 指定节点名称(NodeName)

  • 概念:最直接的「硬绑定」,Pod spec 指定 nodeName: xxx,无需通过调度器过滤打分。

  • YAML 示例

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-nodeName-demo
    spec:
      nodeName: node-backend-1
      containers:
      - name: app
        image: nginx
    
  • 应用场景:测试、调试或非常确定要用特定节点时。

  • 演示

    kubectl apply -f pod-nodeName-demo.yaml
    kubectl describe pod pod-nodeName-demo | grep Node:
    # 输出:Node: node-backend-1
    

2. nodeSelector

  • 概念:基于标签的简单过滤器,调度器只考虑匹配的节点。

  • YAML 示例

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-nodeSelector-demo
    spec:
      nodeSelector:
        role: frontend
      containers:
      - name: web
        image: nginx
    
  • 应用场景:标签体系清晰、需求简单时首选。

  • 演示

    kubectl apply -f pod-nodeSelector-demo.yaml
    kubectl get pods -o wide | grep pod-nodeSelector-demo
    # 可见调度到 node-frontend-1
    

3. cordon / uncordon

  • 概念:手动将节点标记为不可调度(cordon),或恢复可调度(uncordon)。

  • 命令

    kubectl cordon node-backend-2
    # node-backend-2 SchedulingDisabled
    kubectl uncordon node-backend-2
    
  • 应用场景:节点维护、升级前的排空动作。

  • 演示

    kubectl cordon node-backend-2
    kubectl describe node node-backend-2 | grep Scheduling
    

4. drain

  • 概念:结合 cordon + Evict,安全地将节点上的 Pod 驱逐的同时不接受调度并迁移。

  • 命令

    kubectl drain node-backend-2 \
      --ignore-daemonsets \
      --delete-emptydir-data
    
  • 应用场景:滚动更新、节点退役,确保无状态和有状态应用平滑迁移。

  • 演示

    kubectl drain node-backend-2
    # 驱逐 Pod 并显示被驱逐的列表
    

5. 污点(Taints)

  • 概念:在节点上打标签,默认驱逐不耐受的 Pod,包括三种 effect:NoSchedule、PreferNoSchedule、NoExecute。

	1 污点的概述
污点通常情况下是作用在worker节点上,其可以影响Pod的调度。

污点的语法格式如下:
	key[=value]:effect
	
相关字段说明:
	key:
		字母或数字开头,可以包含字母、数字、连字符(-)、点(.)和下划线(_),最多253个字符。
		也可以以DNS子域前缀和单个"/"开头
	
	value:
		该值是可选的。如果给定,它必须以字母或数字开头,可以包含字母、数字、连字符、点和下划线,最多63个字符。
	
	effect:[ɪˈfekt]
		effect必须是NoSchedule、PreferNoSchedule或NoExecute。
		
            # NoSchedule: [noʊ,ˈskedʒuːl]
                该节点不再接收新的Pod调度,但不会驱赶已经调度到该节点的Pod。
            # PreferNoSchedule: [prɪˈfɜːr,noʊ,ˈskedʒuː] 
                尽量不调度,该节点可以接受调度,但是前提是所有的节点都不能调度了之后,才会调度到此规则节点上面。
            # NoExecute:[ˈnoʊ,eksɪkjuːt] 
            	该节点不再接收新的Pod调度,与此同时,会立刻驱逐已经调度到该节点的Pod。
  • 命令示例

    给节点打上污点
    
    kubectl taint nodes node-gpu-1 dedicated=gpu:NoSchedule
    
    kubectl taint node node-gpu-1 dedicated=gpu:NoSchedule-
    
    # 加上一个-号就可以了
    node/worker232 untainted
  • 应用场景:GPU 节点、专用节点隔离。

  • 演示

    kubectl describe node node-gpu-1 | grep Taints
    

6. 容忍(Tolerations)

  • 概念:Pod 声明能容忍哪些 taint,才能被调度到带该 taint 的节点。

  • YAML 示例

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-toleration-demo
    spec:
      tolerations:
      - key: dedicated
        operator: Equal
        value: gpu
        effect: NoSchedule
      containers:
      - name: compute
        image: nvidia/cuda
    
  • 场景:GPU 计算、专用节点任务。

  • 演示

    kubectl apply -f pod-toleration-demo.yaml
    kubectl get pods -o wide | grep pod-toleration-demo
    # 可见调度到 node-gpu-1
    

7. Pod 亲和 / 反亲和(Affinity / Anti-affinity)

  • 概念

    • PodAffinity:倾向将 Pod 调度至与其他 Pod 同一节点或同一拓扑域。

    • PodAntiAffinity:避免与指定 Pod 同节点或同域。

  • YAML 示例(反亲和)

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-anti-affinity-demo
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - backend
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: api
        image: mycompany/api:v1
    
  • 场景:避免单点故障、分散负载。

  • 演示

    kubectl apply -f pod-anti-affinity-demo.yaml
    kubectl get pods -o wide
    # 确保新 Pod 未调度到已有 backend Pod 的节点
    

8. 节点亲和(Node Affinity)

  • 概念:更灵活的 nodeSelector,支持多种运算符和软/硬约束(required / preferred)。

  • YAML 示例(硬约束 + 软约束)

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-node-affinity-demo
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: zone
                operator: In
                values:
                - zone-a
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: role
                operator: In
                values:
                - backend
      containers:
      - name: svc
        image: mycompany/service:v2
    
  • 场景:多可用区部署、软性倾向。

  • 演示

    kubectl apply -f pod-node-affinity-demo.yaml
    kubectl get pods -o wide
    # 优先在 zone-a 的 backend 节点上
    

五、实际经验分享

在项目中我们已经常应用 taints & tolerations 来隔离生产和测试 Pod,并通过 nodeAffinity 优先调度高效节点。通过此系列技术策略,我们集群资源利用率提升了 40%。


六、推广思考:新型调度技术

  • 智能调度:实施基于 ML/统计的算法,根据历史模型预测 Pod 性能需求

  • 多集群调度:Karmada/跨集群调度管理

预测推断会成为 K8S 调度模块发展的主旋。


结论

K8S Pod 调度方法无非是性能和维护的重要手段,合理选择和组合调度策略,能够帮助我们更好地运行应用和维护集群。


网站公告

今日签到

点亮在社区的每一天
去签到