K8s Pod Affinity 与 Anti-Affinity 调度策略详解 - 智猿学院-IT界的百科全书

K8s Pod Affinity 与 Anti-Affinity 调度策略详解：让你的 Pod 们不再孤单寂寞冷！

各位观众老爷们，大家好！欢迎来到今天的 Kubernetes 调度小课堂。我是你们的 Kubernetes 狂热爱好者，兼段子手，兼…嗯…头发日益稀疏的编程专家。今天我们要聊点什么呢？没错！就是 K8s 里那些神秘又迷人的 Pod Affinity 和 Anti-Affinity 调度策略！

想象一下，你的 Pods，一个个孤独地漂浮在你的 Kubernetes 集群中，就像浩瀚宇宙里的一个个小行星，彼此之间没有任何联系，孤独，寂寞，冷！难道我们就眼睁睁看着它们这样吗？当然不行！我们要做的，就是给它们牵线搭桥，让它们找到自己的“好基友”，或者让它们远离那些“冤家对头”。这就是 Affinity 和 Anti-Affinity 的作用！

一、什么是 Affinity 和 Anti-Affinity？简单来说，就是“抱团取暖”和“划清界限”！

Affinity (亲和性): 就像磁铁一样，让 Pods 尽可能地部署在一起。 “物以类聚，人以群分”，好兄弟就要在一起，一起扛bug，一起升职加薪！
Anti-Affinity (反亲和性): 就像避雷针一样，让 Pods 尽可能地分散开来。 “距离产生美”，避免单点故障，减少资源争抢，让世界充满爱与和平！

二、为什么要使用 Affinity 和 Anti-Affinity？难道默认的调度策略不好吗？

默认的调度策略，就像一个 “雨露均沾” 的皇帝，尽可能把 Pods 分散到各个节点上。听起来很公平，对不对？但是！现实世界往往不是这么简单。

性能需求: 某些 Pods 之间需要频繁通信，如果部署在不同的节点上，网络延迟会严重影响性能。例如，一个 Web 服务和一个数据库，最好部署在同一个节点上，甚至同一个 Pod 里 (当然，这违反了 “单一职责原则”，只是举个例子)。
高可用性: 如果某个节点挂了，部署在该节点上的所有 Pods 都会受到影响。如果将同一个应用的多个实例部署在不同的节点上，即使某个节点挂了，应用仍然可以正常运行。
资源隔离: 某些 Pods 消耗大量的资源，如果和其他 Pods 部署在同一个节点上，可能会导致资源争抢，影响其他 Pods 的性能。
授权与安全: 某些 Pods 负责处理敏感数据，需要部署在特定的节点上，以保证安全性。

总而言之，默认的调度策略只考虑了资源利用率，而忽略了应用自身的特性和需求。 Affinity 和 Anti-Affinity 就是为了解决这些问题而生的。它们就像 Kubernetes 的 “红娘”，可以根据你的需求，灵活地控制 Pods 的部署位置。

三、Affinity 和 Anti-Affinity 的分类：软硬兼施，刚柔并济！

Affinity 和 Anti-Affinity 分为两种类型：

Required (必须): “霸道总裁爱上你”，必须满足指定的规则，否则 Pod 无法调度。如果找不到符合条件的节点，Pod 将一直处于 Pending 状态，直到有合适的节点出现。这种方式非常严格，确保 Pod 必须满足某些条件才能运行。
Preferred (偏好): “你若安好，便是晴天”，尽可能满足指定的规则，但不是强制的。如果找不到完全符合条件的节点，Pod 仍然可以调度到其他节点上。这种方式比较灵活，可以根据实际情况进行调整。

类型	描述	适用场景
Required	强制满足规则，否则 Pod 无法调度。	性能至关重要的场景，例如数据库和 Web 服务必须部署在同一个节点上。安全性要求极高的场景，例如处理敏感数据的 Pod 必须部署在特定的节点上。
Preferred	尽可能满足规则，但不是强制的。	高可用性要求较高的场景，例如将同一个应用的多个实例尽可能地部署在不同的节点上。资源隔离要求较高的场景，例如将消耗大量资源的 Pod 尽可能地部署在不同的节点上，避免资源争抢。

四、Affinity 和 Anti-Affinity 的语法：复杂但强大，灵活又多变！

Affinity 和 Anti-Affinity 的配置都写在 Pod 的 spec.affinity 字段下。

1. Node Affinity (节点亲和性):

Node Affinity 是基于节点上的 Label 来进行调度的。就像给节点贴上标签，然后让 Pods 根据标签来选择自己喜欢的节点。

requiredDuringSchedulingIgnoredDuringExecution: 必须满足指定的规则才能调度，但节点上的 Label 发生变化时，不会影响已经运行的 Pod。就像 “结婚前要求很高，结婚后睁一只眼闭一只眼”。
preferredDuringSchedulingIgnoredDuringExecution: 尽可能满足指定的规则，但节点上的 Label 发生变化时，不会影响已经运行的 Pod。就像 “相亲时要求很高，结婚后发现对方有些缺点也能接受”。
requiredDuringSchedulingRequiredDuringExecution: 必须满足指定的规则才能调度，节点上的 Label 发生变化时，会影响已经运行的 Pod。如果节点上的 Label 不再满足规则，Pod 会被驱逐。就像 “结婚前要求很高，结婚后发现对方变了立刻离婚”。 (谨慎使用！)

