简体中文 繁體中文 English 日本語 Deutsch 한국 사람 بالعربية TÜRKÇE português คนไทย Français

开启辅助访问 切换到宽版

站内搜索

搜索

活动公告

通知：是的！我们正在计划一个大动作！
11-02 12:46
通知：Telegram 推送频道https://t.me/+2tB3a7aKXlw2YjA1 及时接收第一手论坛帖子信息～
10-23 09:32
通知：本站资源由网友上传分享，如有违规等问题请到版务模块进行投诉，将及时处理！
10-23 09:31
通知：加入QQ社群吧 https://qm.qq.com/q/QZibQd1hiq
10-23 09:28
通知：签到时间调整为每日4:00（东八区）
10-23 09:26
>社区 > 科技 > 经验交流 >帖子
本版发帖返回

K8s节点调度策略详解从原理到实践掌握资源分配优化技巧提升容器集群整体性能与稳定性

威震华夏关云长

3万

主题

349

科技点

3万

积分

大区版主

木柜子打湿

积分
31898

三倍冰淇淋无人之境【一阶】财Doro小樱（小丑装）立华奏以外的星空【二阶】⑨的冰沙
发表于 2025-9-18 02:20:07 | 显示全部楼层 |阅读模式

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要 登录 才可以下载或查看，没有账号？立即注册

x
引言

Kubernetes（简称K8s）作为当前最流行的容器编排平台，其调度系统是确保容器应用高效运行的核心组件之一。在复杂的集群环境中，如何合理地将Pod分配到最合适的节点上，直接关系到整个集群的资源利用率、应用性能和系统稳定性。本文将深入探讨K8s的节点调度策略，从基本原理到实际应用，帮助读者全面理解并掌握资源分配优化技巧，从而提升容器集群的整体性能与稳定性。

K8s调度器工作原理

调度器概述

Kubernetes调度器（kube-scheduler）是集群控制平面的核心组件之一，其主要职责是监视新创建的尚未分配节点的Pod，并为它们选择一个最佳节点来运行。调度决策考虑了多种因素，包括资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后期限等。

调度过程

K8s的调度过程主要分为两个阶段：

1. 过滤（Predicates）阶段：调度器会遍历所有可用节点，根据Pod的资源请求、节点选择器、亲和性/反亲和性规则等条件筛选出符合要求的候选节点。这一阶段是硬性约束，任何不满足条件的节点都会被排除。
2. 打分（Priorities）阶段：调度器对过滤阶段得到的候选节点进行打分，根据一系列优先级函数为每个节点计算一个分数，最终选择得分最高的节点作为Pod的目标节点。这一阶段是软性约束，用于在多个符合条件的节点中选择最优的一个。

过滤（Predicates）阶段：调度器会遍历所有可用节点，根据Pod的资源请求、节点选择器、亲和性/反亲和性规则等条件筛选出符合要求的候选节点。这一阶段是硬性约束，任何不满足条件的节点都会被排除。

打分（Priorities）阶段：调度器对过滤阶段得到的候选节点进行打分，根据一系列优先级函数为每个节点计算一个分数，最终选择得分最高的节点作为Pod的目标节点。这一阶段是软性约束，用于在多个符合条件的节点中选择最优的一个。

调度框架

Kubernetes从v1.19版本开始引入了调度框架（Scheduling Framework），这是一个可插拔的架构，允许用户通过自定义插件来扩展调度器的功能。调度框架定义了一系列扩展点，调度器在这些扩展点上调用插件来影响调度决策。

主要的扩展点包括：

• Filter：类似于Predicates，用于过滤不符合条件的节点
• Score：类似于Priorities，用于为节点打分
• PreFilter：在Filter之前执行，用于预处理或检查
• PostFilter：在Filter之后执行，当没有可用节点时执行
• PreScore：在Score之前执行，用于预处理或检查
• NormalizeScore：在Score之后执行，用于标准化分数
• Reserve：在绑定之前执行，用于预留资源
• Permit：在绑定之前执行，用于允许或延迟绑定
• PreBind：在绑定之前执行，用于预处理
• Bind：执行绑定操作
• PostBind：在绑定之后执行，用于清理工作

常见的节点调度策略

默认调度策略

Kubernetes调度器默认使用一系列内置的调度算法，包括：

1. 资源请求与限制：调度器会考虑Pod的资源请求（CPU、内存等）和节点的可用资源。只有当节点的可用资源满足Pod的资源请求时，该节点才会被考虑。
2. 节点选择器（NodeSelector）：通过为Pod指定nodeSelector，可以限制Pod只能调度到具有特定标签的节点上。

资源请求与限制：调度器会考虑Pod的资源请求（CPU、内存等）和节点的可用资源。只有当节点的可用资源满足Pod的资源请求时，该节点才会被考虑。

