@riberk

Почему шедулер kubernetes может игнорировать nodeAffinity?

Здравствуйте.
Есть кластер k8s версии 1.12 развёрнутый на aws при помощи kops
В кластере есть некоторое количество нод, размеченных лейблом 'example.com/wtf', который принимает значения a, b, c, d
Для примера как-то так
Node name          example.com/wtf
instance1                  a
instance2                  b
instance3                  c
instance4                  d

И есть тестовый деплоймент

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-scheduler
spec:
  replicas: 6
  selector:
    matchLabels:
      app: test-scheduler
  template:
    metadata:
      labels:
        app: test-scheduler
    spec:
      tolerations:
        - key: spot
          operator: Exists
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - preference:
              matchExpressions:
              - key: example.com/wtf
                operator: In
                values:
                - a
            weight: 40
          - preference:
              matchExpressions:
              - key: example.com/wtf
                operator: In
                values:
                - b
            weight: 35
          - preference:
              matchExpressions:
              - key: example.com/wtf
                operator: In
                values:
                - c
            weight: 30
          - preference:
              matchExpressions:
              - key: example.com/wtf
                operator: In
                values:
                - d
            weight: 25
      containers:
      - name: a
        resources:
          requests:
            cpu: "100m"
            memory: "50Mi"
          limits:
            cpu: "100m"
            memory: "50Mi"
        image: busybox
        command:
          - 'sleep'
          - '99999'


Судя по документации, nodeAffinity должны складываться для каждой ноды, на которую может быть запланирован под,
и выигрывает нода, у которой сумма weight больше других. Но в моём случае ноды выбираются достаточно рандомным образом.
К примеру, вот на такие 5 нод планируются 6 подов из деплоймента:
NODE    LABEL
wtf1	NONE
node1	a
node2	b
node3	c
wtf2	NONE


При этом ноды wtf1 и wtf2 вообще не содержат моего лейбла (при этом есть ещё одна нода с этим лейблом со значением 'd').
Место на всех нодах есть, они доступны и могут запускать поды

В связи с этим 2 вопроса
1. Почему так происходит?
2. Пишет ли шедулер куда-то логи того, как выбиралась нода для пода? В эвентах этой информации нет и в логах шедулера на мастерах тоже пусто

Основной смысл этих манипуляций - я хочу разделить все ноды тегами по размеру
и заполнять своими приложениями сначала маленькие и дешёвые виртуалки, а только потом большие и дорогие (не в ущерб отказоустойчивости, т.е. podAntiAffinity имеет больший вес, чем nodeAffinity по размеру).
  • Вопрос задан
  • 140 просмотров
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы