Работа с пороками и допусками в Kubernetes

Что такое Taints & Tolerants в Kubernetes и как это работает?

В обычной жизни мы часто сближаемся с людьми, которые нам нравятся и с которыми хотим общаться очень часто; аналогично, в Kubernetes мы можем установить близость между узлами и подами.

Если вы хотите убедиться, что только несколько типов модулей будут размещены в одном рабочем узле и оттолкнуть другие модули, которые вы не хотите быть частью узла рабочего процесса , вы можете использовать концепцию

«Пороки и терпимость»

Давайте разберемся с аналогией с комарами и человеком:

Предположим, вы не хотите, чтобы комар вас укусил, что в таком случае делать? Вы используете репеллент от комаров или одомос (гель от комаров).

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

Итак, наше тело здесь «испорчено», а Mosquito - «нетолерантно»

Но если появится какой-либо другой тип насекомых, устойчивый к нанесенному загрязнению (репеллент), они смогут сесть на наше тело.

Итак, в этом случае тело «испорчено», другая ошибка - «терпимая».

Используя эту аналогию, теперь мы можем понять, что некоторые типы узлов заражены, чтобы отразить некоторые нетолерантные типы модулей, этот модуль не сможет подключаться к таким узлам, в то время как некоторые другие типы модулей, которые являются толерантными. к испорченному рабочему узлу, сможет находиться на этом узле.

Пороки и допуски в контексте Kubernetes:

В случае Kubernetes

Узел: человек, на котором хотел сесть ошибка. Узел ее вообще испорчен
Стручок: это сам жук / москит. Стручок здесь обычно делают толерантным

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

Давайте разберемся с цифрой, приведенной ниже:

Пояснение:

Рабочий NODE 1 Tainted и POD 3 отмечен как терпимый:

УЗЕЛ 1 здесь помечен как Зараженный (зеленый цвет), что означает, что ни один из модулей, POD 1, POD 2, POD 3 не сможет находиться на NODE 1, пока какой-либо один или все они не будут помечены как устойчивые к узлу. 1 портит.

Итак, если мы отметим POD 3 как толерантный к зараженному УЗЛУ 1, как показано на рисунке выше, и оставим другие модули, модуль 1, модуль 2, как нетолерантные к заражению Узлом 1, вот как может выглядеть ситуация:

Объяснение:

POD 3 разрешено размещаться в NODE 1, поскольку он отмечен как устойчивый к нему. Остальным модулям разрешается размещать в УЗЛЫ 2 и УЗЕЛ 3.

Примечание!

POD 3, даже если он отмечен как толерантный к УЗЛУ 1, имеет полную свободу быть частью других узлов: узла 2 и узла 3, но модули POD 1, POD 2 не могут быть размещены в УЗЛЕ 1, пока они не будут отмечены. терпимый к этому.

Итак, с этой интуицией и пониманием пришло время понять

Как наносятся порчи?

Вы добавляете заражение к узлу, используя kubectl taint.

Например, добавление taint с помощью команды kubectl taint будет иметь следующий синтаксис:

kubectl taint nodes <node name >key=value:taint-effect

Здесь

taint: это команда для применения taints в узлах.
узлы: набор рабочих узлов.
имя узла: имя конкретного рабочего узла, к которому нужно применить заражение, у него есть пара "ключ-значение".
пара "ключ-значение": он используется для указания типа приложения в модуле, к которому этот узел может быть присоединен.
taint-effect: используется для определения того, как будут обрабатываться капсулы, если они не переносят заражение.

Эффект загрязнения бывает следующих типов

NoSchedule
PreferNoSchedule
NoExecute

Вот так будет выглядеть финальная команда:

kubectl taint nodes node1 app=blue: NoSchedule

здесь node1 заражен модулем с парой "ключ-значение" app = blue, где модули сопоставлены с типом искаженного эффекта: NoSchedule. Это означает, что для данного узла, node1, не будет запланировано ни одного модуля, пока он не получит соответствующие допуски.

Добавление допусков в модуль:

В приведенном выше определении модуля мы указываем допуски для модуля в разделе спецификации модуля, как показано на рисунке выше.

tolerations:
- key: "app"
  operator: "Equal"
  value: "blue"
  effect: "NoSchedule"

Это определение допусков соответствует приведенной ниже команде:

kubectl taint nodes node1 app=blue: NoSchedule

где мы добавили искажение, чтобы сопоставить пакет с парой "ключ-значение" app = blue.

Таким образом, с этим допуском теперь Pod tol-pod будет разрешено планировать с узлом, который испорчен, чтобы принимать тип значения app = blue.

Как порок и терпимость работают вместе:

Допуски, определенные в определении модуля, соответствуют заражению (сопоставлено с рабочими узлами), где он ищет совпадающие ключи и эффект заражения.

