Здравствуйте.
Есть кластер 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 по размеру).