节点选择器（NodeSelector）：通过为Pod指定nodeSelector，可以限制Pod只能调度到具有特定标签的节点上。
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5.   name: nginx
  6. spec:
  7.   containers:
  8.   - name: nginx
  9.     image: nginx
  10.   nodeSelector:
  11.     disktype: ssd
复制代码

1. 节点亲和性（Node Affinity）：比nodeSelector更灵活的节点选择机制，支持硬性要求（required）和软性偏好（preferred）。
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5.   name: with-node-affinity
  6. spec:
  7.   affinity:
  8.     nodeAffinity:
  9.       requiredDuringSchedulingIgnoredDuringExecution:
  10.         nodeSelectorTerms:
  11.         - matchExpressions:
  12.           - key: kubernetes.io/e2e-az-name
  13.             operator: In
  14.             values:
  15.             - e2e-az1
  16.             - e2e-az2
  17.       preferredDuringSchedulingIgnoredDuringExecution:
  18.       - weight: 1
  19.         preference:
  20.           matchExpressions:
  21.           - key: another-node-label-key
  22.             operator: In
  23.             values:
  24.             - another-node-label-value
  25.   containers:
  26.   - name: with-node-affinity
  27.     image: k8s.gcr.io/pause:2.0
复制代码

1. Pod亲和性与反亲和性（Pod Affinity/Anti-Affinity）：基于已在节点上运行的Pod标签来决定新Pod的调度位置。
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5.   name: with-pod-affinity
  6. spec:
  7.   affinity:
  8.     podAffinity:
  9.       requiredDuringSchedulingIgnoredDuringExecution:
  10.       - labelSelector:
  11.           matchExpressions:
  12.           - key: security
  13.             operator: In
  14.             values:
  15.             - S1
  16.         topologyKey: topology.kubernetes.io/zone
  17.     podAntiAffinity:
  18.       preferredDuringSchedulingIgnoredDuringExecution:
  19.       - weight: 100
  20.         podAffinityTerm:
  21.           labelSelector:
  22.             matchExpressions:
  23.             - key: security
  24.               operator: In
  25.               values:
  26.               - S2
  27.           topologyKey: topology.kubernetes.io/zone
  28.   containers:
  29.   - name: with-pod-affinity
  30.     image: k8s.gcr.io/pause:2.0
复制代码

1. 污点（Taints）和容忍（Tolerations）：节点可以设置”污点”来排斥特定的Pod，而Pod可以通过设置”容忍”来接受特定的污点。
  2. # 节点设置污点
  3. kubectl taint nodes node1 key=value:NoSchedule
  5. # Pod设置容忍
  6. apiVersion: v1
  7. kind: Pod
  8. metadata:
  9.   name: myapp
  10. spec:
  11.   containers:
  12.   - name: myapp
  13.     image: myapp:latest
  14.   tolerations:
  15.   - key: "key"
  16.     operator: "Equal"
  17.     value: "value"
  18.     effect: "NoSchedule"
复制代码

自定义调度策略

除了内置的调度策略，Kubernetes还支持自定义调度策略，主要通过以下方式实现：

1. 自定义调度器：用户可以开发自己的调度器替代默认的kube-scheduler。自定义调度器需要实现Kubernetes调度器接口，并能够与API Server交互。
2. 调度器扩展：通过调度框架的插件机制，用户可以开发自定义插件来扩展调度器的功能，而不需要替换整个调度器。
3. 调度策略配置文件：可以通过配置文件来调整调度器的行为，包括启用/禁用特定的调度插件、调整插件参数等。

自定义调度器：用户可以开发自己的调度器替代默认的kube-scheduler。自定义调度器需要实现Kubernetes调度器接口，并能够与API Server交互。

调度器扩展：通过调度框架的插件机制，用户可以开发自定义插件来扩展调度器的功能，而不需要替换整个调度器。

调度策略配置文件：可以通过配置文件来调整调度器的行为，包括启用/禁用特定的调度插件、调整插件参数等。
  2. apiVersion: kubescheduler.config.k8s.io/v1beta2
  3. kind: KubeSchedulerConfiguration
  4. profiles:
  5. - schedulerName: default-scheduler
  6.   plugins:
  7.     score:
  8.       disabled:
  9.       - name: NodeResourcesBalancedAllocation
  10.       enabled:
  11.       - name: MyCustomPlugin
复制代码

资源分配优化技巧

资源请求与限制的合理设置

合理设置Pod的资源请求（requests）和限制（limits）是优化Kubernetes集群资源利用的关键：

1. 资源请求（Requests）：Pod调度时，Kubernetes会确保节点有足够的可用资源来满足Pod的资源请求。资源请求也用于Kubernetes计算Pod的QoS（服务质量）类别。
2. 资源限制（Limits）：Pod可以使用的资源上限。当Pod尝试使用超过限制的资源时，可能会被限制或终止。

