Kubernetes Pod 调度策略怎么应用？

Kubernetes Pod 调度策略：实战场景解析

Pod调度是Kubernetes集群的核心功能之一，它决定了Pod应该在哪个Node节点上运行。通常情况下，Kubernetes的默认调度器已经能满足大部分需求，但对于一些特殊的业务场景，我们需要自定义Pod调度策略来优化资源利用率、提高应用性能或保证应用的可靠性。以下，我们通过几个具体的业务场景来深入探讨Pod调度策略的应用。

场景一：考试系统中的资源隔离

假设我们正在搭建一个在线考试系统，考试期间对服务器的CPU、内存和网络资源需求非常高。为了避免考试Pod与其他Pod争抢资源，影响考试的顺利进行，我们需要将考试Pod调度到专用的Node节点上。
直接答案：使用Node Affinity/Selector和Taints/Tolerations，将考试Pod调度到专用的Node节点上。

步骤：

1. 为专用Node打标签：

   首先，我们需要为专门用于考试的Node节点打上标签，例如：kubectl label node exam=true。

2. 配置Pod的Node Affinity：

   然后，在考试Pod的YAML文件中，使用nodeSelector或nodeAffinity来指定Pod只能调度到具有exam=true标签的Node节点上。

   apiVersion: v1
   kind: Pod
   metadata:
     name: exam-pod
   spec:
     containers:
     - name: exam-container
       image: exam-image:latest
     nodeSelector:
       exam: "true"
   

   或者，使用nodeAffinity实现更灵活的调度规则：

   apiVersion: v1
   kind: Pod
   metadata:
     name: exam-pod
   spec:
     containers:
     - name: exam-container
       image: exam-image:latest
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: exam
               operator: In
               values:
               - "true"
   

3. 配置Node的Taints和Pod的Tolerations（可选）：

   为了进一步避免其他Pod误调度到考试节点，可以为考试节点添加Taints，并为考试Pod添加相应的Tolerations。例如， taint node: kubectl taint node exam=dedicated:NoSchedule. 考试Pod 的toleration定义如下:

   apiVersion: v1
   kind: Pod
   metadata:
     name: exam-pod
   spec:
     containers:
     - name: exam-container
       image: exam-image:latest
     tolerations:
     - key: "exam"
       operator: "Equal"
       value: "dedicated"
       effect: "NoSchedule"
   

   注意： NoSchedule 表示没有对应Toleration的Pod不能调度到该节点上。其他可选值还有PreferNoSchedule (尽量不调度) 和 NoExecute (已在运行的Pod如果没有对应Toleration会被驱逐).

在实际项目中，还需要考虑考试高峰期的资源动态伸缩，可以通过Horizontal Pod Autoscaler (HPA) 结合Node Affinity来自动调整考试Pod的数量，并将其调度到预留的考试节点上。值得注意的是，需要监控考试系统的资源使用情况，及时调整资源配额和调度策略。

场景二：办公环境中对GPU资源的需求

在办公环境中，一些应用（例如设计软件、机器学习任务）需要使用GPU资源。为了充分利用GPU资源，并保证这些应用的性能，我们需要将需要GPU的Pod调度到具有GPU的Node节点上。

步骤：

1. 安装NVIDIA Device Plugin：

   首先，需要在具有GPU的Node节点上安装NVIDIA Device Plugin，以便Kubernetes能够识别GPU资源。

2. 为Node节点添加GPU资源标签：

   安装NVIDIA Device Plugin后，Kubernetes会自动为具有GPU的Node节点添加nvidia.com/gpu资源。我们可以使用kubectl describe node 来查看Node节点的资源信息。

3. 配置Pod的Resource Requests和Limits：

   在需要GPU的Pod的YAML文件中，需要配置resources.requests和resources.limits来申请GPU资源。

   apiVersion: v1
   kind: Pod
   metadata:
     name: gpu-pod
   spec:
     containers:
     - name: gpu-container
       image: gpu-image:latest
       resources:
         requests:
           nvidia.com/gpu: 1  # 申请1个GPU
         limits:
           nvidia.com/gpu: 1  # 限制使用1个GPU
   

通过配置Resource Requests和Limits，Kubernetes调度器会自动将Pod调度到具有足够GPU资源的Node节点上。在vDisk这类支持IDV架构的平台中，可以将部分桌面虚拟机的GPU资源通过Kubernetes管理和调度， 从而灵活地满足用户的GPU需求。 这种方式可以提高GPU的利用率，降低成本。

场景三：物联网边缘计算中的节点亲和性

在物联网边缘计算场景中，边缘节点通常具有不同的硬件配置和地理位置。 为了保证应用的低延迟和高性能，我们需要将Pod调度到最合适的边缘节点上。

步骤：

1. 为边缘节点打标签：

   根据节点的硬件配置和地理位置，为边缘节点打上不同的标签，例如：kubectl label node location=beijing, kubectl label node hardware=high-performance。

2. 配置Pod的Node Affinity：

   在Pod的YAML文件中，使用nodeSelector或nodeAffinity来指定Pod应该调度到哪个或哪些边缘节点上。例如，将Pod调度到北京的边缘节点上：

   apiVersion: v1
   kind: Pod
   metadata:
     name: edge-pod
   spec:
     containers:
     - name: edge-container
       image: edge-image:latest
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: location
               operator: In
               values:
               - "beijing"
   

在vDisk云桌面等云终端解决方案中，物联网管理可以有效集成到云桌面环境中，实现对边缘计算资源的统一管理和调度。vDisk的物联网管理功能可以监控边缘节点的健康状态和资源使用情况，并根据应用的实际需求动态调整调度策略。另外，vDisk的小程序查看功能使得管理员可以通过手机等移动设备随时随地查看边缘节点的状态，提高了管理的便捷性。

场景四：高可用性部署

为了提高应用的可用性，通常需要将同一个应用的多个副本分布到不同的Node节点上，避免单点故障。

步骤：

1. 使用Pod Anti-Affinity：

   在Pod的YAML文件中，使用podAntiAffinity来避免同一个应用的多个副本调度到同一个Node节点上。

   apiVersion: v1
   kind: Pod
   metadata:
     name: app-pod
     labels:
       app: my-app
   spec:
     containers:
     - name: app-container
       image: app-image:latest
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           - labelSelector:
               matchExpressions:
                 - key: app
                   operator: In
                   values:
                     - my-app
             topologyKey: kubernetes.io/hostname
   

   这里，topologyKey: kubernetes.io/hostname 表示根据Node节点的hostname来避免调度到同一个节点上。

经验表明，合理使用Pod Anti-Affinity可以显著提高应用的可用性。但需要注意的是，如果集群中没有足够的Node节点来满足Anti-Affinity的约束，Pod可能会一直处于Pending状态。

不同调度策略的对比

以下表格对比了几种常用的Kubernetes Pod调度策略：

最后提一下，除了上述几种常用的调度策略，Kubernetes还支持自定义调度器，可以根据更复杂的业务逻辑来实现Pod的调度。然而，自定义调度器的开发和维护成本较高，通常只在非常特殊的场景下才使用。