全面揭秘Kubernetes调度器工作原理与优化技巧从资源感知到智能调度掌握容器编排核心提升集群效率构建稳定云原生环境

威震华夏关云长

1. Kubernetes调度器概述

Kubernetes作为当今最流行的容器编排平台，其调度器(Scheduler)是整个系统的核心组件之一。调度器负责将新创建的Pod分配到集群中的合适节点上运行，这一过程看似简单，实则涉及复杂的决策逻辑和资源管理策略。在云原生环境中，调度器的效率和智能程度直接影响整个集群的资源利用率、应用性能和系统稳定性。

Kubernetes调度器的主要职责是监视新创建尚未分配节点的Pod，并根据一系列规则和策略为它们选择最合适的运行节点。这一过程需要考虑多方面因素，包括资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰以及截止时间等。

调度器在Kubernetes架构中扮演着至关重要的角色。它作为控制平面的核心组件，与API Server、etcd、Controller Manager和kubelet等其他组件紧密协作，共同维持集群的正常运行。一个高效、智能的调度器能够显著提升集群资源利用率，降低运营成本，并确保应用性能和可靠性。

2. 调度器工作原理详解

Kubernetes调度器的工作流程可以概括为两个主要阶段：过滤(Filtering)和打分(Scoring)。让我们深入了解这两个阶段的具体实现。

2.1 调度流程概述

调度器的工作流程如下：

1. 监视Pod：调度器持续监视Kubernetes API Server，查找尚未分配节点的Pod（即spec.nodeName为空的Pod）。
2. 过滤阶段：对于每个待调度的Pod，调度器会遍历集群中的所有节点，通过一系列谓词(Predicates)规则筛选出满足Pod基本运行需求的节点。
3. 打分阶段：对过滤阶段筛选出的节点，调度器会应用一系列优先级(Priorities)规则进行打分，选出最适合运行该Pod的节点。
4. 绑定阶段：调度器将Pod与选定的节点进行绑定，更新Pod的spec.nodeName字段，然后kubelet会负责在目标节点上创建并运行Pod。

2.2 过滤阶段详解

过滤阶段是调度决策的第一步，其目的是快速排除那些明显不适合运行Pod的节点。Kubernetes提供了一系列内置的谓词规则，包括：

• PodFitsResources：检查节点是否有足够的CPU、内存等资源满足Pod的需求。
• PodFitsHostPorts：检查Pod请求的端口是否已被节点上的其他Pod占用。
• PodMatchNodeSelector：检查节点的标签是否匹配Pod的nodeSelector。
• NoVolumeZoneConflict：检查Pod请求的卷是否在节点所在的可用区。
• CheckNodeMemoryPressure：检查节点是否处于内存压力状态。
• CheckNodeDiskPressure：检查节点是否处于磁盘压力状态。
• MatchInterPodAffinity：检查Pod是否满足与其他Pod的亲和性/反亲和性规则。

让我们通过一个示例来了解过滤阶段的具体实现：

2. // 伪代码示例：过滤阶段实现
3. func (g *GenericScheduler) Schedule(pod *v1.Pod, nodeLister algorithm.NodeLister) (result ScheduleResult, err error) {
4.     // 获取所有节点
5.     nodes, err := nodeLister.List()
6.     if err != nil {
7.         return result, err
8.     }
9.    
10.     // 过滤阶段：应用谓词规则
11.     filteredNodes, failedPredicateMap, err := g.findNodesThatFit(pod, nodes)
12.     if err != nil {
13.         return result, err
14.     }
15.    
16.     // 如果没有节点满足条件，返回错误
17.     if len(filteredNodes) == 0 {
18.         return result, &FitError{
19.             Pod:              pod,
20.             NumAllNodes:      len(nodes),
21.             FailedPredicates: failedPredicateMap,
22.         }
23.     }
24.    
25.     // 打分阶段：应用优先级规则
26.     priorityList, err := g.prioritizeNodes(pod, filteredNodes)
27.     if err != nil {
28.         return result, err
29.     }
30.    
31.     // 选择得分最高的节点
32.     host, err := g.selectHost(priorityList)
33.     if err != nil {
34.         return result, err
35.     }
36.    
37.     return ScheduleResult{
38.         SuggestedHost:  host,
39.         EvaluatedNodes: len(filteredNodes),
40.         FeasibleNodes:  len(filteredNodes),
41.     }, nil
42. }

复制代码

2.3 打分阶段详解

打分阶段是调度决策的第二步，其目的是从满足基本条件的节点中选出最优节点。每个优先级规则会为节点打分，最终得分是所有规则得分的加权和。Kubernetes提供了一系列内置的优先级规则，包括：

• LeastRequestedPriority：优先选择资源请求量较少的节点，以平衡资源使用。
• BalancedResourceAllocation：优先选择CPU和内存资源使用更均衡的节点。
• NodeAffinityPriority：优先选择与Pod的节点亲和性规则匹配度更高的节点。
• TaintTolerationPriority：优先选择与Pod的容忍规则匹配度更高的节点。
• InterPodAffinityPriority：优先选择与其他Pod的亲和性规则匹配度更高的节点。
• NodePreferAvoidPodsPriority：优先选择那些没有标记要避免Pod的节点。
• ImageLocalityPriority：优先选择已经存在Pod所需容器镜像的节点。

以下是一个打分阶段的示例实现：

2. // 伪代码示例：打分阶段实现
3. func (g *GenericScheduler) prioritizeNodes(pod *v1.Pod, nodes []*v1.Node) (schedulerapi.HostPriorityList, error) {
4.     // 初始化节点得分列表
5.     result := make(schedulerapi.HostPriorityList, 0, len(nodes))
6.    
7.     // 并行计算每个节点在每个优先级规则下的得分
8.     for _, node := range nodes {
9.         // 计算节点在所有优先级规则下的总得分
10.         score := 0
11.         for _, priorityConfig := range g.prioritizers {
12.             // 调用优先级函数计算得分
13.             nodeScore, err := priorityConfig.Function(pod, node)
14.             if err != nil {
15.                 return nil, err
16.             }
17.             // 加权求和
18.             score += nodeScore * priorityConfig.Weight
19.         }
20.         
21.         result = append(result, schedulerapi.HostPriority{
22.             Host:  node.Name,
23.             Score: score,
24.         })
25.     }
26.    
27.     return result, nil
28. }

复制代码

2.4 绑定阶段详解

绑定阶段是调度决策的最后一步，调度器将Pod与选定的节点进行绑定。这个过程包括：

1. 更新Pod的spec.nodeName字段为选定的节点名称。
2. 将更新后的Pod对象写入etcd。
3. 目标节点上的kubelet监视到分配给自己的Pod后，负责创建并运行该Pod。

绑定阶段的示例代码如下：

2. // 伪代码示例：绑定阶段实现
3. func (b *Binder) Bind(binding *v1.Binding) error {
4.     // 创建绑定请求
5.     err := b.Client.CoreV1().Pods(binding.Namespace).Bind(binding)
6.     if err != nil {
7.         return err
8.     }
9.     return nil
10. }
12. // 调度器调用绑定
13. func (sched *Scheduler) bind(binding *v1.Binding) error {
14.     // 尝试绑定
15.     err := sched.Binder.Bind(binding)
16.     if err != nil {
17.         // 绑定失败，记录错误并重试
18.         return err
19.     }
20.    
21.     // 绑定成功，记录事件
22.     sched.Recorder.Eventf(&v1.Pod{
23.         ObjectMeta: metav1.ObjectMeta{
24.             Name:      binding.Name,
25.             Namespace: binding.Namespace,
26.         },
27.     }, v1.EventTypeNormal, "Scheduled", "Successfully assigned %v/%v to %v", binding.Namespace, binding.Name, binding.Target.Name)
28.    
29.     return nil
30. }

复制代码

3. 资源感知机制

Kubernetes调度器的资源感知机制是其核心功能之一，它使调度器能够根据节点的资源状况做出智能决策。本节将深入探讨调度器如何感知、评估和利用集群资源。

3.1 资源模型

Kubernetes使用两种主要的资源度量方式：请求(Request)和限制(Limit)。

• 请求(Request)：Pod需要的最小资源量，用于调度决策和节点资源分配。
• 限制(Limit)：Pod可以使用的最大资源量，用于运行时资源限制。

调度器主要关注资源请求量，因为它决定了Pod能否在节点上运行。节点的可分配资源(Allocatable)是其总资源容量减去系统预留资源后的值，调度器会确保节点上所有Pod的资源请求总和不超过节点的可分配资源。

以下是一个资源模型的示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: resource-pod
6. spec:
7.   containers:
8.   - name: resource-container
9.     image: nginx
10.     resources:
11.       requests:
12.         cpu: "500m"      # 0.5 CPU核心
13.         memory: "512Mi"  # 512 MiB内存
14.       limits:
15.         cpu: "1000m"     # 1 CPU核心
16.         memory: "1Gi"    # 1 GiB内存

复制代码

3.2 资源监控与报告

Kubernetes通过kubelet组件收集节点资源使用情况，并定期向API Server报告。调度器利用这些信息了解节点的资源状况，做出合理的调度决策。

kubelet通过cAdvisor(Container Advisor)收集容器资源使用数据，包括CPU、内存、磁盘和网络等。这些数据通过节点状态(NodeStatus)更新到API Server，调度器可以访问这些信息进行调度决策。

以下是节点资源状态的示例：

2. apiVersion: v1
3. kind: Node
4. metadata:
5.   name: node-1
6. status:
7.   capacity:
8.     cpu: "4"
9.     memory: 16Gi
10.     pods: "110"
11.   allocatable:
12.     cpu: "3900m"
13.     memory: 15Gi
14.     pods: "110"
15.   conditions:
16.   - type: MemoryPressure
17.     status: "False"
18.   - type: DiskPressure
19.     status: "False"
20.   - type: PIDPressure
21.     status: "False"
22.   - type: Ready
23.     status: "True"

复制代码

3.3 资源感知调度策略

Kubernetes调度器提供了多种资源感知的调度策略，帮助优化集群资源利用率。

正确设置Pod的资源请求和限制是资源感知调度的基础。请求值用于调度决策，确保节点有足够资源运行Pod；限制值用于运行时资源控制，防止Pod消耗过多资源影响其他应用。

以下是一个资源请求与限制的最佳实践示例：

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: resource-aware-deployment
6. spec:
7.   replicas: 3
8.   selector:
9.     matchLabels:
10.       app: resource-aware
11.   template:
12.     metadata:
13.       labels:
14.         app: resource-aware
15.     spec:
16.       containers:
17.       - name: app
18.         image: myapp:1.0
19.         resources:
20.           requests:
21.             cpu: "500m"
22.             memory: "512Mi"
23.           limits:
24.             cpu: "1000m"
25.             memory: "1Gi"
26.       - name: sidecar
27.         image: sidecar:1.0
28.         resources:
29.           requests:
30.             cpu: "200m"
31.             memory: "256Mi"
32.           limits:
33.             cpu: "500m"
34.             memory: "512Mi"

复制代码

Kubernetes提供了资源配额(ResourceQuota)和限制范围(LimitRange)两种机制，帮助管理员控制命名空间的资源使用。

• 资源配额：限制命名空间中可以创建的对象数量以及计算资源总量。
• 限制范围：为命名空间中的Pod或容器设置默认资源请求和限制，以及最小/最大资源限制。

以下是一个资源配额和限制范围的示例：

2. # 资源配额示例
3. apiVersion: v1
4. kind: ResourceQuota
5. metadata:
6.   name: compute-resources
7.   namespace: dev-namespace
8. spec:
9.   hard:
10.     requests.cpu: "4"
11.     requests.memory: 8Gi
12.     limits.cpu: "8"
13.     limits.memory: 16Gi
14.     pods: "10"
16. # 限制范围示例
17. apiVersion: v1
18. kind: LimitRange
19. metadata:
20.   name: resource-limits
21.   namespace: dev-namespace
22. spec:
23.   limits:
24.   - default:
25.       cpu: "500m"
26.       memory: "512Mi"
27.     defaultRequest:
28.       cpu: "250m"
29.       memory: "256Mi"
30.     max:
31.       cpu: "2000m"
32.       memory: "2Gi"
33.     min:
34.       cpu: "100m"
35.       memory: "128Mi"
36.     type: Container

复制代码

Kubernetes允许配置资源过量使用(Overcommitment)，即节点上所有Pod的资源请求总和可以超过节点的可分配资源。这种策略可以提高资源利用率，但也增加了资源耗尽的风险。

资源过量使用通过kubelet的--kube-reserved和--system-reserved参数配置，它们分别指定为Kubernetes系统和系统进程预留的资源。

以下是一个kubelet资源配置示例：

2. kubelet --kube-reserved=cpu=500m,memory=1Gi --system-reserved=cpu=200m,memory=500Mi

复制代码

3.4 扩展资源与设备插件

除了CPU和内存等标准资源，Kubernetes还支持扩展资源(Extended Resources)，如GPU、FPGA、高性能网卡等。这些资源通过设备插件(Device Plugin)机制集成到Kubernetes中。

设备插件负责：

1. 发现节点上的特定硬件设备。
2. 将这些设备作为扩展资源广告给Kubelet。
3. 监控设备健康状况。
4. 在Pod需要时分配设备。

以下是一个使用GPU资源的Pod示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: gpu-pod
6. spec:
7.   containers:
8.   - name: cuda-container
9.     image: nvidia/cuda:10.0-base
10.     resources:
11.       limits:
12.         nvidia.com/gpu: 2  # 请求2个GPU

复制代码

4. 智能调度策略

Kubernetes提供了多种智能调度策略，使调度器能够根据业务需求和应用特性做出更精细的调度决策。这些策略包括节点亲和性、Pod亲和性/反亲和性、污点和容忍等。

4.1 节点亲和性调度

节点亲和性(Node Affinity)允许Pod根据节点标签选择性地调度到特定节点上。它分为两种类型：requiredDuringSchedulingIgnoredDuringExecution(硬性要求)和preferredDuringSchedulingIgnoredDuringExecution(软性偏好)。

硬性节点亲和性规则必须满足，否则Pod不会被调度到节点上。它使用nodeSelector的扩展形式，提供更丰富的匹配语法。

以下是一个硬性节点亲和性的示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: affinity-pod
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.   containers:
18.   - name: nginx
19.     image: nginx

复制代码

软性节点亲和性规则是偏好而非强制要求，调度器会尝试满足这些规则，但在无法满足时仍会调度Pod。

以下是一个软性节点亲和性的示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: affinity-pod
6. spec:
7.   affinity:
8.     nodeAffinity:
9.       preferredDuringSchedulingIgnoredDuringExecution:
10.       - weight: 1  # 权重，范围1-100
11.         preference:
12.           matchExpressions:
13.           - key: another-node-label-key
14.             operator: In
15.             values:
16.             - another-node-label-value
17.   containers:
18.   - name: nginx
19.     image: nginx

复制代码

4.2 Pod亲和性与反亲和性调度

Pod亲和性(Pod Affinity)和反亲和性(Pod Anti-Affinity)允许Pod根据其他Pod的标签选择性地调度到特定节点上。这种策略对于需要部署在一起或分开的应用非常有用。

Pod亲和性确保Pod被调度到与具有特定标签的Pod相同的节点上。它同样分为硬性要求和软性偏好两种类型。

以下是一个Pod亲和性的示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: pod-affinity-pod
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.   containers:
18.   - name: nginx
19.     image: nginx

复制代码

Pod反亲和性确保Pod不被调度到与具有特定标签的Pod相同的节点上。这对于避免单点故障和提高应用可用性非常重要。

以下是一个Pod反亲和性的示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: pod-antiaffinity-pod
6. spec:
7.   affinity:
8.     podAntiAffinity:
9.       requiredDuringSchedulingIgnoredDuringExecution:
10.       - labelSelector:
11.           matchExpressions:
12.           - key: app
13.             operator: In
14.             values:
15.             - web-frontend
16.         topologyKey: kubernetes.io/hostname
17.   containers:
18.   - name: nginx
19.     image: nginx

复制代码

4.3 污点与容忍调度

污点(Taints)和容忍(Tolerations)是另一种控制Pod调度的机制。污点应用于节点，表示节点不能接受某些Pod；容忍应用于Pod，表示Pod可以容忍具有特定污点的节点。

节点污点由键、值和效果组成。效果可以是NoSchedule、PreferNoSchedule或NoExecute。

以下是为节点添加污点的示例：

2. kubectl taint nodes node1 key=value:NoSchedule

复制代码

Pod可以通过容忍来接受具有特定污点的节点。容忍必须与污点的键、值和效果匹配。

以下是一个Pod容忍的示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: toleration-pod
6. spec:
7.   tolerations:
8.   - key: "key"
9.     operator: "Equal"
10.     value: "value"
11.     effect: "NoSchedule"
12.   containers:
13.   - name: nginx
14.     image: nginx

复制代码

4.4 自定义调度器

除了默认调度器，Kubernetes还允许用户开发自定义调度器，满足特定业务需求。自定义调度器可以与默认调度器并行运行，或者完全替代默认调度器。

自定义调度器通常作为独立的进程运行，通过监视Kubernetes API Server获取待调度Pod和节点信息，然后应用自定义调度逻辑，最后将Pod绑定到选定节点。

以下是一个简单的自定义调度器框架：

2. package main
4. import (
5.     "flag"
6.     "fmt"
7.     "time"
9.     corev1 "k8s.io/api/core/v1"
10.     "k8s.io/apimachinery/pkg/labels"
11.     "k8s.io/client-go/informers"
12.     "k8s.io/client-go/kubernetes"
13.     "k8s.io/client-go/tools/cache"
14.     "k8s.io/client-go/tools/clientcmd"
15.     "k8s.io/klog/v2"
16. )
18. type CustomScheduler struct {
19.     clientset     kubernetes.Interface
20.     podInformer    cache.SharedIndexInformer
21.     nodeInformer   cache.SharedIndexInformer
22.     unscheduledPods chan *corev1.Pod
23. }
25. func NewCustomScheduler(clientset kubernetes.Interface) *CustomScheduler {
26.     factory := informers.NewSharedInformerFactory(clientset, 30*time.Second)
27.    
28.     podInformer := factory.Core().V1().Pods().Informer()
29.     nodeInformer := factory.Core().V1().Nodes().Informer()
30.    
31.     scheduler := &CustomScheduler{
32.         clientset:     clientset,
33.         podInformer:    podInformer,
34.         nodeInformer:   nodeInformer,
35.         unscheduledPods: make(chan *corev1.Pod, 100),
36.     }
37.    
38.     // 设置Pod事件处理器
39.     podInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{
40.         AddFunc: func(obj interface{}) {
41.             pod := obj.(*corev1.Pod)
42.             if pod.Spec.NodeName == "" && pod.Status.Phase == corev1.PodPending {
43.                 scheduler.unscheduledPods <- pod
44.             }
45.         },
46.         UpdateFunc: func(oldObj, newObj interface{}) {
47.             oldPod := oldObj.(*corev1.Pod)
48.             newPod := newObj.(*corev1.Pod)
49.             if oldPod.Spec.NodeName == "" && newPod.Spec.NodeName == "" && newPod.Status.Phase == corev1.PodPending {
50.                 scheduler.unscheduledPods <- newPod
51.             }
52.         },
53.     })
54.    
55.     return scheduler
56. }
58. func (s *CustomScheduler) Run(stopCh <-chan struct{}) {
59.     // 启动informer
60.     go s.podInformer.Run(stopCh)
61.     go s.nodeInformer.Run(stopCh)
62.    
63.     // 等待缓存同步
64.     if !cache.WaitForCacheSync(stopCh, s.podInformer.HasSynced, s.nodeInformer.HasSynced) {
65.         klog.Error("Timed out waiting for caches to sync")
66.         return
67.     }
68.    
69.     // 开始调度循环
70.     for {
71.         select {
72.         case pod := <-s.unscheduledPods:
73.             s.Schedule(pod)
74.         case <-stopCh:
75.             return
76.         }
77.     }
78. }
80. func (s *CustomScheduler) Schedule(pod *corev1.Pod) {
81.     // 获取所有节点
82.     nodes, err := s.nodeInformer.GetIndexer().ByIndex(cache.NamespaceIndex, "")
83.     if err != nil {
84.         klog.Errorf("Failed to get nodes: %v", err)
85.         return
86.     }
87.    
88.     // 自定义调度逻辑
89.     selectedNode := s.selectNode(pod, nodes)
90.     if selectedNode == nil {
91.         klog.Infof("No available node for pod %s/%s", pod.Namespace, pod.Name)
92.         return
93.     }
94.    
95.     // 绑定Pod到节点
96.     binding := &corev1.Binding{
97.         ObjectMeta: metav1.ObjectMeta{Name: pod.Name, UID: pod.UID},
98.         Target:     corev1.ObjectReference{Kind: "Node", Name: selectedNode.Name},
99.     }
100.    
101.     err = s.clientset.CoreV1().Pods(pod.Namespace).Bind(binding)
102.     if err != nil {
103.         klog.Errorf("Failed to bind pod %s/%s to node %s: %v", pod.Namespace, pod.Name, selectedNode.Name, err)
104.         return
105.     }
106.    
107.     klog.Infof("Successfully bound pod %s/%s to node %s", pod.Namespace, pod.Name, selectedNode.Name)
108. }
110. func (s *CustomScheduler) selectNode(pod *corev1.Pod, nodes []interface{}) *corev1.Node {
111.     // 这里实现自定义的节点选择逻辑
112.     // 可以基于资源、标签、亲和性等因素进行选择
113.    
114.     for _, nodeObj := range nodes {
115.         node := nodeObj.(*corev1.Node)
116.         
117.         // 检查节点是否可调度
118.         if !isNodeSchedulable(node) {
119.             continue
120.         }
121.         
122.         // 检查节点是否有足够资源
123.         if !nodeHasEnoughResources(node, pod) {
124.             continue
125.         }
126.         
127.         // 检查节点是否匹配Pod的节点选择器
128.         if !nodeMatchesSelector(node, pod) {
129.             continue
130.         }
131.         
132.         // 如果所有检查都通过，选择该节点
133.         return node
134.     }
135.    
136.     return nil
137. }
139. func isNodeSchedulable(node *corev1.Node) bool {
140.     return !node.Spec.Unschedulable
141. }
143. func nodeHasEnoughResources(node *corev1.Node, pod *corev1.Pod) bool {
144.     // 实现资源检查逻辑
145.     return true
146. }
148. func nodeMatchesSelector(node *corev1.Node, pod *corev1.Pod) bool {
149.     // 实现节点选择器匹配逻辑
150.     return true
151. }
153. func main() {
154.     var kubeconfig string
155.     var masterURL string
156.    
157.     flag.StringVar(&kubeconfig, "kubeconfig", "", "Path to a kubeconfig. Only required if out-of-cluster.")
158.     flag.StringVar(&masterURL, "master", "", "The address of the Kubernetes API server. Overrides any value in kubeconfig. Only required if out-of-cluster.")
159.     flag.Parse()
160.    
161.     // 创建Kubernetes客户端
162.     config, err := clientcmd.BuildConfigFromFlags(masterURL, kubeconfig)
163.     if err != nil {
164.         klog.Fatalf("Error building kubeconfig: %v", err)
165.     }
166.    
167.     clientset, err := kubernetes.NewForConfig(config)
168.     if err != nil {
169.         klog.Fatalf("Error building kubernetes clientset: %v", err)
170.     }
171.    
172.     // 创建并运行自定义调度器
173.     scheduler := NewCustomScheduler(clientset)
174.    
175.     stopCh := make(chan struct{})
176.     defer close(stopCh)
177.    
178.     go scheduler.Run(stopCh)
179.    
180.     // 等待终止信号
181.     select {}
182. }

复制代码

要在Pod中使用自定义调度器，需要在Pod规范中指定调度器名称：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: custom-scheduler-pod
6. spec:
7.   schedulerName: my-custom-scheduler
8.   containers:
9.   - name: nginx
10.     image: nginx

复制代码

4.5 多调度器协同工作

Kubernetes支持多个调度器同时工作，每个调度器可以负责调度特定的Pod。这种模式允许集群管理员根据不同的业务需求使用不同的调度策略。

要配置多调度器，需要：

1. 部署自定义调度器。
2. 在Pod中指定使用哪个调度器。

以下是一个部署自定义调度器的示例：

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: custom-scheduler
6. spec:
7.   replicas: 1
8.   selector:
9.     matchLabels:
10.       app: custom-scheduler
11.   template:
12.     metadata:
13.       labels:
14.         app: custom-scheduler
15.     spec:
16.       serviceAccountName: custom-scheduler
17.       containers:
18.       - name: custom-scheduler
19.         image: my-custom-scheduler:1.0
20.         imagePullPolicy: Always
21.         command:
22.         - /bin/custom-scheduler
23.         - --kubeconfig=/etc/kubernetes/scheduler.conf
24.         - --v=3
25.         volumeMounts:
26.         - name: kubeconfig
27.           mountPath: /etc/kubernetes
28.           readOnly: true
29.       volumes:
30.       - name: kubeconfig
31.         secret:
32.           secretName: custom-scheduler-kubeconfig

复制代码

为Pod指定调度器只需在Pod规范中设置schedulerName字段：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: custom-scheduled-pod
6. spec:
7.   schedulerName: custom-scheduler
8.   containers:
9.   - name: nginx
10.     image: nginx

复制代码

5. 调度器优化技巧

优化Kubernetes调度器可以显著提高集群资源利用率、应用性能和系统稳定性。本节将介绍一系列实用的调度器优化技巧。

5.1 资源分配优化

合理的资源分配是调度优化的基础。通过优化资源请求和限制，可以提高集群资源利用率，同时确保应用性能。

准确设置Pod的资源请求和限制是优化调度的第一步。资源请求过低可能导致节点资源过载，影响应用性能；资源请求过高则会导致资源浪费。

以下是一些设置资源请求和限制的最佳实践：