资源请求（Requests）：Pod调度时，Kubernetes会确保节点有足够的可用资源来满足Pod的资源请求。资源请求也用于Kubernetes计算Pod的QoS（服务质量）类别。

资源限制（Limits）：Pod可以使用的资源上限。当Pod尝试使用超过限制的资源时，可能会被限制或终止。

优化技巧：

• 准确评估资源需求：通过监控工具（如Prometheus、Metrics Server）收集历史数据，准确评估应用的实际资源需求。
• 为关键组件设置适当的资源请求：确保系统关键组件（如数据库、核心服务）有足够的资源请求，以保证其稳定运行。
• 避免过度设置资源限制：过高的资源限制可能导致资源浪费，而过低的限制可能导致应用性能下降或被终止。
• 使用垂直Pod自动伸缩（VPA）：VPA可以根据实际使用情况自动调整Pod的资源请求和限制。
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5.   name: resource-optimized-pod
  6. spec:
  7.   containers:
  8.   - name: app
  9.     image: myapp:latest
  10.     resources:
  11.       requests:
  12.         cpu: "500m"
  13.         memory: "512Mi"
  14.       limits:
  15.         cpu: "1000m"
  16.         memory: "1Gi"
复制代码

资源配额与限制范围

1. 资源配额（Resource Quotas）：通过命名空间级别的资源配额，可以限制该命名空间中可以创建的资源总量，防止某个团队或应用占用过多资源。
  2. apiVersion: v1
  3. kind: ResourceQuota
  4. metadata:
  5.   name: compute-resources
  6.   namespace: dev-team
  7. spec:
  8.   hard:
  9.     pods: "10"
  10.     requests.cpu: "4"
  11.     requests.memory: "8Gi"
  12.     limits.cpu: "10"
  13.     limits.memory: "16Gi"
复制代码

1. 限制范围（Limit Ranges）：为命名空间中的Pod或容器设置默认的资源请求和限制，以及最小和最大资源限制。
  2. apiVersion: v1
  3. kind: LimitRange
  4. metadata:
  5.   name: cpu-resource-constraint
  6.   namespace: dev-team
  7. spec:
  8.   limits:
  9.   - default:
  10.       cpu: "1"
  11.     defaultRequest:
  12.       cpu: "0.5"
  13.     max:
  14.       cpu: "2"
  15.     min:
  16.       cpu: "0.25"
  17.     type: Container
复制代码

节点资源优化

1. 节点专用于特定工作负载：通过污点和容忍、节点亲和性等机制，可以将特定类型的节点专用于特定的工作负载，如CPU密集型、内存密集型或GPU加速型任务。
2. 使用kubelet的预留资源：在kubelet配置中预留系统资源，确保系统守护进程有足够的资源运行，避免因资源不足导致节点不稳定。

节点专用于特定工作负载：通过污点和容忍、节点亲和性等机制，可以将特定类型的节点专用于特定的工作负载，如CPU密集型、内存密集型或GPU加速型任务。

使用kubelet的预留资源：在kubelet配置中预留系统资源，确保系统守护进程有足够的资源运行，避免因资源不足导致节点不稳定。
  2. # kubelet配置示例
  3. apiVersion: kubelet.config.k8s.io/v1beta1
  4. kind: KubeletConfiguration
  5. evictionHard:
  6.   memory.available: "200Mi"
  7.   nodefs.available: "10%"
  8. systemReserved:
  9.   cpu: "500m"
  10.   memory: "512Mi"
  11. kubeReserved:
  12.   cpu: "500m"
  13.   memory: "512Mi"
复制代码

1. 使用节点自动伸缩：结合集群自动伸缩器（Cluster Autoscaler）和节点自动伸缩组，根据负载情况动态调整节点数量，优化资源利用率。

Pod优先级与抢占

1. Pod优先级（PriorityClass）：为Pod设置优先级，确保关键Pod在资源紧张时优先调度。
  2. apiVersion: scheduling.k8s.io/v1
  3. kind: PriorityClass
  4. metadata:
  5.   name: high-priority
  6. value: 1000000
  7. globalDefault: false
  8. description: "This priority class should be used for critical service pods only."
复制代码

1. Pod抢占（Preemption）：当高优先级的Pod无法调度时，Kubernetes可以尝试从节点上驱逐低优先级的Pod，以腾出资源给高优先级的Pod。
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5.   name: high-priority-pod
  6. spec:
  7.   priorityClassName: high-priority
  8.   containers:
  9.   - name: high-priority-app
  10.     image: myapp:latest
复制代码

高级调度特性

拓扑分布约束

拓扑分布约束（Topology Spread Constraints）允许用户控制Pod在集群拓扑结构中的分布，如跨区域、可用区、节点等。这有助于提高应用的高可用性和故障容忍能力。
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5.   name: my-app
  6. spec:
  7.   replicas: 6
  8.   selector:
  9.     matchLabels:
  10.       app: my-app
  11.   template:
  12.     metadata:
  13.       labels:
  14.         app: my-app
  15.     spec:
  16.       topologySpreadConstraints:
  17.       - maxSkew: 1
  18.         topologyKey: topology.kubernetes.io/zone
  19.         whenUnsatisfiable: DoNotSchedule
  20.         labelSelector:
  21.           matchLabels:
  22.             app: my-app
  23.       containers:
  24.       - name: my-app
  25.         image: myapp:latest
复制代码

自定义调度器

除了默认的kube-scheduler，用户可以开发自定义调度器来满足特定的调度需求。自定义调度器需要实现Kubernetes调度器接口，并能够与API Server交互。
  2. // 自定义调度器示例代码
  3. package main
  5. import (
  6.         "context"
  7.         "fmt"
  8.         "time"
  10.         v1 "k8s.io/api/core/v1"
  11.         metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
  12.         "k8s.io/client-go/kubernetes"
  13.         "k8s.io/client-go/rest"
  14.         "k8s.io/client-go/tools/clientcmd"
  15. )
  17. type CustomScheduler struct {
  18.         clientset *kubernetes.Clientset
  19. }
  21. func NewCustomScheduler() (*CustomScheduler, error) {
  22.         config, err := rest.InClusterConfig()
  23.         if err != nil {
  24.                 // 如果在集群外运行，使用kubeconfig
  25.                 kubeconfig := clientcmd.NewDefaultClientConfigLoadingRules().GetDefaultFilename()
  26.                 config, err = clientcmd.BuildConfigFromFlags("", kubeconfig)
  27.                 if err != nil {
  28.                         return nil, fmt.Errorf("failed to build kubeconfig: %v", err)
  29.                 }
  30.         }
  32.         clientset, err := kubernetes.NewForConfig(config)
  33.         if err != nil {
  34.                 return nil, fmt.Errorf("failed to create clientset: %v", err)
  35.         }
  37.         return &CustomScheduler{
  38.                 clientset: clientset,
  39.         }, nil
  40. }
  42. func (s *CustomScheduler) Run() {
  43.         for {
  44.                 // 获取未调度的Pod
  45.                 pods, err := s.getUnscheduledPods()
  46.                 if err != nil {
  47.                         fmt.Printf("Error getting unscheduled pods: %v\n", err)
  48.                         time.Sleep(10 * time.Second)
  49.                         continue
  50.                 }
  52.                 // 为每个Pod选择节点
  53.                 for _, pod := range pods {
  54.                         node, err := s.selectNodeForPod(pod)
  55.                         if err != nil {
  56.                                 fmt.Printf("Error selecting node for pod %s: %v\n", pod.Name, err)
  57.                                 continue
  58.                         }
  60.                         // 绑定Pod到节点
  61.                         if err := s.bindPodToNode(pod, node); err != nil {
  62.                                 fmt.Printf("Error binding pod %s to node %s: %v\n", pod.Name, node.Name, err)
  63.                                 continue
  64.                         }
  66.                         fmt.Printf("Successfully scheduled pod %s to node %s\n", pod.Name, node.Name)
  67.                 }
  69.                 time.Sleep(10 * time.Second)
  70.         }
  71. }
  73. func (s *CustomScheduler) getUnscheduledPods() ([]*v1.Pod, error) {
  74.         podList, err := s.clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{
  75.                 FieldSelector: "spec.nodeName=",
  76.         })
  77.         if err != nil {
  78.                 return nil, err
  79.         }
  81.         var unscheduledPods []*v1.Pod
  82.         for i := range podList.Items {
  83.                 unscheduledPods = append(unscheduledPods, &podList.Items[i])
  84.         }
  86.         return unscheduledPods, nil
  87. }
  89. func (s *CustomScheduler) selectNodeForPod(pod *v1.Pod) (*v1.Node, error) {
  90.         // 获取所有节点
  91.         nodeList, err := s.clientset.CoreV1().Nodes().List(context.TODO(), metav1.ListOptions{})
  92.         if err != nil {
  93.                 return nil, err
  94.         }
  96.         // 简单的节点选择逻辑：选择第一个有足够资源的节点
  97.         for i := range nodeList.Items {
  98.                 node := &nodeList.Items[i]
  99.                 if s.nodeHasEnoughResources(node, pod) {
  100.                         return node, nil
  101.                 }
  102.         }
  104.         return nil, fmt.Errorf("no suitable node found for pod %s", pod.Name)
  105. }
  107. func (s *CustomScheduler) nodeHasEnoughResources(node *v1.Node, pod *v1.Pod) bool {
  108.         // 简单的资源检查逻辑
  109.         allocatable := node.Status.Allocatable
  110.         for _, container := range pod.Spec.Containers {
  111.                 resources := container.Resources.Requests
  112.                 cpu := resources.Cpu()
  113.                 memory := resources.Memory()
  115.                 if cpu != nil && allocatable.Cpu().Cmp(*cpu) < 0 {
  116.                         return false
  117.                 }
  119.                 if memory != nil && allocatable.Memory().Cmp(*memory) < 0 {
  120.                         return false
  121.                 }
  122.         }
  124.         return true
  125. }
  127. func (s *CustomScheduler) bindPodToNode(pod *v1.Pod, node *v1.Node) error {
  128.         binding := &v1.Binding{
  129.                 ObjectMeta: metav1.ObjectMeta{Name: pod.Name, UID: pod.UID},
  130.                 Target:     v1.ObjectReference{Kind: "Node", Name: node.Name},
  131.         }
  133.         return s.clientset.CoreV1().Pods(pod.Namespace).Bind(context.TODO(), binding, metav1.CreateOptions{})
  134. }
  136. func main() {
  137.         scheduler, err := NewCustomScheduler()
  138.         if err != nil {
  139.                 fmt.Printf("Error creating custom scheduler: %v\n", err)
  140.                 return
  141.         }
  143.         fmt.Println("Starting custom scheduler...")
  144.         scheduler.Run()
  145. }
