在部署更新过程中忽略pod反亲和力

Question

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

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

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 = 0，您将告诉Kubernetes，您将不允许它创建比为部署设置的副本数量更多的荚。这基本上迫使库伯内特斯在开始一个新的吊舱之前移除一个吊舱，从而首先为新的吊舱腾出空间，让你绕过podAntiAffinity问题。我本人就利用了这个机制，取得了很大的成功。

Config示例

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

警告:如果您只有一个副本，不要这样做，因为它会导致停机，因为在添加新副本之前，唯一的吊舱将被移除。如果您有大量的副本，这将使部署变得缓慢，因为库伯内特斯一次只能升级一个吊舱，您可以启动maxUnavailable，使库伯奈特能够一次移除更多的吊舱。

Answer 2

以下是几种可能有效的方法：

1. 修改部署rollingUpdate策略“最大不可用”参数至少为1，这允许立即销毁旧部署的一个荚，为创建新部署的一个荚腾出空间。

最大不可用

.spec.strategy.rollingUpdate.maxUnavailable是一个可选字段，它指定在更新过程中不可用的最大Pods数。该值可以是一个绝对值(例如，5)，也可以是所需Pods的百分比(例如，10%)。绝对值是根据百分比四舍五入计算的。如果.spec.strategy.rollingUpdate.maxSurge为0，则该值不能为0。默认值为25%。 例如，当此值设置为30%时，当滚动更新开始时，旧的ReplicaSet可以立即缩小到所需Pods的70%。一旦新的Pods准备就绪，旧的ReplicaSet就可以进一步缩小，然后扩展新的ReplicaSet，确保在更新期间始终可用的Pods总数至少是所需的Pods的70%。最大浪涌

1. 修改部署荚规范以使用“软”反亲和力而不是“硬”。

荚反亲和

当前有两种节点关联类型，称为和preferredDuringSchedulingIgnoredDuringExecution.。您可以分别将它们看作“硬”和“软”，因为前者指定了调度到节点上的荚必须满足的规则(就像nodeSelector一样，但使用更有表现力的语法)，而后者指定调度程序将尝试执行但不能保证的首选项。