Как посмотреть taints на узле Kubernetes: руководство

Введение

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: Соответствует ключу taint
operator: Либо 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, для дальнейшей оптимизации ресурсов вашего кластера.

Как посмотреть taints, примененные к узлу Kubernetes

Введение

Настройка среды Kubernetes для тестирования

Понимание Kubernetes Taints (заражений)

Что такое Taints?

Структура Taint

Просмотр Taints на узлах Kubernetes

Метод 1: Использование kubectl describe

Метод 2: Использование kubectl get с пользовательскими столбцами

Метод 3: Использование kubectl get с JSONPath

Метод 4: Использование kubectl get с выводом YAML

Добавление и удаление Taints

Добавление Taints к узлам

Удаление Taints с узлов

Когда использовать Taints

Работа с Tolerations

Понимание Tolerations

Создание пода с Tolerations

Тестирование с подом без Tolerations

Очистка

Резюме