复制代码

多调度器支持

Kubernetes支持在集群中运行多个调度器，每个Pod可以指定使用哪个调度器。这允许用户为不同的工作负载使用不同的调度策略。
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5.   name: my-pod
  6. spec:
  7.   schedulerName: my-custom-scheduler
  8.   containers:
  9.   - name: my-container
  10.     image: myimage:latest
复制代码

实践案例

案例1：高可用应用的跨区域部署

假设我们需要部署一个高可用的Web应用，要求Pod分布在不同的可用区，以提高容错能力。
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5.   name: web-app
  6. spec:
  7.   replicas: 6
  8.   selector:
  9.     matchLabels:
  10.       app: web-app
  11.   template:
  12.     metadata:
  13.       labels:
  14.         app: web-app
  15.     spec:
  16.       # 使用拓扑分布约束确保Pod分布在不同的可用区
  17.       topologySpreadConstraints:
  18.       - maxSkew: 1
  19.         topologyKey: topology.kubernetes.io/zone
  20.         whenUnsatisfiable: DoNotSchedule
  21.         labelSelector:
  22.           matchLabels:
  23.             app: web-app
  24.       # 使用Pod反亲和性避免同一应用的Pod集中
  25.       affinity:
  26.         podAntiAffinity:
  27.           preferredDuringSchedulingIgnoredDuringExecution:
  28.           - weight: 100
  29.             podAffinityTerm:
  30.               labelSelector:
  31.                 matchExpressions:
  32.                 - key: app
  33.                   operator: In
  34.                   values:
  35.                   - web-app
  36.               topologyKey: kubernetes.io/hostname
  37.       containers:
  38.       - name: web-app
  39.         image: webapp:latest
  40.         resources:
  41.           requests:
  42.             cpu: "500m"
  43.             memory: "512Mi"
  44.           limits:
  45.             cpu: "1000m"
  46.             memory: "1Gi"
  47.         ports:
  48.         - containerPort: 8080
复制代码

案例2：混合工作负载的资源隔离

假设我们有一个集群同时运行批处理任务和在线服务，需要确保批处理任务不会影响在线服务的性能。
  2. # 首先，为批处理节点添加污点
  3. kubectl taint nodes node-batch1 workload=batch:NoSchedule
  4. kubectl taint nodes node-batch2 workload=batch:NoSchedule
  6. # 在线服务部署
  7. apiVersion: apps/v1
  8. kind: Deployment
  9. metadata:
  10.   name: online-service
  11. spec:
  12.   replicas: 3
  13.   selector:
  14.     matchLabels:
  15.       app: online-service
  16.   template:
  17.     metadata:
  18.       labels:
  19.         app: online-service
  20.     spec:
  21.       # 使用节点亲和性确保在线服务调度到非批处理节点
  22.       affinity:
  23.         nodeAffinity:
  24.           requiredDuringSchedulingIgnoredDuringExecution:
  25.             nodeSelectorTerms:
  26.             - matchExpressions:
  27.               - key: workload
  28.                 operator: NotIn
  29.                 values:
  30.                 - batch
  31.       containers:
  32.       - name: online-service
  33.         image: online-service:latest
  34.         resources:
  35.           requests:
  36.             cpu: "500m"
  37.             memory: "512Mi"
  38.           limits:
  39.             cpu: "1000m"
  40.             memory: "1Gi"
  41.         ports:
  42.         - containerPort: 8080
  44. # 批处理任务部署
  45. apiVersion: batch/v1
  46. kind: Job
  47. metadata:
  48.   name: batch-job
  49. spec:
  50.   template:
  51.     spec:
  52.       # 使用容忍使批处理任务能够调度到批处理节点
  53.       tolerations:
  54.       - key: workload
  55.         operator: Equal
  56.         value: batch
  57.         effect: NoSchedule
  58.       containers:
  59.       - name: batch-job
  60.         image: batch-job:latest
  61.         resources:
  62.           requests:
  63.             cpu: "1000m"
  64.             memory: "2Gi"
  65.           limits:
  66.             cpu: "2000m"
  67.             memory: "4Gi"
  68.       restartPolicy: OnFailure
