LINUX.ORG.RU
решено ФорумAdmin

Kubernetes nodeSelector

 


0

1

Продолжая осваивать Kubernetes установил dashboard. После установки, один из двух dashboard pods постоянно крашился перезапускался. После гугления, выяснилось, что оба pods должны быть запущены на мастер ноде, а в моем случае они запустились на worker. Перекинув их на мастер ноду, все заработало.

Мне показалось странно, что разработчик не позаботился о том, чтобы dashboard сразу разворачивался на мастере, где ему и место. Я стал гуглить, как привязать pod к конкретной ноде и нашел такой параметр как nodeSelector. Потом открыл yaml файл dashboard и какого было мое удивление, когда я там тоже нашел этот параметр. Т.е., как я понимаю, у разработчиков была задумка сделать чтобы dashboard разворачивался именно на мастере, вот так это выглядит:

nodeSelector:

«beta.kubernetes.io/os»: linux

# Comment the following tolerations if Dashboard must not be deployed on master

tolerations:

- key: node-role.kubernetes.io/master

effect: NoSchedule

Я не очень понял этот код и тем более не понял почему он не сработал в моем случае. Объясните мне пожалуйста :)

После гугления, выяснилось, что оба pods должны быть запущены на мастер ноде

Это скорее всего неверно и проблема была совсем в другом.

tolerations:
- key: node-role.kubernetes.io/master

Этот код разрешает поду попасть на мастер-ноду, но не гарантирует этого. Он просто расширяет список возможных нод куда этот под может попасть.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

Это скорее всего неверно и проблема была совсем в другом.

Проблема была именно в этом. Я нашел несколько issues на гитхабе, где люди решали проблему именно так. У меня она точно также решилась.

Вопрос моего топика не в том, почему dashboard не заработал, а почему pod не поставился на мастер ноду.

Сейчас еще раз углубился в tains и tolerations, поправьте меня если я не прав, вот что я понял:

tains - это метки, которые ставятся на ноды.

tolerations - это метки, которые ставятся на поды.

Каждая метка имеет название (key), значение (value) и действие (effect)

Система работает следующим образом, чтобы применить (например установить) pod к ноде нужно, чтобы tolerations у pod совпали с tains у node.

В данном случае мастер нода имеет следующий tain

key=node-role.kubernetes.io/master

value= (не указано, т.е. пустое)

effect=NoSchedule (значит не устанавливать)

Есть два способа сравнить trains и tolerations: 1. Сравнить у обоих key и value (оператор Equal) 2. Проверить наличие у обоих одинаковых key (оператор Exists)

В оригинальном yaml pod указано:

tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule

Оператор Equal используется по умолчанию (если не указывать ничего), но тогда нужно обязательно указать value, если value не указывать, то нужно указать использование оператора Exists

Т.е. правильный код должен выглядеть так

tolerations:
        - key: node-role.kubernetes.io/master
          operator: "Exists"
          effect: NoSchedule

В оригинальном коде пропущена строка с указанием оператора (operator: «Exists»)

Я думаю проблема в этом

samson_b ()
Последнее исправление: samson_b (всего исправлений: 1)
Ответ на: комментарий от alpha

Этот код разрешает поду попасть на мастер-ноду, но не гарантирует этого. Он просто расширяет список возможных нод куда этот под может попасть.

Вы правы, спасибо, я разобрался :))))

Tolerations are applied to pods, and allow (but do not require) the pods to schedule onto nodes with matching taints.

samson_b ()
Ответ на: комментарий от samson_b

Чтобы поставить pod исключительно на мастерноду, нужно его поменять с такого:

      nodeSelector:
        "beta.kubernetes.io/os": linux
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule

на такой

      nodeSelector:
        "beta.kubernetes.io/os": linux
        "node-role.kubernetes.io/master": ""
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule

Правильно?

samson_b ()
Последнее исправление: samson_b (всего исправлений: 1)