Поиск по сайту:

Как использовать недочеты и допуски Kubernetes, чтобы избежать нежелательного планирования


Taints и tolerations — это механизм Kubernetes для управления расписанием подов на узлах в вашем кластере. Загрязнения применяются к узлам и действуют как отталкивающий барьер против новых модулей. Испорченные узлы будут принимать только те модули, которые были отмечены соответствующим допуском.

Taints — один из наиболее продвинутых механизмов планирования Kubernetes. Они облегчают множество различных случаев использования, когда вы хотите предотвратить попадание модулей на нежелательные узлы. В этой статье вы узнаете, что такое taints и tolerances и как вы можете использовать их в своем собственном кластере.

Как работает планирование

Kubernetes — это распределенная система, в которой вы можете развертывать контейнерные приложения (модули) на нескольких физических хостах (узлах). Когда вы создаете новый под, Kubernetes необходимо определить набор узлов, на которых он может быть размещен. Это то, что относится к планированию.

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

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

Случаи использования порчи

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

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

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

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

Эффекты порчи

Каждый Node taint может оказывать одно из трех различных воздействий на решения Kubernetes по планированию:

  • NoSchedule. Поды, не допускающие заражения, не будут планироваться на узле. Поды, уже запланированные для узла, не затрагиваются, даже если они не терпят заражения.
  • PreferNoSchedule — Kubernetes будет избегать планирования подов, не допускающих заражения. Pod по-прежнему можно запланировать на Node в крайнем случае. Это не влияет на существующие модули.
  • NoExecute — работает аналогично NoSchedule, за исключением того, что существующие модули также затрагиваются. Поды без допусков будут немедленно удалены из узла, что приведет к их перепланированию на другие узлы в вашем кластере.

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

Заражение узла

Taints применяются к узлам с помощью команды kubectl taint. Он принимает имя целевого узла, ключ и значение заражения, а также эффект.

Вот пример заражения узла, чтобы выделить его для определенной среды:

$ kubectl taint nodes demo-node env=production:NoSchedule
node/demo-node tainted

Вы можете применить несколько пометок к узлу, повторив команду. Значение ключа является необязательным — вы можете создавать бинарные пометки, опуская его:

$ kubectl taint nodes demo-node has-gpu:NoSchedule

Чтобы удалить ранее примененное заражение, повторите команду, но добавьте дефис (-) к имени эффекта:

$ kubectl taint nodes demo-node has-gpu:NoSchedule-
node/demo-node untainted

Это приведет к удалению соответствующей порчи, если она существует.

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

$ kubectl describe node demo-node
Name:   demo-node
...
Taints: env=production:NoSchedule
...

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

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

Допуски пода объявляются в поле манифеста spec.tolerations:

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: example.com/api:latest
  tolerations:
    - key: env
      operator: Equals
      value: production
      effect: NoSchedule

Этот допуск позволяет поду api планировать работу с узлами, имеющими пометку env со значением production и NoSchedule. как эффект. Пример Pod теперь можно запланировать на demo-node.

Чтобы допускать пометки без значения, вместо этого используйте оператор Exists:

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: example.com/api:latest
  tolerations:
    - key: has-gpu
      operator: Exists
      effect: NoSchedule

Pod теперь допускает пометку has-gpu независимо от того, было ли установлено значение.

Допуски не требуют, чтобы модуль был запланирован на зараженный узел. Это распространенное заблуждение относительно порчи и терпимости. Механизм говорит только о том, что Node не может размещать Pod; он не выражает альтернативного мнения о том, что Pod должен быть размещен на конкретном узле. Taints обычно сочетаются с affinities для достижения такого двунаправленного поведения.

Правила соответствия порчи и терпимости

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

Для эффекта NoExecute есть особый случай. Поды, которые допускают такое заражение, обычно остаются на узле после применения заразы. Вы можете изменить это поведение, чтобы поды добровольно выселялись через заданное время, несмотря на то, что вы допускаете эту черту:

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: example.com/api:latest
  tolerations:
    - key: env
      operator: Equals
      value: production
      effect: NoExecute
      tolerationSeconds: 900

Узел, на котором размещается этот модуль, но впоследствии зараженный env=production:NoExecute, позволит модулю оставаться доступным в течение 15 минут после применения заражения. Затем модуль будет вытеснен, несмотря на допуск NoExecute.

Автоматические порчи

Узлы автоматически искажаются плоскостью управления Kubernetes, чтобы исключить поды и предотвратить планирование, когда возникает конкуренция за ресурсы. Такие дефекты, как node.kubernetes.io/memory-pressure и node.kubernetes.io/disk-pressure, означают, что Kubernetes блокирует Node от принятия новых Pod, потому что ему не хватает Ресурсы.

Другие часто применяемые дефекты включают node.kubernetes.io/not-ready, когда новый узел не принимает модули, и node.kubernetes.io/unschedulable. Последнее применяется к оцепленным узлам, чтобы остановить всю деятельность по планированию подов.

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

Краткое содержание

Taints и tolerances — это механизм отталкивания Pod'ов от отдельных узлов Kubernetes. Они помогают избежать нежелательных результатов планирования, предотвращая автоматическое назначение модулей Pod произвольным узлам.

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




Все права защищены. © Linux-Console.net • 2019-2024