如何在香港服务器上通过Kubernetes资源调度策略（如Pod Affinity、Node Taints）优化大规模微服务架构的资源利用率？

发布人：Minchunlin 发布时间：2025-08-10 09:00 阅读量：529

我负责香港大型电商平台基础设施，工作中我常常需要面对的是如何高效地管理和调度数百个微服务，尤其是在集群规模不断扩展时，如何保证 Kubernetes 集群中的资源利用率最大化，并确保各个服务能够高效稳定地运行。

一开始，随着系统的扩展，集群中的 Pod 数量逐渐增多，节点的资源压力也随之加大。虽然 Kubernetes 提供了很强的资源管理能力，但实际操作中，我发现 Pod 的调度策略并没有做到最优，导致了节点资源的浪费和部分 Pod 由于没有合理调度而表现不稳定。

尤其是在香港机房的资源配置方面，我遇到了不少问题，比如节点间资源分配不均、服务间不合理的亲和性导致资源争抢等。为了优化这种情况，我开始深入研究 Kubernetes 中的 Pod Affinity、Node Taints 等资源调度策略，通过精细化的资源调度来优化大规模微服务架构的资源利用率。

接下来，我将通过这篇文章，分享我在优化 Kubernetes 集群资源利用率过程中，如何利用这些策略来提升性能，减少资源浪费。

一、问题现象：Kubernetes 调度策略带来的挑战

1.1 初期问题分析

随着平台规模的扩大，Kubernetes 集群中的 Pod 数量迅速增加。当我查看集群的资源使用情况时，发现以下几个问题：

资源浪费：有些节点资源并未被充分利用。某些节点 CPU 和内存使用率非常低，但它们依然被分配了很多 Pod，这显然是一种浪费。

Pod 容忍度差：有些服务对资源的要求非常特殊，比如必须运行在特定的节点上（例如，拥有 GPU 或高内存配置的节点），而 Kubernetes 调度器没有考虑到这些需求，导致部分服务调度到不适合的节点上。

亲和性问题：不同微服务之间有时需要共同运行在同一台节点上，以便提高通信效率，但 Kubernetes 默认的调度策略未必考虑到这一点，导致一些需要紧密协作的服务被分配到不同的节点，增加了延迟和网络开销。

这些问题显然影响了整体的资源利用率和服务的性能。

1.2 调度策略优化的需求

在这些问题的驱动下，我意识到需要更深入地优化集群中的调度策略。尤其是在 Pod Affinity 和 Node Taints/Tolerations 的使用上，通过优化调度过程，我可以：

提高资源利用率：确保每个节点的资源都能充分利用，避免资源浪费。

降低服务间的通信延迟：通过合理的 Pod Affinity 策略，确保需要高频交互的服务能够调度到同一节点，减少网络延迟。

增强服务的稳定性：通过合理的 Node Taints 配合 Tolerations，让特定的服务能够运行在指定的节点上，避免调度到不适合的环境中。

二、Kubernetes资源调度策略：Pod Affinity与Node Taints

2.1 Pod Affinity：控制 Pod 的亲和性

Pod Affinity 允许我们在调度 Pod 时，控制它与其他 Pod 的关系。通过设置 Pod Affinity，我们可以确保某些 Pod 一定要运行在特定节点上，或者在某些节点上与特定的 Pod 共同运行。它主要有两个策略：

RequiredDuringSchedulingIgnoredDuringExecution：严格要求 Pod 必须在特定条件下运行。

PreferredDuringSchedulingIgnoredDuringExecution：提出建议，Pod 优先调度到符合条件的节点，但不是强制要求。

2.1.1 实战案例：服务通信优化

在我自己的集群中，某些服务需要频繁地相互通信，尤其是订单服务和库存服务。这些服务频繁交换数据，如果它们运行在不同的节点上，就会导致较高的网络延迟和带宽消耗。为了解决这个问题，我决定使用 Pod Affinity 来保证这两者尽可能调度在同一个节点上。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: inventory-service
              topologyKey: "kubernetes.io/hostname"

在这个配置中，order-service 和 inventory-service 必须在同一个节点上运行。topologyKey 为 kubernetes.io/hostname，意味着它们需要调度到同一个物理主机上。

2.2 Node Taints 和 Tolerations：控制 Pod 的调度容忍性

在实际运营中，有些节点的资源非常特殊，比如包含高内存、高 CPU 或 GPU 配置，或者某些节点是预留节点，仅供特定的服务使用。为了确保这些节点不被不适合的 Pod 占用，我们可以利用 Node Taints 和 Pod Tolerations 来控制哪些 Pod 能够被调度到这些节点。

2.2.1 实战案例：资源独占优化

在我的集群中，我们有一些节点配备了 GPU 资源，主要用于计算密集型服务（如图像处理、机器学习等）。为了确保这些节点只被需要 GPU 的服务占用，我在 GPU 节点上设置了 Taint，只有具有对应 Toleration 的 Pod 才能调度到这些节点上。

kubectl taint nodes node1 gpu=true:NoSchedule

然后，在需要 GPU 的 Pod 中配置相应的 Toleration：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: image-processing-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: image-processing-service
  template:
    metadata:
      labels:
        app: image-processing-service
    spec:
      tolerations:
        - key: "gpu"
          value: "true"
          effect: "NoSchedule"

通过这种方式，只有标记为 gpu=true 的 Pod 才会被调度到具有 GPU 资源的节点上，避免了其他不需要 GPU 的 Pod 占用这些节点的资源。