Помните: есть два особых случая:

По умолчанию операция имеет тип: Равно

Если в определении есть пустой ключ с типом оператора Существует, он соответствует всем ключам, значениям и эффектам, что означает, что эта пара "ключ-значение", сопоставленная с любым искажением, будет терпеть все.
Пустой эффект соответствует всем эффектам с ключом Key.

Понимание других эффектов заражения:

Эффект загрязнения: PreferNoSchedule

tolerations:
- key: "app"
  operator: "Equal"
  value: "blue"
  effect: "PreferNoSchedule"

Если мы изменим тип taint-эффекта на: effect: "PreferNoSchedule",

это означает, что это «предпочтительная» или «мягкая» версия NoSchedule - система попытается избежать размещения модуля, который не переносит заражение на узле, но это не обязательно

Эффект загрязнения: NoExecute

Чтобы лучше понять это, давайте рассмотрим новый вариант использования, в котором у нас есть несколько допусков, сопоставленных с одной и той же парой "ключ-значение", но с другим типом эффектов искажения.

Давайте добавим помутнение узла: узел 1, как показано ниже.

- $ kubectl taint nodes node1 app=blue:NoSchedule
- $ kubectl taint nodes node1 app=blue:NoExecute
- $ kubectl taint nodes node1 app=green:NoSchedule

Теперь давайте создадим определение модуля с двумя допусками, как показано ниже:

apiVersion: v1
kind: Pod
metadata:
  name: tol-pod
  labels:
    env: prod
spec:
  containers:
  - name: nginx-cotainer
    image: nginx
  
  tolerations:
  - key: "app"
     operator: "Equal"
     value: "blue"
     effect: "NoSchedule"
  - key: "app"
     operator: "Equal"
     value: "blue"
     effect: "NoExecute"

Пояснение:

В описанных выше ситуациях наш модуль не будет назначен на узел node1, так как нет допуска, соответствующего третьему заражению.

Но если модуль уже запущен в узле, он может продолжать это делать, если узел был недавно заражен, поскольку третье заражение является единственным из трех допусков, которые не определены для обработки узел.

Как правило, если какой-либо узел имеет заражение типа NoExecute и какой-либо под, который не был разработан, допуски для обработки заражения будут исключены (если они существовали до того, как узел был заражен), но любые стручки, которые действительно терпят заражение, никогда не будут выселены.

терпениеSeconds:

Если мы хотим проинструктировать pod с taint-effect: NoExecute, чтобы он оставался привязанным к узлу, который был испорчен и был вынужден выселить, в течение некоторого определенного времени мы можем использовать необязательное поле tolerationSeconds в допусках определение, как показано ниже

tolerations:
- key: "app"
  operator: "Equal"
  value: "app"
  effect: "NoExecute"
  tolerationSeconds: 3600

Резюме:

Мы поняли

Что такое пороки и терпимость?
Почему используются пороки и допуски?
Как добавить taints в Worker Node?
Как добавить терпимость к капсуле?

Я хотел бы завершить эту часть некоторыми пунктами, в которых упоминаются варианты использования Taints & Tolerations. Как мы уже обсуждали, порчи и допуски - это гибкий способ оттолкнуть поды от узлов или выселить поды, которые не должны работать, поэтому стоит рассмотреть один из важных вариантов их использования:

Выделенный узел, привязанный к определенным группам пользователей / набору пользователей

Если в качестве администратора Kubernetes или архитектора DevOps вы хотите использовать какой-либо конкретный рабочий узел в кластере k8s исключительно для определенного набора или группы пользователей, мы можем сделать это следующим образом:

$ kubectl taint nodes nodename dedicated=groupName:NoSchedule

Затем модулям с допусками будет разрешено использовать выделенные и поврежденные узлы в кластере. Для того, чтобы Pod был запланирован на узлах с выделенной меткой, необходимо, чтобы Pod имел определение сродства узла, где должна быть указана эта метка special: groupName.

Мы узнаем больше о привязке к узлам в нашей следующей статье из этой серии или в Taints & Tolerations.

2. Выселения на основе заражения:

Мы можем разумно использовать эффект заражения NoExecute, чтобы принудительно исключить поды на основе проблем с узлами, которые необходимо решить для устранения ограничений ресурсов в узле или любой другой соответствующей проблемы, связанной с рабочими узлами.

Что дальше?

Мы рассмотрим более сложные варианты использования Taints & Tolerations, например

Соответствие узла
Примеры использования удаления пакетов на основе заражения
Как управлять специализированными спецификациями аппаратного уровня в узлах?
и многое другое… ..

Если вам понравилась эта работа, покажите мне некоторую поддержку и привязанность, следуя за мной и хлопая в ладоши.