复制代码

案例3：GPU资源调度优化

假设我们有一个机器学习训练任务，需要使用GPU资源，并且希望优化GPU利用率。
  2. # 首先，为GPU节点添加标签
  3. kubectl label nodes node-gpu1 accelerator=gpu
  4. kubectl label nodes node-gpu2 accelerator=gpu
  6. # GPU资源监控和共享配置
  7. apiVersion: v1
  8. kind: ConfigMap
  9. metadata:
  10.   name: gpu-sharing-config
  11.   namespace: kube-system
  12. data:
  13.   gpu-sharing-config.yaml: |
  14.     apiVersion: v1
  15.     kind: ConfigMap
  16.     metadata:
  17.       name: gpu-sharing-config
  18.       namespace: kube-system
  19.     data:
  20.       gpu-sharing-config.yaml: |
  21.         version: v1
  22.         flags:
  23.           migStrategy: none
  24.           failOnInitError: true
  25.           nvidiaDriverRoot: "/"
  26.           plugin:
  27.             passDeviceSpecs: true
  28.             deviceListStrategy: envvar
  29.             deviceIDStrategy: uuid
  31. # GPU设备插件DaemonSet
  32. apiVersion: apps/v1
  33. kind: DaemonSet
  34. metadata:
  35.   name: nvidia-device-plugin-daemonset
  36.   namespace: kube-system
  37. spec:
  38.   selector:
  39.     matchLabels:
  40.       name: nvidia-device-plugin-ds
  41.   template:
  42.     metadata:
  43.       labels:
  44.         name: nvidia-device-plugin-ds
  45.     spec:
  46.       tolerations:
  47.       - key: "nvidia.com/gpu"
  48.         operator: "Exists"
  49.         effect: "NoSchedule"
  50.       containers:
  51.       - image: nvcr.io/nvidia/k8s-device-plugin:v0.9.0
  52.         name: nvidia-device-plugin-ctr
  53.         env:
  54.           - name: FAIL_ON_INIT_ERROR
  55.             value: "true"
  56.         securityContext:
  57.           allowPrivilegeEscalation: false
  58.           capabilities:
  59.             drop: ["ALL"]
  60.         volumeMounts:
  61.           - name: device-plugin
  62.             mountPath: /var/lib/kubelet/device-plugins
  63.       volumes:
  64.         - name: device-plugin
  65.           hostPath:
  66.             path: /var/lib/kubelet/device-plugins
  68. # 机器学习训练任务
  69. apiVersion: batch/v1
  70. kind: Job
  71. metadata:
  72.   name: ml-training-job
  73. spec:
  74.   template:
  75.     spec:
  76.       # 使用节点亲和性确保任务调度到GPU节点
  77.       affinity:
  78.         nodeAffinity:
  79.           requiredDuringSchedulingIgnoredDuringExecution:
  80.             nodeSelectorTerms:
  81.             - matchExpressions:
  82.               - key: accelerator
  83.                 operator: In
  84.                 values:
  85.                 - gpu
  86.       containers:
  87.       - name: ml-training
  88.         image: ml-training:latest
  89.         resources:
  90.           limits:
  91.             nvidia.com/gpu: 1  # 请求1个GPU
  92.           requests:
  93.             cpu: "2000m"
  94.             memory: "8Gi"
  95.       restartPolicy: OnFailure
复制代码

性能监控与调优

调度性能监控

监控调度器的性能对于确保集群高效运行至关重要。以下是一些关键的监控指标和工具：

1. 调度延迟：从Pod创建到Pod被调度的时间间隔。可以通过以下Prometheus查询获取：
  2. histogram_quantile(0.99, sum(rate(scheduler_e2e_scheduling_duration_seconds_bucket[5m])) by (le))
复制代码

1. 调度尝试次数：调度器为Pod尝试调度的次数。高尝试次数可能表明资源紧张或调度策略过于严格。
  2. sum(rate(scheduler_scheduling_attempt_total[5m])) by (result)
复制代码

1. 队列深度：待调度Pod队列的长度，反映调度器的负载情况。
  2. kube_scheduler_pending_pods
复制代码

1. 调度器事件：通过Kubernetes事件监控调度相关的活动。
  2. kubectl get events --field-selector involvedObject.kind=Pod -A
复制代码

调度器性能调优

