Введение
Kubernetes, популярная платформа оркестрации контейнеров, предоставляет мощную функцию под названием "taints" (заражения) для управления планированием подов на узлах. В этом руководстве мы рассмотрим, как просматривать taints, примененные к узлам Kubernetes, что является важным навыком для эффективного управления вашим кластером Kubernetes.
Taints позволяют вам помечать узлы определенными атрибутами, которые могут отталкивать определенные поды, обеспечивая правильное планирование рабочих нагрузок на основе возможностей и ресурсов узла. Понимание того, как просматривать и работать с taints, помогает вам поддерживать оптимальное распределение ресурсов в вашей среде Kubernetes.
Настройка среды Kubernetes для тестирования
Прежде чем мы сможем просмотреть taints на узлах Kubernetes, нам потребуется функционирующая среда Kubernetes. Для этого руководства мы будем использовать Minikube, который предоставляет облегченный локальный кластер Kubernetes для целей разработки и тестирования.
Давайте начнем с установки Minikube:
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
rm minikube-linux-amd64
Теперь, когда Minikube установлен, давайте запустим кластер Kubernetes:
minikube start --driver=docker
Вы должны увидеть вывод, похожий на этот:
😄 minikube v1.29.0 on Ubuntu 22.04
✨ Using the docker driver based on user configuration
📌 Using Docker driver with root privileges
👍 Starting control plane node minikube in cluster minikube
🚜 Pulling base image ...
🔥 Creating docker container (CPUs=2, Memory=2200MB) ...
🐳 Preparing Kubernetes v1.26.1 on Docker 23.0.1 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: default-storageclass, storage-provisioner
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
Давайте убедимся, что кластер запущен, проверив статус узлов:
kubectl get nodes
Вы должны увидеть вывод, похожий на этот:
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 1m v1.26.1
Отлично! Теперь у нас есть функционирующая среда Kubernetes для изучения taints. Команда kubectl уже настроена для работы с нашим кластером Minikube.
Понимание Kubernetes Taints (заражений)
Прежде чем мы начнем просматривать taints, давайте разберемся, что это такое и как они работают в Kubernetes.
Что такое Taints?
Taints - это свойства, применяемые к узлам Kubernetes, которые позволяют узлу отталкивать определенные поды. Думайте о taints как о метках, которые помечают узлы как неподходящие для определенных типов рабочих нагрузок.
Taints работают вместе с концепцией, называемой "tolerations" (допусками). В то время как taints применяются к узлам, tolerations применяются к подам. Под с toleration, соответствующим taint узла, может быть запланирован на этом зараженном узле.
Структура Taint
Taints состоят из трех компонентов:
- Key (ключ): Строка, которая идентифицирует taint (например,
gpu,disk,network) - Value (значение): Необязательная строка, присвоенная ключу (например,
true,high-performance) - Effect (эффект): Определяет, как обрабатываются поды без соответствующих tolerations
Наиболее распространенные эффекты taint:
NoSchedule: Новые поды без соответствующих tolerations не будут запланированы на узлеPreferNoSchedule: Система попытается избежать размещения подов без соответствующих tolerations на узле, но это не гарантируетсяNoExecute: Новые поды без соответствующих tolerations не будут запланированы на узле, а существующие поды без соответствующих tolerations будут выселены
Вот синтаксис для taint:
- С значением:
key=value:effect - Без значения:
key:effect
Некоторые узлы в кластере Kubernetes имеют taints по умолчанию. Например, узлы плоскости управления (control plane) часто заражаются с помощью node-role.kubernetes.io/control-plane:NoSchedule, чтобы предотвратить планирование обычных рабочих нагрузок на них, сохраняя ресурсы для системных компонентов.
Давайте рассмотрим наш узел Minikube, чтобы увидеть, есть ли у него какие-либо taints по умолчанию:
kubectl describe node minikube | grep -A3 Taints
Вы, вероятно, увидите вывод, похожий на:
Taints: node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable: false
Lease:
HolderIdentity: minikube
Этот вывод показывает, что наш узел Minikube имеет taint, который предотвращает планирование обычных подов на нем, поскольку это узел плоскости управления.
Просмотр Taints на узлах Kubernetes
Теперь, когда мы понимаем, что такое taints, давайте рассмотрим различные методы просмотра taints, примененных к узлам Kubernetes.
Метод 1: Использование kubectl describe
Наиболее подробный способ просмотра taints на узле - использование команды kubectl describe node:
kubectl describe node minikube
Эта команда выводит исчерпывающую информацию об узле. Чтобы сосредоточиться только на taints, вы можете использовать grep:
kubectl describe node minikube | grep -A1 Taints
Пример вывода:
Taints: node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable: false
Метод 2: Использование kubectl get с пользовательскими столбцами
Вы можете использовать команду kubectl get nodes с пользовательскими столбцами вывода, чтобы отобразить только taints:
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints
Пример вывода:
NAME TAINTS
minikube [map[effect:NoSchedule key:node-role.kubernetes.io/control-plane]]
Метод 3: Использование kubectl get с JSONPath
Другой подход - использовать JSONPath для извлечения информации о taint:
kubectl get nodes minikube -o jsonpath='{.spec.taints}'
Пример вывода:
[{"effect":"NoSchedule","key":"node-role.kubernetes.io/control-plane"}]
Для лучшей читаемости вы можете отформатировать вывод как JSON:
kubectl get nodes minikube -o jsonpath='{.spec.taints}' | jq .
Если у вас не установлен jq, вы можете установить его с помощью:
sudo apt-get update && sudo apt-get install -y jq
Пример форматированного вывода:
[
{
"effect": "NoSchedule",
"key": "node-role.kubernetes.io/control-plane"
}
]
Метод 4: Использование kubectl get с выводом YAML
Вы также можете просмотреть полную спецификацию узла в формате YAML и выполнить поиск taints:
kubectl get node minikube -o yaml | grep -A5 taints:
Пример вывода:
taints:
- effect: NoSchedule
key: node-role.kubernetes.io/control-plane
unschedulable: false
status:
addresses:
Каждый из этих методов предоставляет одну и ту же информацию в разных форматах. Выберите тот, который лучше всего соответствует вашим потребностям, основываясь на читаемости и том, как вы планируете использовать информацию.
Добавление и удаление Taints
Теперь, когда мы знаем, как просматривать taints, давайте узнаем, как их добавлять и удалять. Это распространенная операция, когда вам нужно контролировать планирование подов или подготовить узлы к обслуживанию.
Добавление Taints к узлам
Синтаксис для добавления taint к узлу:
kubectl taint nodes <node-name> <key>=<value>:<effect>
Давайте добавим taint к нашему узлу Minikube, чтобы пометить его как имеющий GPU:
kubectl taint nodes minikube gpu=true:NoSchedule
Вы должны увидеть вывод, подобный:
node/minikube tainted
Теперь давайте убедимся, что taint был добавлен:
kubectl describe node minikube | grep -A3 Taints
Пример вывода:
Taints: gpu=true:NoSchedule
node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable: false
Lease:
Как видите, наш узел теперь имеет два taints: исходный taint control-plane и наш новый taint GPU.
Удаление Taints с узлов
Чтобы удалить taint, вы добавляете знак минус (-) к тому же определению taint:
kubectl taint nodes <node-name> <key>=<value>:<effect>-
Давайте удалим taint GPU, который мы только что добавили:
kubectl taint nodes minikube gpu=true:NoSchedule-
Вы должны увидеть вывод, подобный:
node/minikube untainted
Давайте убедимся, что taint был удален:
kubectl describe node minikube | grep -A3 Taints
Пример вывода:
Taints: node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable: false
Lease:
HolderIdentity: minikube
Теперь наш узел снова имеет только taint control-plane.
Когда использовать Taints
Taints особенно полезны в нескольких сценариях:
- Специализированное оборудование: Заражение узлов специализированным оборудованием (например, GPU), чтобы гарантировать, что только рабочие нагрузки, требующие этого оборудования, будут запланированы там.
- Обслуживание узлов: Добавление taint перед выполнением обслуживания, чтобы предотвратить планирование новых подов.
- Изоляция безопасности: Разделение определенных рабочих нагрузок от других по соображениям безопасности.
- Оптимизация ресурсов: Выделение узлов для конкретных типов рабочих нагрузок для оптимального использования ресурсов.
Понимая, как просматривать, добавлять и удалять taints, вы получили фундаментальные знания для управления планированием подов в вашем кластере Kubernetes.
Работа с Tolerations
Теперь, когда мы понимаем, как работают taints, давайте рассмотрим tolerations - механизм, который позволяет планировать поды на узлах с соответствующими taints.
Понимание Tolerations
Tolerations указываются в спецификациях подов и позволяют планировать поды на узлах с соответствующими taints. Toleration состоит из:
key: Соответствует ключу taintoperator: ЛибоEqual(соответствует ключу и значению), либоExists(соответствует только ключу)value: Значение для сопоставления (при использовании оператораEqual)effect: Эффект для сопоставления или пустой для сопоставления всех эффектовtolerationSeconds: Необязательная продолжительность, в течение которой под может оставаться на узле с соответствующим taint NoExecute
Создание пода с Tolerations
Давайте создадим под, который допускает наш taint control-plane. Сначала создадим YAML-файл для нашего пода:
nano ~/project/toleration-pod.yaml
Теперь добавьте следующее содержимое в файл:
apiVersion: v1
kind: Pod
metadata:
name: toleration-pod
spec:
containers:
- name: nginx
image: nginx:latest
tolerations:
- key: "node-role.kubernetes.io/control-plane"
operator: "Exists"
effect: "NoSchedule"
Эта спецификация пода включает в себя toleration, которая соответствует taint control-plane на нашем узле. Сохраните и выйдите из файла (в nano нажмите Ctrl+O, Enter, затем Ctrl+X).
Теперь давайте создадим под:
kubectl apply -f ~/project/toleration-pod.yaml
Вы должны увидеть вывод, подобный:
pod/toleration-pod created
Давайте проверим, был ли под запланирован на нашем узле:
kubectl get pods -o wide
Пример вывода:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
toleration-pod 1/1 Running 0 12s 10.244.0.5 minikube <none> <none>
Под работает на нашем узле minikube, потому что у него есть toleration, соответствующая taint control-plane.
Тестирование с подом без Tolerations
Для сравнения давайте создадим под без tolerations:
nano ~/project/no-toleration-pod.yaml
Добавьте следующее содержимое:
apiVersion: v1
kind: Pod
metadata:
name: no-toleration-pod
spec:
containers:
- name: nginx
image: nginx:latest
Сохраните и выйдите из файла, затем создайте под:
kubectl apply -f ~/project/no-toleration-pod.yaml
Теперь давайте проверим статус пода:
kubectl get pods -o wide
Вы можете заметить, что под остается в состоянии Pending:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
no-toleration-pod 0/1 Pending 0 12s <none> <none> <none> <none>
toleration-pod 1/1 Running 0 2m 10.244.0.5 minikube <none> <none>
Давайте проверим, почему под находится в состоянии Pending:
kubectl describe pod no-toleration-pod
В разделе событий вы должны увидеть что-то вроде:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 45s default-scheduler 0/1 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.
Это подтверждает, что под не может быть запланирован, потому что он не допускает taint control-plane.
Очистка
Давайте очистим поды, которые мы создали:
kubectl delete pod toleration-pod no-toleration-pod
Вы должны увидеть:
pod "toleration-pod" deleted
pod "no-toleration-pod" deleted
Поздравляем! Теперь вы понимаете, как taints и tolerations работают вместе, чтобы контролировать планирование подов в Kubernetes.
Резюме
В этой практической лабораторной работе вы узнали, как работать с Kubernetes taints и tolerations, ключевыми функциями для управления планированием подов в вашем кластере. Вот что вы сделали:
- Настроили среду Kubernetes с использованием Minikube
- Поняли концепцию taints и их влияние на планирование подов
- Изучили различные методы просмотра taints на узлах Kubernetes
- Добавили и удалили taints с узлов, используя команды kubectl
- Создали поды с и без tolerations, чтобы увидеть, как они взаимодействуют с помеченными узлами
Эти навыки необходимы для управления размещением рабочих нагрузок и распределением ресурсов в кластерах Kubernetes. Правильно используя taints и tolerations, вы можете гарантировать, что поды будут запланированы на соответствующих узлах в зависимости от требований к оборудованию, характеристик рабочей нагрузки и ограничений по ресурсам.
Продолжая свой путь в Kubernetes, вы можете опираться на эти знания, чтобы реализовать более сложные стратегии планирования, такие как node affinity и anti-affinity, для дальнейшей оптимизации ресурсов вашего кластера.


