Когда и где использовать правила близости Kubernetes Pod - PullRequest
Новая
       76

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

0 голосов
/ 28 февраля 2019

Я пытаюсь понять, является ли хорошей практикой использование правила 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?

1 Ответ

0 голосов
/ 21 марта 2019

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

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

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

...