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

威震华夏关云长

引言

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的潜力，提升容器集群的整体性能与稳定性。

版权声明

1、转载或引用本网站内容(K8s节点调度策略详解从原理到实践掌握资源分配优化技巧提升容器集群整体性能与稳定性)须注明原网址及作者(威震华夏关云长)，并标明本网站网址(https://www.pixtech.cc/)。

2、对于不当转载或引用本网站内容而引起的民事纷争、行政处理或其他损失，本网站不承担责任。

3、对不遵守本声明或其他违法、恶意使用本网站内容者，本网站保留追究其法律责任的权利。

本文地址: https://www.pixtech.cc/thread-36816-1-1.html