在当今的云计算和容器化技术领域，Kubernetes 已经成为了编排和管理容器化应用的事实标准。然而，在实际使用过程中，我们可能会遇到 Kubernetes 默认节点调度不合理的问题。下面就来详细探讨如何应对这个问题。

一、问题背景与应用场景

在很多企业的生产环境中，Kubernetes 集群被广泛用于部署各种微服务应用。想象一下，一家电商公司使用 Kubernetes 来管理他们的订单系统、库存系统、用户服务等多个微服务。这些服务对资源的需求各不相同，订单系统在促销活动期间可能需要大量的 CPU 和内存资源来处理高并发的订单请求；而库存系统则可能更侧重于磁盘 I/O 性能，以确保库存数据的及时更新。

Kubernetes 默认的调度器会根据一些基本的规则来分配 Pod 到节点上，比如节点的可用资源、Pod 的资源请求等。但在复杂的生产环境中，这些默认规则可能无法满足实际需求。例如，默认调度器可能会将多个高 CPU 需求的 Pod 调度到同一个节点上，导致该节点 CPU 资源耗尽，而其他节点却有大量的空闲资源，从而影响整个系统的性能和稳定性。

二、Kubernetes 默认调度器的工作原理

Kubernetes 默认调度器的工作流程主要分为两个阶段：过滤阶段和打分阶段。

过滤阶段

过滤阶段会根据一系列的规则筛选出符合 Pod 调度要求的节点。例如，Pod 可能有资源请求（如 CPU 和内存），调度器会检查每个节点的可用资源是否满足 Pod 的请求。以下是一个简单的示例，假设我们有一个 Pod 定义文件 example-pod.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    resources:
      requests:
        cpu: "500m"  # 请求 500 毫核 CPU
        memory: "256Mi"  # 请求 256 MiB 内存

在过滤阶段，调度器会遍历集群中的所有节点，检查哪些节点有至少 500 毫核的 CPU 和 256 MiB 的可用内存。

打分阶段

在过滤出符合要求的节点后，调度器会对这些节点进行打分。打分的依据包括节点的资源使用率、Pod 分布情况等。例如，调度器可能会优先选择资源使用率较低的节点，以实现资源的均衡分配。

三、默认调度不合理的表现及原因分析

表现

  1. 资源不均衡：如前面提到的，多个高资源需求的 Pod 集中在少数节点上，导致这些节点资源紧张，而其他节点资源闲置。
  2. 性能瓶颈：某些对特定资源（如磁盘 I/O）有高要求的 Pod 被调度到不适合的节点上，导致性能下降。
  3. 服务不可用：如果某个节点因为资源耗尽而崩溃，那么该节点上的所有 Pod 都会受到影响，可能导致服务不可用。

原因

  1. 默认规则简单：默认调度器的规则是通用的，无法考虑到具体业务场景的复杂需求。
  2. 缺乏业务感知：调度器不了解 Pod 所代表的业务含义，无法根据业务的重要性和优先级进行调度。
  3. 动态变化处理不足：在集群资源动态变化（如节点故障、新节点加入）时，默认调度器可能无法及时做出最优的调度决策。

四、应对策略

节点亲和性和反亲和性

节点亲和性和反亲和性允许我们根据节点的标签来控制 Pod 的调度。例如，我们可以为不同类型的节点添加标签，然后在 Pod 定义中指定亲和性规则。

节点亲和性示例

假设我们有一些节点被标记为 disk-type=ssd，表示这些节点使用了 SSD 磁盘。我们有一个对磁盘 I/O 性能要求较高的 Pod，可以使用节点亲和性将其调度到这些节点上。以下是 Pod 定义文件 io-intensive-pod.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: io-intensive-pod
spec:
  containers:
  - name: io-intensive-container
    image: some-io-intensive-app
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk-type
            operator: In
            values:
            - ssd

在这个示例中，requiredDuringSchedulingIgnoredDuringExecution 表示在调度时必须满足亲和性规则，但在 Pod 运行期间如果节点标签发生变化，不会影响 Pod 的运行。

节点反亲和性示例

假设我们有多个副本的同一个服务，为了提高服务的可用性，我们希望这些副本不要调度到同一个节点上。可以使用节点反亲和性来实现。以下是 Pod 定义文件 anti-affinity-pod.yaml：

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