1. 基于监控数据设置资源：使用应用的历史监控数据确定合理的资源请求和限制。
2. 使用垂直Pod自动伸缩(VPA)：VPA可以根据实际资源使用情况自动调整Pod的资源请求和限制。
3. 为不同环境设置不同资源：开发、测试和生产环境可以使用不同的资源配置。

以下是一个基于VPA的资源配置示例：

2. apiVersion: autoscaling.k8s.io/v1
3. kind: VerticalPodAutoscaler
4. metadata:
5.   name: my-app-vpa
6. spec:
7.   targetRef:
8.     apiVersion: "apps/v1"
9.     kind:       Deployment
10.     name:       my-app
11.   updatePolicy:
12.     updateMode: "Auto"

复制代码

资源配额和限制范围可以帮助控制命名空间的资源使用，防止单个应用或团队占用过多资源。

以下是一个资源配额和限制范围的组合示例：

2. # 资源配额
3. apiVersion: v1
4. kind: ResourceQuota
5. metadata:
6.   name: compute-resources
7.   namespace: dev-namespace
8. spec:
9.   hard:
10.     requests.cpu: "10"
11.     requests.memory: 20Gi
12.     limits.cpu: "20"
13.     limits.memory: 40Gi
14.     pods: "50"
15.     persistentvolumeclaims: "10"
17. # 限制范围
18. apiVersion: v1
19. kind: LimitRange
20. metadata:
21.   name: resource-limits
22.   namespace: dev-namespace
23. spec:
24.   limits:
25.   - default:
26.       cpu: "500m"
27.       memory: "512Mi"
28.     defaultRequest:
29.       cpu: "250m"
30.       memory: "256Mi"
31.     max:
32.       cpu: "2000m"
33.       memory: "2Gi"
34.     min:
35.       cpu: "100m"
36.       memory: "128Mi"
37.     type: Container

复制代码

资源过量使用可以提高资源利用率，但也增加了资源耗尽的风险。以下是一些优化资源过量使用的技巧：

1. 合理设置kubelet预留资源：为Kubernetes系统和系统进程预留足够资源。
2. 使用Pod优先级和抢占：确保关键Pod在资源不足时能够获得资源。
3. 监控资源使用情况：密切监控节点资源使用情况，避免资源耗尽。

以下是一个kubelet资源配置示例：

2. kubelet --kube-reserved=cpu=500m,memory=1Gi,ephemeral-storage=1Gi \
3.         --system-reserved=cpu=200m,memory=500Mi,ephemeral-storage=1Gi \
4.         --eviction-hard=memory.available<500Mi,nodefs.available<10%

复制代码

5.2 调度性能调优

调度性能直接影响Pod的启动速度和集群的响应能力。通过优化调度器性能，可以提高集群的整体效率。

Kubernetes调度器支持并发调度多个Pod，通过调整并发度可以提高调度性能。

以下是一个调度器配置文件示例，展示了如何调整并发度：

2. apiVersion: kubescheduler.config.k8s.io/v1beta2
3. kind: KubeSchedulerConfiguration
4. parallelism: 16  # 默认为16，可根据集群规模调整

复制代码

过多的谓词和优先级规则会增加调度决策的时间。以下是一些优化技巧：

1. 禁用不必要的规则：根据集群需求禁用不必要的谓词和优先级规则。
2. 自定义规则顺序：将计算成本高但过滤效果好的规则放在前面。
3. 使用自定义调度器：对于特定场景，开发专用的高效调度器。

以下是一个自定义调度器配置示例，展示了如何选择特定的谓词和优先级规则：

2. apiVersion: kubescheduler.config.k8s.io/v1beta2
3. kind: KubeSchedulerConfiguration
4. profiles:
5. - schedulerName: default-scheduler
6.   plugins:
7.     filter:
8.       enabled:
9.       - name: NodeUnschedulable
10.       - name: NodeResourcesFit
11.       - name: NodePorts
12.       - name: VolumeBinding
13.     score:
14.       enabled:
15.       - name: NodeResourcesBalancedAllocation
16.       - name: NodeResourcesLeastAllocated
17.       - name: ImageLocality

复制代码

Kubernetes调度器使用缓存来存储节点和Pod信息，减少API Server的访问次数。优化缓存配置可以提高调度性能。

以下是一些缓存优化技巧：

1. 增加缓存大小：对于大型集群，增加缓存大小可以提高性能。
2. 调整缓存过期时间：根据集群变化频率调整缓存过期时间。
3. 使用分布式缓存：对于多调度器部署，考虑使用分布式缓存。

以下是一个调度器缓存配置示例：

2. apiVersion: kubescheduler.config.k8s.io/v1beta2
3. kind: KubeSchedulerConfiguration
4. percentageOfNodesToScore: 50  # 默认为50，表示只对50%的节点进行打分

复制代码

5.3 避免调度热点

调度热点是指某些节点被过度分配资源，而其他节点资源利用率较低的情况。避免调度热点可以提高集群资源利用率和应用性能。

Pod反亲和性可以确保应用实例分布在不同的节点上，避免单点过载。

以下是一个使用Pod反亲和性避免热点的示例：

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: web-frontend
6. spec:
7.   replicas: 5
8.   selector:
9.     matchLabels:
10.       app: web-frontend
11.   template:
12.     metadata:
13.       labels:
14.         app: web-frontend
15.     spec:
16.       affinity:
17.         podAntiAffinity:
18.           requiredDuringSchedulingIgnoredDuringExecution:
19.           - labelSelector:
20.               matchExpressions:
21.               - key: app
22.                 operator: In
23.                 values:
24.                 - web-frontend
25.             topologyKey: kubernetes.io/hostname
26.       containers:
27.       - name: web
28.         image: nginx
29.         resources:
30.           requests:
31.             cpu: "500m"
32.             memory: "512Mi"
33.           limits:
34.             cpu: "1000m"
35.             memory: "1Gi"

复制代码

在多可用区部署中，使用区域感知调度可以确保应用实例均匀分布在各个可用区，提高可用性。

以下是一个使用节点亲和性实现区域感知调度的示例：

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: zone-aware-app
6. spec:
7.   replicas: 6
8.   selector:
9.     matchLabels:
10.       app: zone-aware
11.   template:
12.     metadata:
13.       labels:
14.         app: zone-aware
15.     spec:
16.       affinity:
17.         nodeAffinity:
18.           requiredDuringSchedulingIgnoredDuringExecution:
19.             nodeSelectorTerms:
20.             - matchExpressions:
21.               - key: topology.kubernetes.io/zone
22.                 operator: In
23.                 values:
24.                 - us-east-1a
25.                 - us-east-1b
26.                 - us-east-1c
27.       containers:
28.       - name: app
29.         image: myapp:1.0
30.         resources:
31.           requests:
32.             cpu: "500m"
33.             memory: "512Mi"
34.           limits:
35.             cpu: "1000m"
36.             memory: "1Gi"

复制代码

Kubernetes Descheduler是一个用于重新平衡集群资源的工具，它可以识别并重新调度那些可能导致不均衡的Pod。

以下是一个Descheduler配置示例：

2. apiVersion: policy/v1
3. kind: PodDisruptionBudget
4. metadata:
5.   name: descheduler-pdb
6. spec:
7.   selector:
8.     matchLabels:
9.       app: descheduler
10.   maxUnavailable: 1
11. ---
12. apiVersion: apps/v1
13. kind: Deployment
14. metadata:
15.   name: descheduler
16.   namespace: kube-system
17. spec:
18.   replicas: 1
19.   selector:
20.     matchLabels:
21.       app: descheduler
22.   template:
23.     metadata:
24.       labels:
25.         app: descheduler
26.     spec:
27.       serviceAccountName: descheduler-sa
28.       containers:
29.       - name: descheduler
30.         image: k8s.gcr.io/descheduler/descheduler:v0.21.0
31.         imagePullPolicy: Always
32.         command:
33.         - "/bin/descheduler"
34.         args:
35.         - "--policy-config-file=/policy-dir/policy.yaml"
36.         - "--v=3"
37.         volumeMounts:
38.         - mountPath: /policy-dir
39.           name: policy-volume
40.       volumes:
41.       - name: policy-volume
42.         configMap:
43.           name: descheduler-policy
44. ---
45. apiVersion: v1
46. kind: ConfigMap
47. metadata:
48.   name: descheduler-policy
49.   namespace: kube-system
50. data:
51.   policy.yaml: |
52.     apiVersion: "descheduler/v1alpha1"
53.     kind: "DeschedulerPolicy"
54.     strategies:
55.       "RemoveDuplicates":
56.         enabled: true
57.       "RemovePodsViolatingInterPodAntiAffinity":
58.         enabled: true
59.       "LowNodeUtilization":
60.         enabled: true
61.         params:
62.           nodeResourceUtilizationThresholds:
63.             thresholds:
64.               "cpu" : 20
65.               "memory": 20
66.               "pods": 20
67.             targetThresholds:
68.               "cpu" : 50
69.               "memory": 50
70.               "pods": 50