Node Affinity 的 YAML 示例：

apiVersion: v1
kind: Pod
metadata:
  name: node-affinity-example
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - node1
            - node2
  containers:
  - name: nginx
    image: nginx:latest

这段 YAML 的含义是：这个 Pod 必须部署在 kubernetes.io/hostname Label 的值为 node1 或 node2 的节点上。

2. Pod Affinity 和 Pod Anti-Affinity (Pod 亲和性与反亲和性):

Pod Affinity 和 Pod Anti-Affinity 是基于已经运行的 Pods 的 Label 来进行调度的。就像 “近朱者赤，近墨者黑”，让 Pods 选择和自己 “志同道合” 的 Pods 部署在一起，或者远离那些 “道不同不相为谋” 的 Pods。

requiredDuringSchedulingIgnoredDuringExecution: 必须满足指定的规则才能调度，但目标 Pod 的 Label 发生变化时，不会影响已经运行的 Pod。
preferredDuringSchedulingIgnoredDuringExecution: 尽可能满足指定的规则，但目标 Pod 的 Label 发生变化时，不会影响已经运行的 Pod。
requiredDuringSchedulingRequiredDuringExecution: 必须满足指定的规则才能调度，目标 Pod 的 Label 发生变化时，会影响已经运行的 Pod。如果目标 Pod 的 Label 不再满足规则，Pod 会被驱逐。 (谨慎使用！)

Pod Affinity 和 Pod Anti-Affinity 的 YAML 示例：

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

这段 YAML 的含义是：这个 Pod 必须和 Label 为 app: my-app 的 Pod 部署在同一个节点上 (topologyKey: kubernetes.io/hostname)。

Pod Anti-Affinity 的 YAML 示例：

apiVersion: v1
kind: Pod
metadata:
  name: pod-anti-affinity-example
spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - my-app
          topologyKey: kubernetes.io/hostname
  containers:
  - name: nginx
    image: nginx:latest

这段 YAML 的含义是：尽可能避免和 Label 为 app: my-app 的 Pod 部署在同一个节点上 (topologyKey: kubernetes.io/hostname)。 weight: 100 表示这个偏好的权重，权重越高，越倾向于满足这个规则。

五、Affinity 和 Anti-Affinity 的高级用法：灵活组合，玩转调度！

使用多个 matchExpressions: 可以指定多个 Label 的匹配规则，实现更复杂的调度策略。就像 “既要身材好，又要颜值高，还要有内涵”。
使用 operator: 可以使用不同的操作符，例如 In, NotIn, Exists, DoesNotExist, Gt, Lt，来实现更灵活的匹配规则。就像 “可以接受身高 170 以上的，但不接受身高 180 以上的”。
使用 topologyKey: 可以指定不同的拓扑域，例如 kubernetes.io/hostname (节点), failure-domain.beta.kubernetes.io/zone (可用区), failure-domain.beta.kubernetes.io/region (区域)，来实现更精细的调度策略。就像 “要在同一个城市，同一个区，同一个小区”。
结合 Taints 和 Tolerations: Taints 可以给节点打上 “污点”，Tolerations 可以让 Pods 容忍这些 “污点”。结合 Affinity 和 Anti-Affinity，可以实现更复杂的节点亲和性和反亲和性。

六、最佳实践：用好 Affinity 和 Anti-Affinity，让你的应用飞起来！

谨慎使用 requiredDuringSchedulingRequiredDuringExecution: 这种方式非常严格，容易导致 Pod 无法调度，甚至被驱逐。除非你有非常明确的需求，否则尽量避免使用。
合理设置 weight: weight 可以控制 preferredDuringSchedulingIgnoredDuringExecution 的优先级。权重越高，越倾向于满足这个规则。
充分利用 Label: Label 是 Affinity 和 Anti-Affinity 的基础。为你的节点和 Pods 打上合适的 Label，可以方便你使用 Affinity 和 Anti-Affinity 来控制 Pods 的部署位置。
监控 Pod 的调度情况: 可以通过 Kubernetes 的 Events 来监控 Pod 的调度情况，了解 Pod 是否成功调度到指定的节点上。
结合实际情况进行调整: Affinity 和 Anti-Affinity 的配置需要根据实际情况进行调整。不同的应用有不同的需求，没有一成不变的配置。

七、总结： Affinity 和 Anti-Affinity，Kubernetes 的 “魔法棒”！

Affinity 和 Anti-Affinity 是 Kubernetes 中非常强大和灵活的调度策略。它们可以让你根据你的需求，灵活地控制 Pods 的部署位置，从而提高应用的性能，可用性和安全性。

掌握了 Affinity 和 Anti-Affinity，你就掌握了 Kubernetes 的 “魔法棒”，可以随心所欲地调度你的 Pods，让它们不再孤单寂寞冷，而是找到自己的 “好基友”，或者远离那些 “冤家对头”，共同构建一个和谐稳定的 Kubernetes 集群！

希望今天的讲解对大家有所帮助。如果大家还有什么疑问，欢迎在评论区留言。感谢大家的观看，我们下次再见！ (挥手 👋)

最后，送给大家一句 Kubernetes 格言：

“代码虐我千百遍，我待 K8s 如初恋！” ❤️

K8s Pod Affinity 与 Anti-Affinity 调度策略详解：让你的 Pod 们不再孤单寂寞冷！

发表回复 取消回复

发表回复取消回复