在这个示例中，podAntiAffinity 表示 Pod 之间的反亲和性，topologyKey 为 kubernetes.io/hostname 表示根据节点的主机名来进行反亲和性调度，确保同一个服务的 Pod 不会调度到同一个节点上。

污点和容忍度

污点和容忍度是另一种控制 Pod 调度的机制。节点可以被标记为带有污点，而 Pod 可以指定是否容忍这些污点。

污点示例

假设我们有一个节点需要进行维护，我们可以给这个节点添加一个污点，让其他 Pod 不会调度到这个节点上。使用以下命令给节点添加污点：

kubectl taint nodes node-name maintenance=true:NoSchedule

其中，node-name 是节点的名称，maintenance=true 是污点的键值对，NoSchedule 表示如果 Pod 不容忍这个污点，就不会被调度到该节点上。

容忍度示例

如果有一些特殊的 Pod 可以容忍这个污点，我们可以在 Pod 定义中指定容忍度。以下是 Pod 定义文件 tolerant-pod.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: tolerant-pod
spec:
  containers:
  - name: tolerant-container
    image: some-image
  tolerations:
  - key: "maintenance"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

在这个示例中，Pod 可以容忍 maintenance=true 的污点，因此可以被调度到带有该污点的节点上。

自定义调度器

如果以上方法都无法满足需求，我们可以开发自定义调度器。自定义调度器可以根据具体的业务规则和需求来进行调度决策。以下是一个简单的自定义调度器的开发步骤：

  1. 选择编程语言：可以使用 Go 语言来开发自定义调度器，因为 Kubernetes 本身就是用 Go 语言开发的，有丰富的库可以使用。
  2. 实现调度逻辑：在自定义调度器中，我们可以根据业务需求实现自己的过滤和打分逻辑。例如，我们可以根据 Pod 的业务优先级来进行打分，优先调度高优先级的 Pod。
  3. 部署自定义调度器：将自定义调度器部署到 Kubernetes 集群中，并在 Pod 定义中指定使用自定义调度器。
apiVersion: v1
kind: Pod
metadata:
  name: custom-scheduled-pod
spec:
  schedulerName: custom-scheduler  # 指定使用自定义调度器
  containers:
  - name: custom-scheduled-container
    image: some-image

五、技术优缺点分析

节点亲和性和反亲和性

优点

  • 灵活性高：可以根据节点标签灵活控制 Pod 的调度，满足不同业务场景的需求。
  • 易于实现：只需要在 Pod 定义中添加简单的亲和性规则即可。

缺点

  • 配置复杂：如果标签和规则设置不当，可能会导致调度结果不符合预期。
  • 缺乏动态性：一旦规则确定，在运行期间难以动态调整。

污点和容忍度

优点

  • 节点控制强：可以精确控制哪些 Pod 可以调度到特定节点上，适用于节点维护、隔离等场景。
  • 简单有效：通过简单的命令和配置就能实现节点的调度控制。

缺点

  • 缺乏全局视角：污点和容忍度主要关注单个节点的调度控制，无法从全局角度优化集群资源分配。

自定义调度器

优点

  • 高度定制化：可以根据具体业务需求实现复杂的调度逻辑，满足各种特殊场景。
  • 动态调整：可以在运行期间动态调整调度策略。

缺点

  • 开发成本高：需要具备一定的编程能力和对 Kubernetes 内部机制的深入理解。
  • 维护难度大：自定义调度器的维护和升级需要额外的精力和资源。

六、注意事项

  1. 标签管理：在使用节点亲和性和反亲和性时，要合理管理节点标签，确保标签的一致性和准确性。
  2. 测试验证：在应用新的调度策略之前，一定要在测试环境中进行充分的测试，确保调度结果符合预期。
  3. 监控和调整：对集群的资源使用情况和 Pod 调度情况进行实时监控，根据监控结果及时调整调度策略。

七、文章总结

Kubernetes 默认节点调度不合理是在实际生产环境中经常遇到的问题。通过深入了解默认调度器的工作原理和问题表现，我们可以采用节点亲和性和反亲和性、污点和容忍度、自定义调度器等多种策略来应对。每种策略都有其优缺点，我们需要根据具体的业务场景和需求选择合适的策略。同时，在实施过程中要注意标签管理、测试验证和监控调整等方面，以确保集群的性能和稳定性。