复制代码

5.4 高级调度优化

除了基本的调度优化技巧，还有一些高级优化策略可以进一步提高调度效率。

Kubernetes调度器支持通过Webhook扩展调度功能，允许在调度决策过程中调用外部服务。

以下是一个调度器扩展的示例：

2. apiVersion: kubescheduler.config.k8s.io/v1beta2
3. kind: KubeSchedulerConfiguration
4. profiles:
5. - schedulerName: default-scheduler
6.   plugins:
7.     filter:
8.       enabled:
9.       - name: NodeResourcesFit
10.       - name: MyCustomFilter
11.     score:
12.       enabled:
13.       - name: NodeResourcesBalancedAllocation
14.       - name: MyCustomScore
15.   pluginConfig:
16.   - name: MyCustomFilter
17.     args:
18.       favoriteColor: blue
19.       favoriteNumber: 7
20.   - name: MyCustomScore
21.     args:
22.       favoriteAnimal: dog
23.       favoriteFood: pizza

复制代码

Kubernetes调度框架(Scheduling Framework)是一组插件API，允许开发自定义调度插件，扩展调度器功能。

以下是一个自定义调度插件的示例：

2. package main
4. import (
5.     "context"
6.     "fmt"
7.     "time"
9.     "k8s.io/api/core/v1"
10.     "k8s.io/apimachinery/pkg/runtime"
11.     "k8s.io/klog/v2"
12.     "k8s.io/kubernetes/pkg/scheduler/framework"
13.     "k8s.io/kubernetes/pkg/scheduler/framework/plugins/defaultbinder"
14.     "k8s.io/kubernetes/pkg/scheduler/framework/plugins/queuesort"
15. )
17. const (
18.     Name = "custom-plugin"
19. )
21. type CustomPlugin struct {
22.     handle framework.Handle
23. }
25. var _ framework.FilterPlugin = &CustomPlugin{}
26. var _ framework.ScorePlugin = &CustomPlugin{}
28. func (cp *CustomPlugin) Name() string {
29.     return Name
30. }
32. func (cp *CustomPlugin) Filter(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status {
33.     // 实现过滤逻辑
34.     node := nodeInfo.Node()
35.     if node.Labels["custom-label"] != "enabled" {
36.         return framework.NewStatus(framework.Unschedulable, "Node does not have custom-label=enabled")
37.     }
38.     return nil
39. }
41. func (cp *CustomPlugin) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) {
42.     // 实现打分逻辑
43.     nodeInfo, err := cp.handle.SnapshotSharedLister().NodeInfos().Get(nodeName)
44.     if err != nil {
45.         return 0, framework.AsStatus(err)
46.     }
47.    
48.     node := nodeInfo.Node()
49.     score := int64(0)
50.    
51.     // 根据节点标签计算得分
52.     if node.Labels["priority"] == "high" {
53.         score = 100
54.     } else if node.Labels["priority"] == "medium" {
55.         score = 50
56.     } else {
57.         score = 10
58.     }
59.    
60.     return score, nil
61. }
63. func (cp *CustomPlugin) ScoreExtensions() framework.ScoreExtensions {
64.     return cp
65. }
67. func (cp *CustomPlugin) NormalizeScore(ctx context.Context, state *framework.CycleState, pod *v1.Pod, scores framework.NodeScoreList) *framework.Status {
68.     // 实现得分归一化逻辑
69.     var highest int64 = 0
70.     for _, nodeScore := range scores {
71.         if nodeScore.Score > highest {
72.             highest = nodeScore.Score
73.         }
74.     }
75.    
76.     if highest == 0 {
77.         return nil
78.     }
79.    
80.     for i, nodeScore := range scores {
81.         scores[i].Score = nodeScore.Score * framework.MaxNodeScore / highest
82.     }
83.    
84.     return nil
85. }
87. type CustomArgs struct {
88.     FavoriteColor  string `json:"favoriteColor,omitempty"`
89.     FavoriteNumber int    `json:"favoriteNumber,omitempty"`
90. }
92. func New(_ runtime.Object, handle framework.Handle) (framework.Plugin, error) {
93.     return &CustomPlugin{handle: handle}, nil
94. }
96. func main() {
97.     // 这里是插件注册逻辑，通常在scheduler初始化时调用
98.     // scheme := runtime.NewScheme()
99.     // utilruntime.Must(scheme.AddUnversionedTypes(corev1.SchemeGroupVersion, &CustomArgs{}))
100.     // framework.Register(Name, func(_ runtime.Object, handle framework.Handle) (framework.Plugin, error) {
101.     //     return New(nil, handle)
102.     // })
103.    
104.     // 在实际使用中，插件会被编译成独立的二进制文件，并通过--plugins参数加载
105.     fmt.Println("Custom plugin compiled successfully")
106. }

复制代码

对于批量任务，使用批处理调度器如Volcano可以提高资源利用率和任务完成速度。

以下是一个Volcano作业的示例：

2. apiVersion: batch.volcano.sh/v1alpha1
3. kind: Job
4. metadata:
5.   name: test-job
6. spec:
7.   minAvailable: 3
8.   schedulerName: volcano
9.   priorityClassName: high-priority
10.   policies:
11.     - event: PodEvicted
12.       action: RestartJob
13.   plugins:
14.     ssh: []
15.     env: []
16.     svc: []
17.   maxRetry: 5
18.   queue: default
19.   tasks:
20.     - replicas: 3
21.       name: "default-nginx"
22.       template:
23.         metadata:
24.           name: web
25.         spec:
26.           containers:
27.             - image: nginx
28.               imagePullPolicy: IfNotPresent
29.               name: nginx
30.               resources:
31.                 requests:
32.                   cpu: "1"
33.                   memory: "1Gi"
34.           restartPolicy: OnFailure

复制代码

6. 实际案例分析

通过实际案例，我们可以更好地理解Kubernetes调度器的工作原理和优化技巧的应用。本节将介绍几个典型的调度优化案例。

6.1 大规模微服务集群调度优化

某互联网公司拥有一个包含数千个微服务的Kubernetes集群，面临资源利用率低、Pod启动慢、节点负载不均等问题。通过一系列调度优化，他们显著提高了集群效率和稳定性。

通过监控数据分析，团队发现以下问题：

1. 资源请求设置不合理：许多Pod的资源请求远高于实际使用量，导致节点资源利用率低。
2. 调度热点：某些节点负载过高，而其他节点资源闲置。
3. Pod启动慢：由于调度决策复杂，Pod启动时间过长。
4. 关键应用受干扰：关键应用与批处理任务混部，导致性能不稳定。

针对上述问题，团队实施了以下优化措施：

1. 资源请求优化：使用VPA自动调整Pod资源请求和限制。为不同类型的应用设置不同的资源请求策略。
2. 使用VPA自动调整Pod资源请求和限制。
3. 为不同类型的应用设置不同的资源请求策略。

• 使用VPA自动调整Pod资源请求和限制。
• 为不同类型的应用设置不同的资源请求策略。

2. apiVersion: autoscaling.k8s.io/v1
3.    kind: VerticalPodAutoscaler
4.    metadata:
5.      name: web-app-vpa
6.    spec:
7.      targetRef:
8.        apiVersion: "apps/v1"
9.        kind:       Deployment
10.        name:       web-app
11.      updatePolicy:
12.        updateMode: "Auto"
13.      resourcePolicy:
14.        containerPolicies:
15.        - containerName: "*"
16.          minAllowed:
17.            cpu: "100m"
18.            memory: "128Mi"
19.          maxAllowed:
20.            cpu: "2000m"
21.            memory: "2Gi"

复制代码

1. 避免调度热点：使用Pod反亲和性确保应用实例分布在不同节点。使用Descheduler定期重新平衡集群资源。
2. 使用Pod反亲和性确保应用实例分布在不同节点。
3. 使用Descheduler定期重新平衡集群资源。

• 使用Pod反亲和性确保应用实例分布在不同节点。
• 使用Descheduler定期重新平衡集群资源。

2. apiVersion: apps/v1
3.    kind: Deployment
4.    metadata:
5.      name: web-app
6.    spec:
7.      replicas: 10
8.      template:
9.        spec:
10.          affinity:
11.            podAntiAffinity:
12.              requiredDuringSchedulingIgnoredDuringExecution:
13.              - labelSelector:
14.                  matchExpressions:
15.                  - key: app
16.                    operator: In
17.                    values:
18.                    - web-app
19.                topologyKey: kubernetes.io/hostname

复制代码

1. 调度性能优化：增加调度器并发度。优化谓词和优先级规则。
2. 增加调度器并发度。
3. 优化谓词和优先级规则。

