Когда и где использовать правила близости Kubernetes Pod

Question

Я пытаюсь понять, если это хорошая практика, чтобы использовать podAntiAffinity Правило предпочесть это Podв моем Deployment избегать быть запланированным на том же узле. Таким образом распространяя Podна моем кластере Kubernetes.

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: "app.kubernetes.io/name"
            operator: In
            values:
            - "foo"
        topologyKey: "kubernetes.io/hostname"

Документация предлагает избегать использования podAntiAffinity для кластеров с сотнями узлов, что говорит о том, что их использование влияет на производительность.

Кроме того, если я их не использую, поведение планировщика по умолчанию не распространяется на пространство Podв любом случае?

Я полагаю, это также имеет значение, что Deployment для. Имеет смысл использовать podAntiAffinity для кеша Redis, например, но не будет ли еще больше смысла использовать DaemonSet для этого случая? Кроме того, какова рекомендация для веб-сервера Pod?

Answer 1

Вы используете правила Pod/Node Affinity, если хотите запланировать pod на некоторых узлах, сопоставляя указанное условие в более выразительных методах. Я не уверен, что вы можете использовать его, чтобы избежать планирования на том же узле. Если вы не используете правило сходства, то kube-scheduler будет искать подходящий узел для планирования pod на нем, и это, как правило, не тот же самый узел.

Вы заставляете kube-планировщик "думать" больше, определяя правила соответствия, и это нормально, что в больших кластерах это может повлиять на производительность.

Также, чтобы понять, как планировщик кубов итерирует по узлам по умолчанию, вы можете проверить эту документацию.