在部署更新期间忽略pod反关联

Question

想象一下在主节点节点设置中,您在节点上部署具有pod反关联性的服务:部署的更新将导致创建另一个pod但调度程序无法调度,因为两个节点都具有反节点亲和力.

问:如何更灵活地设置反亲和力以允许更新？

affinity:
   podAntiAffinity:
     requiredDuringSchedulingIgnoredDuringExecution:
     - labelSelector:
         matchExpressions:
         - key: app
           operator: In
           values:
           - api
     topologyKey: kubernetes.io/hostname

有错误

No nodes are available that match all of the following predicates:: MatchInterPodAffinity (2), PodToleratesNodeTaints (1).

Answer 1

看看最大浪涌

如果您设置 Max Surge = 0，则表示您告诉 Kubernetes 您不允许它创建的 pod 数量多于您为部署设置的副本数量。这基本上会迫使 Kubernetes 在启动新 Pod 之前删除一个 Pod，从而首先为新 Pod 腾出空间，从而解决 podAntiAffinity 问题。我自己就利用了这个机制，并取得了巨大的成功。

配置示例

apiVersion: extensions/v1beta1
kind: Deployment
    ...
spec:
  replicas: <any number larger than 1>
    ...
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
    type: RollingUpdate
    ...
  template:
    ...
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - api
          topologyKey: kubernetes.io/hostname

警告：如果您只有一个副本，请不要执行此操作，因为这会导致停机，因为在添加新的 pod 之前，唯一的 pod 将被删除。如果您有大量副本，这将使部署变慢，因为 Kubernetes 一次只能升级 1 个 pod，您可以调高maxUnavailable以使 Kubernetes 一次删除更多数量的 pod。

Answer 2

以下是一些可能有效的方法：

\n

\n
1. 修改部署的rollingUpdate 策略“Max Unavailable”参数至少为 1，这样可以立即销毁旧部署的 1 个 Pod，为创建新部署的 1 个 Pod 腾出空间。
\n

\n

最大不可用

\n

\n

.spec.strategy.rollingUpdate.maxUnavailable 是一个可选字段，指定更新过程中不可用的 Pod 的最大数量。该值可以是绝对数量（例如 5）或所需 Pod 的百分比（例如 10%）。绝对数是根据百分比向下四舍五入计算得出的。如果 .spec.strategy.rollingUpdate.maxSurge 为 0，则该值不能为 0。默认值为 25%。

\n

例如，当该值设置为 30% 时，当滚动更新开始时，旧的 ReplicaSet 可以立即缩减到所需 Pod 的 70%。一旦新的 Pod 准备就绪，旧的 ReplicaSet 可以进一步缩小，然后扩大新的 ReplicaSet，确保更新过程中始终可用的 Pod 总数至少是所需 Pod 的 70%。\nMax Surge

\n

\n

\n
2. 修改部署 Pod 规范以使用“软”反关联性而不是“硬”。
\n

\n

Pod 反亲和力

\n

\n

当前有两种类型的节点关联性，称为 requiredDuringSchedulingIgnoredDuringExecution 和 PreferredDuringSchedulingIgnoredDuringExecution。您可以将它们分别视为 \xe2\x80\x9chard\xe2\x80\x9d 和 \xe2\x80\x9csoft\xe2\x80\x9d，因为前者指定了 pod 必须满足的规则。调度到节点上（就像nodeSelector，但使用更具表现力的语法），而后者指定调度程序将尝试强制执行但不能保证的首选项。

\n

\n