• 增加调度器并发度。
• 优化谓词和优先级规则。

2. apiVersion: kubescheduler.config.k8s.io/v1beta2
3.    kind: KubeSchedulerConfiguration
4.    parallelism: 32
5.    percentageOfNodesToScore: 30
6.    profiles:
7.    - schedulerName: default-scheduler
8.      plugins:
9.        filter:
10.          enabled:
11.          - name: NodeUnschedulable
12.          - name: NodeResourcesFit
13.          - name: NodePorts
14.        score:
15.          enabled:
16.          - name: NodeResourcesBalancedAllocation
17.          - name: NodeResourcesLeastAllocated

复制代码

1. 应用隔离：使用命名空间和资源配额隔离不同类型的应用。使用污点和容忍分离关键应用和批处理任务。
2. 使用命名空间和资源配额隔离不同类型的应用。
3. 使用污点和容忍分离关键应用和批处理任务。

• 使用命名空间和资源配额隔离不同类型的应用。
• 使用污点和容忍分离关键应用和批处理任务。

2. # 为批处理节点添加污点
3.    apiVersion: v1
4.    kind: Node
5.    metadata:
6.      name: batch-node-1
7.      labels:
8.        role: batch
9.    spec:
10.      taints:
11.      - key: batch
12.        value: "true"
13.        effect: NoSchedule
14.    
15.    # 批处理任务容忍污点
16.    apiVersion: batch/v1
17.    kind: Job
18.    metadata:
19.      name: batch-job
20.    spec:
21.      template:
22.        spec:
23.          tolerations:
24.          - key: batch
25.            operator: Equal
26.            value: "true"
27.            effect: NoSchedule

复制代码

通过上述优化，团队取得了显著效果：

1. 资源利用率提高：CPU利用率从30%提升到65%，内存利用率从40%提升到70%。
2. Pod启动时间缩短：平均Pod启动时间从45秒减少到15秒。
3. 节点负载均衡：节点间CPU和内存使用差异从±40%降低到±15%。
4. 应用性能稳定：关键应用响应时间波动从±200ms降低到±50ms。

6.2 多可用区高可用调度优化

某金融企业需要在多个可用区部署关键应用，确保高可用性和灾难恢复能力。他们通过优化调度策略，实现了应用在多可用区间的智能分布和故障自动转移。

企业的关键需求包括：

1. 应用实例必须分布在至少3个可用区。
2. 每个可用区至少运行一个应用实例。
3. 某个可用区故障时，应用能自动在其他可用区恢复。
4. 跨可用区网络延迟最小化。

针对上述需求，团队实施了以下解决方案：

1. 区域感知调度：使用节点亲和性确保Pod分布在多个可用区。使用Pod反亲和性避免单点故障。
2. 使用节点亲和性确保Pod分布在多个可用区。
3. 使用Pod反亲和性避免单点故障。

• 使用节点亲和性确保Pod分布在多个可用区。
• 使用Pod反亲和性避免单点故障。

2. apiVersion: apps/v1
3.    kind: Deployment
4.    metadata:
5.      name: critical-app
6.    spec:
7.      replicas: 6
8.      template:
9.        spec:
10.          affinity:
11.            nodeAffinity:
12.              requiredDuringSchedulingIgnoredDuringExecution:
13.                nodeSelectorTerms:
14.                - matchExpressions:
15.                  - key: topology.kubernetes.io/zone
16.                    operator: In
17.                    values:
18.                    - us-east-1a
19.                    - us-east-1b
20.                    - us-east-1c
21.            podAntiAffinity:
22.              requiredDuringSchedulingIgnoredDuringExecution:
23.              - labelSelector:
24.                  matchExpressions:
25.                  - key: app
26.                    operator: In
27.                    values:
28.                    - critical-app
29.                topologyKey: topology.kubernetes.io/zone
30.              preferredDuringSchedulingIgnoredDuringExecution:
31.              - weight: 100
32.                podAffinityTerm:
33.                  labelSelector:
34.                    matchExpressions:
35.                    - key: app
36.                      operator: In
37.                      values:
38.                      - critical-app
39.                  topologyKey: kubernetes.io/hostname

复制代码

1. 区域故障恢复：使用Pod Disruption Budget确保最小可用实例数。使用自定义控制器监控可用区状态，自动重新调度Pod。
2. 使用Pod Disruption Budget确保最小可用实例数。
3. 使用自定义控制器监控可用区状态，自动重新调度Pod。

• 使用Pod Disruption Budget确保最小可用实例数。
• 使用自定义控制器监控可用区状态，自动重新调度Pod。

2. apiVersion: policy/v1
3.    kind: PodDisruptionBudget
4.    metadata:
5.      name: critical-app-pdb
6.    spec:
7.      minAvailable: 3
8.      selector:
9.        matchLabels:
10.          app: critical-app

复制代码

1. 网络优化：使用拓扑感知路由优化跨可用区网络流量。使用本地存储减少跨可用区数据访问。
2. 使用拓扑感知路由优化跨可用区网络流量。
3. 使用本地存储减少跨可用区数据访问。

• 使用拓扑感知路由优化跨可用区网络流量。
• 使用本地存储减少跨可用区数据访问。

2. apiVersion: v1
3.    kind: Service
4.    metadata:
5.      name: critical-app-service
6.      annotations:
7.        service.kubernetes.io/topology-aware-hints: "auto"
8.    spec:
9.      selector:
10.        app: critical-app
11.      ports:
12.      - protocol: TCP
13.        port: 80
14.        targetPort: 8080

复制代码

通过上述优化，企业实现了以下目标：

1. 高可用性：应用实例均匀分布在3个可用区，每个可用区运行2个实例。
2. 故障恢复：模拟可用区故障时，应用在2分钟内自动恢复到其他可用区。
3. 网络性能：跨可用区网络延迟降低30%，应用响应时间提升25%。
4. 运营效率：自动化故障恢复减少了70%的人工干预。

6.3 GPU资源调度优化

某AI公司需要高效调度GPU资源，支持多种深度学习训练和推理任务。他们通过自定义调度策略，实现了GPU资源的高效利用和任务优先级管理。

公司面临的主要挑战包括：

1. GPU资源昂贵且有限，需要最大化利用率。
2. 不同任务对GPU资源的需求差异大。
3. 训练任务通常需要长时间独占GPU，而推理任务可以共享GPU。
4. 关键任务需要优先获得GPU资源。

针对上述挑战，团队实施了以下优化方案：

1. GPU资源管理：使用设备插件管理GPU资源。自定义GPU资源分配策略。
2. 使用设备插件管理GPU资源。
3. 自定义GPU资源分配策略。

• 使用设备插件管理GPU资源。
• 自定义GPU资源分配策略。

2. # GPU设备插件配置
3.    apiVersion: v1
4.    kind: DaemonSet
5.    metadata:
6.      name: nvidia-device-plugin-daemonset
7.      namespace: kube-system
8.    spec:
9.      template:
10.        spec:
11.          containers:
12.          - image: nvcr.io/nvidia/k8s-device-plugin:v0.8.0
13.            name: nvidia-device-plugin-ctr
14.            env:
15.              - name: FAIL_ON_INIT_ERROR
16.                value: "false"
17.            volumeMounts:
18.              - name: device-plugin
19.                mountPath: /var/lib/kubelet/device-plugins
20.          volumes:
21.            - name: device-plugin
22.              hostPath:
23.                path: /var/lib/kubelet/device-plugins

复制代码

1. 自定义调度器：开发专门的GPU调度器，支持GPU共享和抢占。实现任务优先级和资源预留机制。
2. 开发专门的GPU调度器，支持GPU共享和抢占。
3. 实现任务优先级和资源预留机制。

• 开发专门的GPU调度器，支持GPU共享和抢占。
• 实现任务优先级和资源预留机制。