1. 调整调度器并发度：通过增加调度器的并发度可以提高调度吞吐量，但可能会增加CPU使用。
  2. apiVersion: kubescheduler.config.k8s.io/v1beta2
  3. kind: KubeSchedulerConfiguration
  4. parallelism: 16
复制代码

1. 优化调度算法：禁用不必要的调度插件或调整插件权重，以提高调度效率。
  2. apiVersion: kubescheduler.config.k8s.io/v1beta2
  3. kind: KubeSchedulerConfiguration
  4. profiles:
  5. - schedulerName: default-scheduler
  6.   plugins:
  7.     score:
  8.       disabled:
  9.       - name: NodeResourcesBalancedAllocation
  10.       enabled:
  11.       - name: NodeResourcesMostAllocated
  12.         weight: 5
  13.       - name: NodeResourcesLeastAllocated
  14.         weight: 2
复制代码

1. 使用调度器缓存：启用调度器缓存可以减少API Server的访问次数，提高调度性能。
  2. apiVersion: kubescheduler.config.k8s.io/v1beta2
  3. kind: KubeSchedulerConfiguration
  4. percentageOfNodesToScore: 50
复制代码

1. 节点健康检查调优：调整节点健康检查的频率和超时时间，以平衡资源利用率和故障检测速度。
  2. apiVersion: kubeadm.k8s.io/v1beta2
  3. kind: ClusterConfiguration
  4. controllerManager:
  5.   extraArgs:
  6.     node-monitor-period: "5s"
  7.     node-monitor-grace-period: "40s"
  8.     pod-eviction-timeout: "2m0s"
复制代码

集群资源利用率优化

1. 资源使用情况监控：使用Prometheus和Grafana监控集群资源利用率，识别资源浪费和瓶颈。
  2. # CPU利用率
  3. sum(rate(container_cpu_usage_seconds_total{container!="", container!="POD"}[5m])) by (node) / sum(machine_cpu_cores) by (node)
  5. # 内存利用率
  6. sum(container_memory_working_set_bytes{container!="", container!="POD"}) by (node) / sum(machine_memory_bytes) by (node)
复制代码

1. 资源回收策略：设置适当的Pod回收策略，确保在资源紧张时优先回收非关键Pod。
  2. apiVersion: policy/v1beta1
  3. kind: PodDisruptionBudget
  4. metadata:
  5.   name: app-pdb
  6. spec:
  7.   minAvailable: 2
  8.   selector:
  9.     matchLabels:
  10.       app: my-app
复制代码

1. 集群自动伸缩：配置集群自动伸缩器（Cluster Autoscaler）和水平Pod自动伸缩器（HPA），根据负载情况动态调整资源。
  2. # HPA配置示例
  3. apiVersion: autoscaling/v2beta2
  4. kind: HorizontalPodAutoscaler
  5. metadata:
  6.   name: my-app-hpa
  7. spec:
  8.   scaleTargetRef:
  9.     apiVersion: apps/v1
  10.     kind: Deployment
  11.     name: my-app
  12.   minReplicas: 2
  13.   maxReplicas: 10
  14.   metrics:
  15.   - type: Resource
  16.     resource:
  17.       name: cpu
  18.       target:
  19.         type: Utilization
  20.         averageUtilization: 50
复制代码

最佳实践和注意事项

调度策略最佳实践

1. 明确资源需求：为所有Pod设置适当的资源请求和限制，避免资源饥饿或浪费。
2. 使用命名空间隔离：通过命名空间和资源配额实现多租户资源隔离，防止单个应用占用过多资源。
3. 合理使用亲和性和反亲和性：避免过度使用严格的亲和性和反亲和性规则，以免导致Pod无法调度。
4. 优先级管理：为关键Pod设置高优先级，确保在资源紧张时优先调度。
5. 避免单点故障：通过拓扑分布约束、Pod反亲和性等机制，确保应用组件分布在不同的节点或可用区。

明确资源需求：为所有Pod设置适当的资源请求和限制，避免资源饥饿或浪费。

使用命名空间隔离：通过命名空间和资源配额实现多租户资源隔离，防止单个应用占用过多资源。

合理使用亲和性和反亲和性：避免过度使用严格的亲和性和反亲和性规则，以免导致Pod无法调度。

优先级管理：为关键Pod设置高优先级，确保在资源紧张时优先调度。

避免单点故障：通过拓扑分布约束、Pod反亲和性等机制，确保应用组件分布在不同的节点或可用区。

常见问题及解决方案

