В статье — варианты использования расширенного планирования подов в Kubernetes, а также передовые методы его применения на практике. Информация пригодится разработчикам приложений и администраторам K8s, чтобы реализовать расширенные шаблоны развёртывания приложений, в которых есть локальность данных, совместное размещение модулей, высокая доступность и эффективное использование ресурсов кластеров K8s.
В Kubernetes задача планирования подов для определённых узлов в кластере выполняется с помощью компонента kube-scheduler. По умолчанию он фильтрует узлы на основе запросов ресурсов и ограничений каждого контейнера в созданном модуле. Затем возможные узлы оцениваются для поиска лучшей возможности для размещения пода.
Во многих сценариях планирование подов на основе ограничений ресурсов — лучший из возможных вариантов. Однако иногда администраторы Kubernetes планируют поды для опредёленных узлов в соответствии с другими вариантами ограничений. В таких случаях стоит рассматривать возможность расширенного планирования.
Допустим, что одна из меток узла — «storage = ssd», указывающая тип хранилища на узле.
kubectl describe node “host01”
Name: host01
Roles: node
Labels: storage=ssd,
Для планирования подов на узле с этой меткой указываем поле nodeSelector с ней в манифесте для пода.
apiVersion: v1
kind: Pod
metadata:
name: pod
labels:
env: dev
spec:
containers:
- name: your-container
image: your-container-image
imagePullPolicy: IfNorPresent
nodeSelector:
storage: ssd
Селекторы узлов — наиболее доступный метод расширенного планирования модулей. Однако они неэффективны в случаях, когда при планировании подов приходится учитывать дополнительные правила и условия.
Рассмотрим привязку узлов для размещения подов на узлах в определённых зонах доступности.
apiVersion: v1
kind: Pod
metadata:
name: node-affinity
spec:
affinity:
nodeAffinity
requiredDuringSchedulingIgnoreDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/cp-az-name
operator: In
values:
- cp-1a
- cp-1b
preferredDuringSchedulingIgnoreDuringExecution:
- weight: 7
preference:
matchExpressions:
- key: custom-key
operator: In
values:
- custom-value
containers:
- name: node-affinity
image: your-container-image
Жёсткие правила сродства указываются в поле “required during scheduling ignored during execution”(«Требуется во время планирования, игнорируется во время выполнения») раздела nodeAffinity в манифесте для пода. В примере планировщику было дано задание разместить модуль только на узлах с меткой, имеющей ключ kubernetes.io/cp-az-name и значения cp-1a или cp-1b.
Для этого использован логический оператор In, фильтрующий массив существующих значений меток. Другие возможные в подобных случаях операторы: NotIn, Exists, DoesNotExist, Gt и Lt.
Мягкое правило указывается в поле спецификации «Предпочитается во время планирования, игнорируется во время выполнения» (“preferred during scheduling ignored during execution”). В примере среди узлов, отвечающих жёстким критериям, используются узлы с меткой, имеющей ключ с именем custom-key и значением custom-value. Если таких узлов нет, возможно добавление подов другим кандидатам, если они соответствуют жёстким критериям.
Эффективная практика — создание правил привязки узлов таким образом, чтобы они включали как жёсткие, так и мягкие правила. Следование этому подходу максимальных усилий (использовать по возможности ту или иную опцию, но не отклонять планирование, если опция недоступна) помогает гибко и предсказуемо планировать развёртывание.
Сродство между пакетами определяется аналогично сродству узлов. В данном случае мы будем использовать поле podAffinity внутри спецификации.
apiVersion: v1
kind: Pod
metadata:
name: example-pod-affinity
spec:
affinity:
nodeAffinity
requiredDuringSchedulingIgnoreDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
containers:
- name: node-affinity
image: your-container-image
Как и сродство узла, сродство пода определяется с помощью выражений соответствия и логических операторов. Но в этом случае они применяются к селектору меток подов, работающих на определённом узле. Если указанное выражение совпадает с меткой целевого пода, новый под размещается вместе с целевым на том же компьютере.
В основном анти-сродство от пода к узлу применяется для выделенных узлов. Для управления использованием ресурсов в кластере администраторы K8s могут выделить определённые узлы для опредёленных типов подов и приложений.
Есть и другие интересные варианты использования анти-сродства между подами. Во-первых, это предотвращение единой точки отказа. Это достигается путём распределения подов в рамках одного и того же сервиса по разным машинам, что требует предотвращения совмещения подов с другими подами того же типа. Во-вторых, это предотвращение конкуренции между службами за ресурсы. Для повышения производительности некоторых сервисов их не стоит размещать вместе с другими сервисами, которые потребляют много ресурсов.
Анти-сродство от пода к узлу в Kubernetes может быть достигнуто с помощью порчи и толерантности.
По умолчанию все поды, не имеющие допусков к порче узла, будут отклонены или исключены из него. Такое поведение обеспечивает гибкость шаблонов развёртывания кластеров и приложений. Не нужно изменять спецификацию пода, если вы не хотите, чтобы он работал на определённых узлах.
Реализовать порчи и терпимости довольно просто. Для начала — добавить к узлу искажение, для которого необходимо применить нестандартное поведение при планировании:
kubectl taint nodes host2 storage=ssd:NoSchedule
node “host1” tainted
Формат порчи выглядит так: <taintKey> = <taintValue>: <taintEffect>. Эффект порчи в примере предотвращает включение любого модуля без соответствующих допусков в расписание для этого узла.
Другие поддерживаемые эффекты порчи — NoExecute и PreferNoSchedule (мягкая версия NoSchedule). При использовании эффекта PreferNoSchedule kube-scheduler попытается не размещать под модуль без требуемого допуска на испорченный узел.
Эффект NoExecute вызывает мгновенное удаление всех подов без определённого разрешения узла. Он может быть полезен, если у вас уже есть поды, запущенные на узле, которые вам больше не нужны.
Создание порчи — лишь первая часть настройки. Чтобы поды могли быть запланированы на испорченном узле, нужно добавить терпимость:
apiVersion: v1
metadata:
name: esearch
spec:
containers:
- name: esearch
image: your-es-container
resources:
requests:
cpu: 0.8
memory: 4Gi
limits:
cpu: 3.0
memory: 22Gi
tolerations:
- key: “storage”
operator: “Equal”
value: “ssd”
effect: “NoSchedule”
Терпимость для порчи добавлена с помощью оператора «Равно». Можно использовать оператор Exists, который применяет допуск к любому узлу, соответствующему ключу порчи. При этом точное значение указывать не нужно.
В этом случае используем taint storage = ssd: NoSchedule, чтобы запланировать под, определённый выше, для узла.
Первый под:
apiVersion: v1
kind: Pod
metadata:
name: s1
labels:
security: s1
spec:
containers:
- name: c1
image: first-image
Для первого пода использована метка “security: s1.”
Второй под:
apiVersion: v1
kind: Pod
metadata:
name: s2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoreDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- s1
topologyKey: kubernetes.io/hostname
containers:
- name: pod-anti-affinity
image: second-image
Второй под относится к селектору меток security: s1 в spec.affinity.podAntiAffinity. Соответственно, он не будет назначен узлу, на котором уже размещены какие-либо поды с меткой security: s1.
В таблице — ключевая информация для каждого типа ресурсов.
Обзор возможностей Kubernetes для расширенного планирования подов
Используя анти-сродство узлов и порчу, можно запускать узлы с оборудованием, выделенным для определённых приложений и сервисов, обеспечивая эффективное использование ресурсов в кластере. При помощи анти-сродства пода и анти-сродства узла возможна высокая доступность приложений с избежанием единой точки отказа: в таком случае разные компоненты будут работать на разных узлах.
Сродство и анти-сродство — две мощные концепции в Kubernetes, которые необходимо освоить каждому администратору кластера.
habr.com
В Kubernetes задача планирования подов для определённых узлов в кластере выполняется с помощью компонента kube-scheduler. По умолчанию он фильтрует узлы на основе запросов ресурсов и ограничений каждого контейнера в созданном модуле. Затем возможные узлы оцениваются для поиска лучшей возможности для размещения пода.
Во многих сценариях планирование подов на основе ограничений ресурсов — лучший из возможных вариантов. Однако иногда администраторы Kubernetes планируют поды для опредёленных узлов в соответствии с другими вариантами ограничений. В таких случаях стоит рассматривать возможность расширенного планирования.
Сценарии использования для ручного планирования доставки от пода к узлу
В производственном применении Kubernetes всегда необходима настройка распределения подов по узлам. Перечислим некоторые распространённые сценарии, при которых расширенное планирование — оптимальный вариант.- Запуск подов на узлах с выделенным оборудованием. У некоторых приложений Kubernetes особые требования к оборудованию. Поды, выполняющие задания по машинному обучению, требуют высокопроизводительных графических процессоров вместо ЦП, в то время как модули Elasticsearch более эффективны на твердотельных накопителях, чем на жёстких дисках. Лучшая практика для любого управления кластером K8s с учётом ресурсов — это назначать поды узлам с правильным оборудованием.
- Совместное размещение подов и кодовая зависимость. В настройке микросервисов или тесно связанном стеке приложений определённые поды должны быть размещены на одном компьютере, чтобы повысить производительность, избежать проблем с задержкой в сети и сбоев подключения. Рекомендуется запускать веб-сервер на том же компьютере, что и службу кэширования в памяти или базу данных.
- Локальность данных. Требования к локальности данных для приложений, интенсивно использующих данные, аналогичны предыдущему варианту использования. Для более быстрого чтения и лучшей пропускной способности записи этим приложениям требуется развёртывание баз данных на одном компьютере с клиентским приложением.
Ресурсы Kubernetes для расширенного планирования подов
Kubernetes располагает множеством ресурсов и стратегий API. Рассмотрим некоторые из них: концепции nodeSelector, сродства узлов и сродства между модулями — и покажем наглядно, как реализовать их в вашем кластере K8s.Ручное планирование подов с помощью nodeSelector
В более ранних версиях K8s пользователи могли планировать поды вручную, используя поле nodeSelector в файле PodSpec. NodeSelector — метод планирования от пода к узлу на основе меток, при котором пользователи назначают определённые метки узлам и следят за тем, чтобы поле nodeSelector соответствовало этим меткам.Допустим, что одна из меток узла — «storage = ssd», указывающая тип хранилища на узле.
kubectl describe node “host01”
Name: host01
Roles: node
Labels: storage=ssd,
Для планирования подов на узле с этой меткой указываем поле nodeSelector с ней в манифесте для пода.
apiVersion: v1
kind: Pod
metadata:
name: pod
labels:
env: dev
spec:
containers:
- name: your-container
image: your-container-image
imagePullPolicy: IfNorPresent
nodeSelector:
storage: ssd
Селекторы узлов — наиболее доступный метод расширенного планирования модулей. Однако они неэффективны в случаях, когда при планировании подов приходится учитывать дополнительные правила и условия.
Сродство узлов
Функция привязки узлов более эффективна по сравнению с ручным размещением подов. Она включает в себя функциональный язык сродства с использованием логических операторов и ограничений, обеспечивающий точный контроль над размещением подов. Язык поддерживает мягкие и жёсткие правила планирования, позволяющие контролировать строгость ограничений привязки узлов в зависимости от требований пользователя.Рассмотрим привязку узлов для размещения подов на узлах в определённых зонах доступности.
apiVersion: v1
kind: Pod
metadata:
name: node-affinity
spec:
affinity:
nodeAffinity
requiredDuringSchedulingIgnoreDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/cp-az-name
operator: In
values:
- cp-1a
- cp-1b
preferredDuringSchedulingIgnoreDuringExecution:
- weight: 7
preference:
matchExpressions:
- key: custom-key
operator: In
values:
- custom-value
containers:
- name: node-affinity
image: your-container-image
Жёсткие правила сродства указываются в поле “required during scheduling ignored during execution”(«Требуется во время планирования, игнорируется во время выполнения») раздела nodeAffinity в манифесте для пода. В примере планировщику было дано задание разместить модуль только на узлах с меткой, имеющей ключ kubernetes.io/cp-az-name и значения cp-1a или cp-1b.
Для этого использован логический оператор In, фильтрующий массив существующих значений меток. Другие возможные в подобных случаях операторы: NotIn, Exists, DoesNotExist, Gt и Lt.
Мягкое правило указывается в поле спецификации «Предпочитается во время планирования, игнорируется во время выполнения» (“preferred during scheduling ignored during execution”). В примере среди узлов, отвечающих жёстким критериям, используются узлы с меткой, имеющей ключ с именем custom-key и значением custom-value. Если таких узлов нет, возможно добавление подов другим кандидатам, если они соответствуют жёстким критериям.
Эффективная практика — создание правил привязки узлов таким образом, чтобы они включали как жёсткие, так и мягкие правила. Следование этому подходу максимальных усилий (использовать по возможности ту или иную опцию, но не отклонять планирование, если опция недоступна) помогает гибко и предсказуемо планировать развёртывание.
Межподовое сродство
Сродство в Kubernetes — это функция, служащая для планирования подов на основе их отношения к другим подам. Сродство позволяет использовать различные интересные варианты, такие как совместное размещение подов в рамках созависимой службы (служб) или реализация локальности данных, при которой поды данных работают на том же компьютере, что и основной под службы.Сродство между пакетами определяется аналогично сродству узлов. В данном случае мы будем использовать поле podAffinity внутри спецификации.
apiVersion: v1
kind: Pod
metadata:
name: example-pod-affinity
spec:
affinity:
nodeAffinity
requiredDuringSchedulingIgnoreDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
containers:
- name: node-affinity
image: your-container-image
Как и сродство узла, сродство пода определяется с помощью выражений соответствия и логических операторов. Но в этом случае они применяются к селектору меток подов, работающих на определённом узле. Если указанное выражение совпадает с меткой целевого пода, новый под размещается вместе с целевым на том же компьютере.
Анти-сродство
Иногда предпочтительнее использовать метод чёрного списка для планирования пакетов. Такой подход препятствует планированию подов на определённых узлах при невыполнении опредёленных условий. Такая концепция называется анти-сродством Kubernetes.В основном анти-сродство от пода к узлу применяется для выделенных узлов. Для управления использованием ресурсов в кластере администраторы K8s могут выделить определённые узлы для опредёленных типов подов и приложений.
Есть и другие интересные варианты использования анти-сродства между подами. Во-первых, это предотвращение единой точки отказа. Это достигается путём распределения подов в рамках одного и того же сервиса по разным машинам, что требует предотвращения совмещения подов с другими подами того же типа. Во-вторых, это предотвращение конкуренции между службами за ресурсы. Для повышения производительности некоторых сервисов их не стоит размещать вместе с другими сервисами, которые потребляют много ресурсов.
Анти-сродство от пода к узлу в Kubernetes может быть достигнуто с помощью порчи и толерантности.
Порча и терпимость
Ошибки, условия и допуски помогают пользователю контролировать планирование подов для определённых узлов без изменения уже существующих.По умолчанию все поды, не имеющие допусков к порче узла, будут отклонены или исключены из него. Такое поведение обеспечивает гибкость шаблонов развёртывания кластеров и приложений. Не нужно изменять спецификацию пода, если вы не хотите, чтобы он работал на определённых узлах.
Реализовать порчи и терпимости довольно просто. Для начала — добавить к узлу искажение, для которого необходимо применить нестандартное поведение при планировании:
kubectl taint nodes host2 storage=ssd:NoSchedule
node “host1” tainted
Формат порчи выглядит так: <taintKey> = <taintValue>: <taintEffect>. Эффект порчи в примере предотвращает включение любого модуля без соответствующих допусков в расписание для этого узла.
Другие поддерживаемые эффекты порчи — NoExecute и PreferNoSchedule (мягкая версия NoSchedule). При использовании эффекта PreferNoSchedule kube-scheduler попытается не размещать под модуль без требуемого допуска на испорченный узел.
Эффект NoExecute вызывает мгновенное удаление всех подов без определённого разрешения узла. Он может быть полезен, если у вас уже есть поды, запущенные на узле, которые вам больше не нужны.
Создание порчи — лишь первая часть настройки. Чтобы поды могли быть запланированы на испорченном узле, нужно добавить терпимость:
apiVersion: v1
metadata:
name: esearch
spec:
containers:
- name: esearch
image: your-es-container
resources:
requests:
cpu: 0.8
memory: 4Gi
limits:
cpu: 3.0
memory: 22Gi
tolerations:
- key: “storage”
operator: “Equal”
value: “ssd”
effect: “NoSchedule”
Терпимость для порчи добавлена с помощью оператора «Равно». Можно использовать оператор Exists, который применяет допуск к любому узлу, соответствующему ключу порчи. При этом точное значение указывать не нужно.
В этом случае используем taint storage = ssd: NoSchedule, чтобы запланировать под, определённый выше, для узла.
Анти-сродство подов
Также можно отделять поды друг от друга с помощью функции анти-сродства. Одна из лучших практик, доступных Kubernetes — избегание единой точки отказа с распределением подов по разным зонам доступности. Можно настроить аналогичное поведение в анти-сродстве для части спецификации пода. Для анти-сродства нам понадобятся два пода.Первый под:
apiVersion: v1
kind: Pod
metadata:
name: s1
labels:
security: s1
spec:
containers:
- name: c1
image: first-image
Для первого пода использована метка “security: s1.”
Второй под:
apiVersion: v1
kind: Pod
metadata:
name: s2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoreDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- s1
topologyKey: kubernetes.io/hostname
containers:
- name: pod-anti-affinity
image: second-image
Второй под относится к селектору меток security: s1 в spec.affinity.podAntiAffinity. Соответственно, он не будет назначен узлу, на котором уже размещены какие-либо поды с меткой security: s1.
Заключение
Расширенное планирование подов позволяет использовать множество интересных вариантов и продвинутых практик для развёртывания сложных приложений и микросервисов в Kubernetes. С помощью привязки подов реализуется их размещение и локализация данных для тесно связанных стеков приложений и микросервисов.В таблице — ключевая информация для каждого типа ресурсов.
Обзор возможностей Kubernetes для расширенного планирования подов
| Тип ресурса | Когда используется | Достоинства | Недостатки | Оптимальные сферы применения |
| nodeSelector | Назначение подов узлам с определёнными метками | Простота использова-ния, незначитель-ные изменения в PodSpec | Отсутствие поддержки логических операторов, ограниченные возможности расширения с помощью сложных правил планирования | Только в ранних версиях K8s, не поддержива-ющих сродство узлов |
| Сродство узлов | Реализация локальности данных, запуск модулей на узлах с помощью специального программного обеспечения. | Функциональ-ный синтаксис с поддержкой логических операторов, детальный контроль над правилами размещения подов, поддержка жёстких и мягких правил размещения подов | Необходи-мость модификации существующих подов для изменения поведения | Сочетание жёстких и мягких правил для охвата различных вариантов использова-ния и сценариев |
| Сродство подов | Размещение модулей в зависимой службе, обеспечива-ющей локальность данных | Аналогично сродству узлов | Необходи-мость модификации существующих подов для изменения поведения | Правильное управление метками в подах и документи-рование используемых меток |
| Анти-сродство подов | Обеспечение высокой доступности через распростране-ние пакетов, предотвраще-ние конкуренции между сервисами за ресурсы | Развёрнутый контроль над отторжением подов, поддержка жёстких и мягких правил анти-сродства подов | Необходи-мость модификации существующих подов для изменения поведения | Аналогично сродству узлов |
| Порча и терпимость | Узлы с выделенным программным обеспечением, разделение ресурсов команды | Отсутствие необходи-мости модификации существующих подов, поддержка автоматического удаления подов без требуемой терпимости, поддержка различных эффектов порчи | Отсутствие поддержки синтаксиса с логическими операторами | Необходимо быть осторожными при нанесении нескольких порч на узел. Важно убедиться, что нужные поды имеют требуемые уровни терпимости |
Сродство и анти-сродство — две мощные концепции в Kubernetes, которые необходимо освоить каждому администратору кластера.
Планирование подов для узлов Kubernetes: развёрнутое руководство
В статье — варианты использования расширенного планирования подов в Kubernetes, а также передовые методы его применения на практике. Информация пригодится разработчикам приложений и администраторам...
habr.com