2. // 自定义GPU调度器伪代码
3.    type GPUScheduler struct {
4.      // 调度器状态
5.      gpuNodes []*GPUNode
6.      pendingQueue []*Task
7.      runningTasks map[string]*Task
8.      priorityClasses map[string]int
9.    }
10.    
11.    func (s *GPUScheduler) Schedule() {
12.      // 按优先级排序待调度任务
13.      sort.Slice(s.pendingQueue, func(i, j int) bool {
14.        return s.priorityClasses[s.pendingQueue[i].PriorityClass] >
15.               s.priorityClasses[s.pendingQueue[j].PriorityClass]
16.      })
17.      
18.      // 尝试调度每个任务
19.      for _, task := range s.pendingQueue {
20.        for _, node := range s.gpuNodes {
21.          if s.canSchedule(task, node) {
22.            s.assignTask(task, node)
23.            break
24.          }
25.        }
26.      }
27.    }
28.    
29.    func (s *GPUScheduler) canSchedule(task *Task, node *GPUNode) bool {
30.      // 检查节点是否有足够的GPU资源
31.      if task.RequiresExclusiveGPU && node.AvailableExclusiveGPUs == 0 {
32.        return false
33.      }
34.      
35.      if !task.RequiresExclusiveGPU && node.AvailableSharedGPUMemory < task.RequiredGPUMemory {
36.        return false
37.      }
38.      
39.      // 检查节点是否满足其他约束
40.      if !node.Labels.Match(task.NodeSelector) {
41.        return false
42.      }
43.      
44.      return true
45.    }
46.    
47.    func (s *GPUScheduler) assignTask(task *Task, node *GPUNode) {
48.      // 分配GPU资源
49.      if task.RequiresExclusiveGPU {
50.        node.AvailableExclusiveGPUs--
51.        task.AssignedGPUs = []string{node.AllocateExclusiveGPU()}
52.      } else {
53.        allocatedMemory := task.RequiredGPUMemory
54.        task.AssignedGPUs = node.AllocateSharedGPU(allocatedMemory)
55.        node.AvailableSharedGPUMemory -= allocatedMemory
56.      }
57.      
58.      // 更新任务状态
59.      task.Status = "Running"
60.      task.Node = node.Name
61.      s.runningTasks[task.ID] = task
62.      
63.      // 从待调度队列中移除
64.      for i, t := range s.pendingQueue {
65.        if t.ID == task.ID {
66.          s.pendingQueue = append(s.pendingQueue[:i], s.pendingQueue[i+1:]...)
67.          break
68.        }
69.      }
70.      
71.      // 创建Pod
72.      s.createPod(task)
73.    }

复制代码

1. 任务优先级管理：使用Pod优先级和抢占机制。实现任务排队和超时处理。
2. 使用Pod优先级和抢占机制。
3. 实现任务排队和超时处理。

• 使用Pod优先级和抢占机制。
• 实现任务排队和超时处理。

2. # 优先级类定义
3.    apiVersion: scheduling.k8s.io/v1
4.    kind: PriorityClass
5.    metadata:
6.      name: high-priority
7.    value: 1000000
8.    globalDefault: false
9.    description: "This priority class should be used for critical GPU training jobs only."
10.    ---
11.    apiVersion: scheduling.k8s.io/v1
12.    kind: PriorityClass
13.    metadata:
14.      name: medium-priority
15.    value: 500000
16.    globalDefault: false
17.    description: "This priority class should be used for regular GPU training jobs."
18.    ---
19.    apiVersion: scheduling.k8s.io/v1
20.    kind: PriorityClass
21.    metadata:
22.      name: low-priority
23.    value: 100000
24.    globalDefault: true
25.    description: "This priority class should be used for GPU inference jobs."
26.    
27.    # 使用优先级类的Pod
28.    apiVersion: v1
29.    kind: Pod
30.    metadata:
31.      name: high-priority-gpu-job
32.    spec:
33.      priorityClassName: high-priority
34.      containers:
35.      - name: gpu-container
36.        image: tensorflow/tensorflow:latest-gpu
37.        resources:
38.          limits:
39.            nvidia.com/gpu: 2

复制代码

通过上述优化，公司取得了显著效果：

1. GPU利用率提升：从60%提升到90%，支持更多并发任务。
2. 任务完成时间缩短：高优先级任务平均等待时间从30分钟减少到5分钟。
3. 资源成本降低：通过GPU共享和智能调度，节省了30%的GPU资源成本。
4. 运营效率提升：自动化调度减少了80%的人工干预。

7. 构建稳定云原生环境的最佳实践

通过优化Kubernetes调度器，我们可以构建更加稳定、高效的云原生环境。本节将总结一些构建稳定云原生环境的最佳实践。

7.1 资源管理最佳实践

有效的资源管理是构建稳定云原生环境的基础。以下是一些资源管理的最佳实践：

为所有容器设置资源请求和限制，确保调度器能够做出合理的决策，防止资源耗尽。

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: resource-managed-app
6. spec:
7.   template:
8.     spec:
9.       containers:
10.       - name: app
11.         image: myapp:1.0
12.         resources:
13.           requests:
14.             cpu: "500m"
15.             memory: "512Mi"
16.           limits:
17.             cpu: "1000m"
18.             memory: "1Gi"

复制代码

在命名空间级别使用资源配额和限制范围，防止单个应用或团队占用过多资源。

2. # 资源配额
3. apiVersion: v1
4. kind: ResourceQuota
5. metadata:
6.   name: namespace-quota
7. spec:
8.   hard:
9.     requests.cpu: "10"
10.     requests.memory: "20Gi"
11.     limits.cpu: "20"
12.     limits.memory: "40Gi"
13.     pods: "50"
15. # 限制范围
16. apiVersion: v1
17. kind: LimitRange
18. metadata:
19.   name: container-limits
20. spec:
21.   limits:
22.   - default:
23.       cpu: "500m"
24.       memory: "512Mi"
25.     defaultRequest:
26.       cpu: "250m"
27.       memory: "256Mi"
28.     type: Container

复制代码

使用资源监控和自动伸缩机制，确保应用能够根据负载动态调整资源使用。

2. # 水平Pod自动伸缩(HPA)
3. apiVersion: autoscaling/v2
4. kind: HorizontalPodAutoscaler
5. metadata:
6.   name: app-hpa
7. spec:
8.   scaleTargetRef:
9.     apiVersion: apps/v1
10.     kind: Deployment
11.     name: 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
21.   - type: Resource
22.     resource:
23.       name: memory
24.       target:
25.         type: Utilization
26.         averageUtilization: 70
28. # 垂直Pod自动伸缩(VPA)
29. apiVersion: autoscaling.k8s.io/v1
30. kind: VerticalPodAutoscaler
31. metadata:
32.   name: app-vpa
33. spec:
34.   targetRef:
35.     apiVersion: "apps/v1"
36.     kind:       Deployment
37.     name:       app
38.   updatePolicy:
39.     updateMode: "Auto"

复制代码

7.2 调度策略最佳实践

合理的调度策略可以提高资源利用率，确保应用性能和稳定性。以下是一些调度策略的最佳实践：

使用节点和Pod的亲和性、反亲和性规则，控制Pod的分布，提高应用可用性和性能。

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: distributed-app
6. spec:
7.   template:
8.     spec:
9.       affinity:
10.         # 节点亲和性：选择特定类型的节点
11.         nodeAffinity:
12.           requiredDuringSchedulingIgnoredDuringExecution:
13.             nodeSelectorTerms:
14.             - matchExpressions:
15.               - key: node-role.kubernetes.io/worker
16.                 operator: In
17.                 values:
18.                 - "true"
19.         
20.         # Pod反亲和性：避免Pod集中在同一节点
21.         podAntiAffinity:
22.           requiredDuringSchedulingIgnoredDuringExecution:
23.           - labelSelector:
24.               matchExpressions:
25.               - key: app
26.                 operator: In
27.                 values:
28.                 - distributed-app
29.             topologyKey: kubernetes.io/hostname
30.         
31.         # Pod亲和性：将相关应用部署在一起
32.         podAffinity:
33.           preferredDuringSchedulingIgnoredDuringExecution:
34.           - weight: 100
35.             podAffinityTerm:
36.               labelSelector:
37.                 matchExpressions:
38.                 - key: app
39.                   operator: In
40.                   values:
41.                   - cache-service
42.               topologyKey: kubernetes.io/hostname

复制代码

使用污点和容忍机制隔离不同类型的工作负载，确保关键应用不受干扰。

2. # 为关键节点添加污点
3. apiVersion: v1
4. kind: Node
5. metadata:
6.   name: critical-node-1
7. spec:
8.   taints:
9.   - key: workload-type
10.     value: critical
11.     effect: NoSchedule
13. # 关键应用容忍污点
14. apiVersion: apps/v1
15. kind: Deployment
16. metadata:
17.   name: critical-app
18. spec:
19.   template:
20.     spec:
21.       tolerations:
22.       - key: workload-type
23.         operator: Equal
24.         value: critical
25.         effect: NoSchedule
26.       containers:
27.       - name: app
28.         image: critical-app:1.0

复制代码

对于有特殊调度需求的应用，使用自定义调度器实现更精细的调度控制。

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: custom-scheduled-pod
6. spec:
7.   schedulerName: custom-scheduler
8.   containers:
9.   - name: app
10.     image: special-app:1.0

复制代码

7.3 高可用性和容灾最佳实践

构建高可用、容灾能力强的云原生环境是确保业务连续性的关键。以下是一些高可用性和容灾的最佳实践：