1. Pod无法调度（Pending状态）检查资源请求是否过高，节点是否有足够资源检查节点选择器、亲和性/反亲和性规则是否过于严格检查污点和容忍设置是否匹配使用kubectl describe pod <pod-name>查看详细错误信息
2. 检查资源请求是否过高，节点是否有足够资源
3. 检查节点选择器、亲和性/反亲和性规则是否过于严格
4. 检查污点和容忍设置是否匹配
5. 使用kubectl describe pod <pod-name>查看详细错误信息
6. 节点资源利用率不均衡使用节点亲和性将Pod分散到不同节点考虑使用Descheduler定期重新平衡集群调整调度器的打分策略，如启用NodeResourcesMostAllocated插件
7. 使用节点亲和性将Pod分散到不同节点
8. 考虑使用Descheduler定期重新平衡集群
9. 调整调度器的打分策略，如启用NodeResourcesMostAllocated插件
10. 关键Pod被驱逐为关键Pod设置适当的优先级确保关键Pod的资源请求合理，避免资源争用考虑使用PodDisruptionBudget保护关键应用
11. 为关键Pod设置适当的优先级
12. 确保关键Pod的资源请求合理，避免资源争用
13. 考虑使用PodDisruptionBudget保护关键应用
14. 调度性能问题监控调度延迟和队列深度调整调度器并发度和算法考虑使用多个调度器分担负载
15. 监控调度延迟和队列深度
16. 调整调度器并发度和算法
17. 考虑使用多个调度器分担负载

Pod无法调度（Pending状态）

• 检查资源请求是否过高，节点是否有足够资源
• 检查节点选择器、亲和性/反亲和性规则是否过于严格
• 检查污点和容忍设置是否匹配
• 使用kubectl describe pod <pod-name>查看详细错误信息

节点资源利用率不均衡

• 使用节点亲和性将Pod分散到不同节点
• 考虑使用Descheduler定期重新平衡集群
• 调整调度器的打分策略，如启用NodeResourcesMostAllocated插件

关键Pod被驱逐

• 为关键Pod设置适当的优先级
• 确保关键Pod的资源请求合理，避免资源争用
• 考虑使用PodDisruptionBudget保护关键应用

调度性能问题

• 监控调度延迟和队列深度
• 调整调度器并发度和算法
• 考虑使用多个调度器分担负载

安全考虑

1. 限制特权Pod：避免将特权Pod调度到关键节点，或在调度策略中限制特权Pod的数量。
2. 敏感工作负载隔离：将敏感工作负载调度到专用节点，并使用网络策略限制其通信。
3. 多租户安全：通过命名空间、网络策略和资源配额实现多租户环境的安全隔离。

限制特权Pod：避免将特权Pod调度到关键节点，或在调度策略中限制特权Pod的数量。

敏感工作负载隔离：将敏感工作负载调度到专用节点，并使用网络策略限制其通信。

多租户安全：通过命名空间、网络策略和资源配额实现多租户环境的安全隔离。
  2. # 网络策略示例
  3. apiVersion: networking.k8s.io/v1
  4. kind: NetworkPolicy
  5. metadata:
  6.   name: app-network-policy
  7.   namespace: dev-team
  8. spec:
  9.   podSelector:
  10.     matchLabels:
  11.       app: my-app
  12.   policyTypes:
  13.   - Ingress
  14.   - Egress
  15.   ingress:
  16.   - from:
  17.     - namespaceSelector:
  18.         matchLabels:
  19.           name: dev-team
  20.     - podSelector:
  21.         matchLabels:
  22.           app: my-app
  23.   egress:
  24.   - to:
  25.     - namespaceSelector:
  26.         matchLabels:
  27.           name: dev-team
  28.     - podSelector:
  29.         matchLabels:
  30.           app: my-app
复制代码

结论

Kubernetes的节点调度策略是优化容器集群性能和稳定性的关键因素。通过深入理解调度器的工作原理、合理配置资源请求与限制、利用亲和性/反亲和性、污点和容忍等高级特性，以及实施有效的监控和调优措施，可以显著提高集群的资源利用率和应用性能。

随着Kubernetes生态系统的发展，调度技术也在不断演进。未来，我们可以期待更智能的调度算法、更灵活的调度框架以及更精细的资源控制机制。作为Kubernetes用户和管理者，我们需要持续关注这些发展，并将最佳实践应用到实际环境中，以确保容器集群的高效、稳定运行。

通过本文的介绍，希望读者能够全面理解Kubernetes节点调度策略，并能够根据实际需求设计、实施和优化调度方案，从而充分发挥Kubernetes的潜力，提升容器集群的整体性能与稳定性。
回复

使用道具 举报

返回列表 发新帖
您需要登录后才可以回帖 登录 | 立即注册
高级模式
B Color Image Link Quote Code Smilies

本版积分规则

友情链接

keba
磕巴白菜
别管 别听 就是玩
二次元论坛
二次元论坛
按下F逃离世界！
次元宅社
次元宅社
开放、共创，CHANGE SEKAI！
频道订阅

频道订阅

加入社群

加入社群

联系我们|TG频道|RSS

Powered by Pixtech

© 2025 Pixtech Team.