将应用部署在多个可用区，确保单个可用区故障时应用仍能正常运行。

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: multi-az-app
6. spec:
7.   replicas: 6
8.   template:
9.     spec:
10.       affinity:
11.         nodeAffinity:
12.           requiredDuringSchedulingIgnoredDuringExecution:
13.             nodeSelectorTerms:
14.             - matchExpressions:
15.               - key: topology.kubernetes.io/zone
16.                 operator: In
17.                 values:
18.                 - us-east-1a
19.                 - us-east-1b
20.                 - us-east-1c
21.         podAntiAffinity:
22.           requiredDuringSchedulingIgnoredDuringExecution:
23.           - labelSelector:
24.               matchExpressions:
25.               - key: app
26.                 operator: In
27.                 values:
28.                 - multi-az-app
29.             topologyKey: topology.kubernetes.io/zone

复制代码

使用Pod中断预算(PDB)确保在维护或故障期间始终有足够的应用实例运行。

2. apiVersion: policy/v1
3. kind: PodDisruptionBudget
4. metadata:
5.   name: app-pdb
6. spec:
7.   minAvailable: 2
8.   selector:
9.     matchLabels:
10.       app: multi-az-app

复制代码

为应用配置适当的健康检查，确保不健康的容器能够自动重启或替换。

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: health-checked-app
6. spec:
7.   template:
8.     spec:
9.       containers:
10.       - name: app
11.         image: health-checked-app:1.0
12.         livenessProbe:
13.           httpGet:
14.             path: /health
15.             port: 8080
16.           initialDelaySeconds: 30
17.           periodSeconds: 10
18.           timeoutSeconds: 5
19.           failureThreshold: 3
20.         readinessProbe:
21.           httpGet:
22.             path: /ready
23.             port: 8080
24.           initialDelaySeconds: 5
25.           periodSeconds: 5
26.           timeoutSeconds: 3
27.           failureThreshold: 1

复制代码

7.4 安全性最佳实践

确保云原生环境的安全性是保护应用和数据的关键。以下是一些安全性的最佳实践：

使用Pod安全策略(Pod Security Policy)限制Pod的安全配置，防止不安全的设置。

2. apiVersion: policy/v1beta1
3. kind: PodSecurityPolicy
4. metadata:
5.   name: restricted-psp
6. spec:
7.   privileged: false
8.   allowPrivilegeEscalation: false
9.   requiredDropCapabilities:
10.     - ALL
11.   volumes:
12.     - 'configMap'
13.     - 'emptyDir'
14.     - 'projected'
15.     - 'secret'
16.     - 'downwardAPI'
17.     - 'persistentVolumeClaim'
18.   runAsUser:
19.     rule: 'MustRunAsNonRoot'
20.   seLinux:
21.     rule: 'RunAsAny'
22.   fsGroup:
23.     rule: 'RunAsAny'

复制代码

使用网络策略(Network Policy)控制Pod之间的网络通信，防止未授权访问。

2. apiVersion: networking.k8s.io/v1
3. kind: NetworkPolicy
4. metadata:
5.   name: app-network-policy
6. spec:
7.   podSelector:
8.     matchLabels:
9.       app: secure-app
10.   policyTypes:
11.   - Ingress
12.   - Egress
13.   ingress:
14.   - from:
15.     - podSelector:
16.         matchLabels:
17.           app: frontend
18.     ports:
19.     - protocol: TCP
20.       port: 80
21.   egress:
22.   - to:
23.     - podSelector:
24.         matchLabels:
25.           app: database
26.     ports:
27.     - protocol: TCP
28.       port: 5432

复制代码

使用基于角色的访问控制(RBAC)限制用户和服务账户对Kubernetes资源的访问权限。

2. # 角色
3. apiVersion: rbac.authorization.k8s.io/v1
4. kind: Role
5. metadata:
6.   namespace: default
7.   name: app-operator
8. rules:
9. - apiGroups: [""]
10.   resources: ["pods", "services", "configmaps"]
11.   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
12. - apiGroups: ["apps"]
13.   resources: ["deployments", "replicasets"]
14.   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
16. # 角色绑定
17. apiVersion: rbac.authorization.k8s.io/v1
18. kind: RoleBinding
19. metadata:
20.   name: app-operator-binding
21.   namespace: default
22. subjects:
23. - kind: ServiceAccount
24.   name: app-operator-sa
25.   namespace: default
26. roleRef:
27.   kind: Role
28.   name: app-operator
29.   apiGroup: rbac.authorization.k8s.io

复制代码

7.5 监控和日志最佳实践

有效的监控和日志系统是确保云原生环境稳定运行的关键。以下是一些监控和日志的最佳实践：

使用Prometheus、Grafana等工具实施全面监控，覆盖基础设施、Kubernetes组件和应用性能。

2. # Prometheus监控配置示例
3. apiVersion: v1
4. kind: ConfigMap
5. metadata:
6.   name: prometheus-config
7. data:
8.   prometheus.yml: |
9.     global:
10.       scrape_interval: 15s
11.     scrape_configs:
12.     - job_name: 'kubernetes-apiservers'
13.       kubernetes_sd_configs:
14.       - role: endpoints
15.       scheme: https
16.       tls_config:
17.         ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
18.       bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
19.       relabel_configs:
20.       - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
21.         action: keep
22.         regex: default;kubernetes;https
23.    
24.     - job_name: 'kubernetes-nodes'
25.       kubernetes_sd_configs:
26.       - role: node
27.       scheme: https
28.       tls_config:
29.         ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
30.       bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
31.       relabel_configs:
32.       - action: labelmap
33.         regex: __meta_kubernetes_node_label_(.+)
34.       - target_label: __address__
35.         replacement: kubernetes.default.svc:443
36.       - source_labels: [__meta_kubernetes_node_name]
37.         regex: (.+)
38.         target_label: __metrics_path__
39.         replacement: /api/v1/nodes/${1}/proxy/metrics

复制代码

使用Elasticsearch、Fluentd、Kibana(EFK)或Loki等工具实施集中化日志管理，便于故障排查和分析。

2. # Fluentd日志收集配置示例
3. apiVersion: v1
4. kind: ConfigMap
5. metadata:
6.   name: fluentd-config
7. data:
8.   fluent.conf: |
9.     <source>
10.       @type tail
11.       path /var/log/containers/*app*.log
12.       pos_file /var/log/fluentd-containers.log.pos
13.       tag kubernetes.*
14.       format json
15.       time_format %Y-%m-%dT%H:%M:%S.%NZ
16.     </source>
17.    
18.     <match kubernetes.**>
19.       @type elasticsearch
20.       host elasticsearch-logging
21.       port 9200
22.       index_name fluentd
23.       type_name _doc
24.     </match>

复制代码

基于监控指标设置合理的告警规则，确保在问题发生时能够及时通知运维人员。

2. # Prometheus告警规则示例
3. apiVersion: monitoring.coreos.com/v1
4. kind: PrometheusRule
5. metadata:
6.   name: app-alert-rules
7. spec:
8.   groups:
9.   - name: app.rules
10.     rules:
11.     - alert: HighPodMemoryUsage
12.       expr: sum(container_memory_usage_bytes{container!="POD", pod=~"app-.*"}) by (pod) / sum(container_spec_memory_limit_bytes{container!="POD", pod=~"app-.*"}) by (pod) > 0.9
13.       for: 5m
14.       labels:
15.         severity: warning
16.       annotations:
17.         summary: "High memory usage of pod {{ $labels.pod }}"
18.         description: "Pod {{ $labels.pod }} memory usage is above 90% for 5 minutes."
19.    
20.     - alert: PodCrashLooping
21.       expr: rate(kube_pod_container_status_restarts_total{pod=~"app-.*"}[15m]) * 60 * 15 > 0
22.       for: 5m
23.       labels:
24.         severity: critical
25.       annotations:
26.         summary: "Pod {{ $labels.pod }} is crash looping."
27.         description: "Pod {{ $labels.pod }} ({{ $labels.container }}) is restarting {{ $value }} times per 15 minutes."

复制代码

结论

Kubernetes调度器作为容器编排系统的核心组件，其工作原理和优化技巧对于构建高效、稳定的云原生环境至关重要。通过深入理解调度器的工作流程、资源感知机制和智能调度策略，我们可以更好地优化集群资源利用率，提高应用性能和系统稳定性。

本文从调度器的基本工作原理出发，详细介绍了过滤、打分和绑定等关键步骤，探讨了资源感知机制和智能调度策略，并提供了一系列实用的优化技巧和实际案例分析。最后，我们总结了构建稳定云原生环境的最佳实践，涵盖资源管理、调度策略、高可用性、安全性以及监控和日志等方面。

随着云原生技术的不断发展，Kubernetes调度器也在持续演进。未来，我们可以期待更多智能化、自动化的调度功能，如基于机器学习的资源预测、更灵活的调度策略和更高效的调度算法。通过不断学习和实践，我们可以更好地掌握Kubernetes调度器的核心原理和优化技巧，为构建高效、稳定的云原生环境贡献力量。

mai2

感謝分享