Обслуживание узла

Введение

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

Представьте, что узел — это номер в отеле, а поды — гости. Если вам нужно отремонтировать номер, нельзя просто войти в него, пока гости спят. Нужен вежливый и безопасный процесс.

В этой лабораторной работе вы изучите стандартный порядок обслуживания узла:

• Cordon (не беспокоить): повесить на дверь табличку «Новых гостей не размещать». Отель (планировщик) перестаёт направлять новых гостей в этот номер.
• Drain (выселить): вежливо попросить текущих гостей уйти и переселить их в другой доступный номер.
• Обслуживание: выполнить необходимые работы — например, ремонт.
• Uncordon (открыть): снять табличку и снова разрешить планирование.

Для имитации этого процесса вы будете работать с локальным кластером Minikube.

Запретить планирование на узле

Перед началом обслуживания необходимо убедиться, что планировщик Kubernetes не размещает новые поды на узле, с которым мы собираемся работать. Этот процесс называется «cordon». Он похож на размещение на двери номера таблички «Не беспокоить» или «Номер временно закрыт».

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

Сначала определите имя узла. Выполните следующую команду:

kubectl get nodes

В выводе должен отображаться один узел, например minikube, со статусом Ready.

Чтобы пометить узел как недоступный для планирования, используйте команду cordon. Подстановка команды $() автоматически получит имя узла:

kubectl cordon $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')

Снова проверьте статус узла:

kubectl get nodes

Статус должен измениться на Ready,SchedulingDisabled. Это подтверждает, что для узла выполнен cordon. Новые поды не будут размещаться на этом узле, но уже запущенные поды продолжат работать.

Освободить узел

Cordon останавливает размещение только новых подов. В номере всё ещё работают приложения — наши «гости». Чтобы безопасно удалить их с узла, используйте команду drain.

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

Здесь важно слово «выселяет». Drain не предназначен для принудительной остановки приложений. Он просит рабочие нагрузки корректно покинуть узел с учётом особенностей Kubernetes, чтобы контроллеры могли создать им замену, а правила завершения работы соблюдались. Поэтому drain безопаснее, чем вручную удалять случайные процессы на узле.

Выполните команду drain. В этой среде необходимо добавить несколько параметров, чтобы принудительно выполнить выселение:

• --ignore-daemonsets: некоторые системные поды (DaemonSet) привязаны к узлу и не могут быть перемещены. Мы игнорируем их.
• --delete-emptydir-data: если под использует локальное временное хранилище, drain удалит эти данные. Мы подтверждаем это поведение.
• --force: этот параметр требуется для удаления подов, которыми не управляют ReplicationController, ReplicaSet, Job, DaemonSet или StatefulSet, например storage-provisioner в Minikube.

kubectl drain $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}') --ignore-daemonsets --delete-emptydir-data --force

В выводе появятся сообщения о выселении подов.

Примечание: в этой лабораторной работе используется одноузловой Minikube. Поэтому при освобождении единственного узла поды будут выселены, но перейдут в состояние Pending. Это происходит потому, что их некуда переселить — «в отеле нет других номеров». В реальном многоузловом кластере они сразу переместились бы на исправный узел.

Проверить состояние

После освобождения узла важно проверить, что произошло с приложениями.

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

Проверьте состояние подов:

kubectl get pods

Как уже упоминалось, скорее всего, поды будут находиться в состоянии Pending.

Чтобы понять причину этого состояния, запросите сведения у Kubernetes. Выведите описание одного из подов:

kubectl describe pod $(kubectl get pods -o jsonpath='{.items[0].metadata.name}')

В нижней части вывода найдите раздел Events. Вы должны увидеть сообщение, похожее на «0/1 nodes are available: 1 node(s) are unschedulable».

Это подтверждает, что освобождение узла выполнено успешно. Планировщик хочет запустить под, но соблюдает установленную нами на единственном доступном узле табличку «Не беспокоить».

Снова разрешить планирование на узле

Представьте, что вы закончили «ремонт» — обновление ОС или другое обслуживание. Теперь нужно снова открыть номер и вернуть узел в рабочее состояние.

Команда uncordon просто снимает блокировку планирования. Она не заставляет поды немедленно переместиться на узел. Команда сообщает планировщику, что узел снова доступен для будущего размещения, после чего начинает работать обычный механизм согласования состояния.

Для этого используйте команду uncordon. Она снимает табличку «Не беспокоить».

kubectl uncordon $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')

Теперь проверьте состояние узла:

kubectl get nodes

Статус должен снова стать Ready — метка SchedulingDisabled должна исчезнуть.

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

kubectl get pods

Вы должны увидеть, как их состояние меняется с Pending на ContainerCreating, а затем на Running.

Итоги

В этой лабораторной работе вы изучили безопасный жизненный цикл обслуживания узла Kubernetes. Вы научились:

1. Выполнять cordon узла, чтобы пометить его как недоступный для планирования («Не беспокоить»).
2. Выполнять drain узла, чтобы безопасно выселить запущенные рабочие нагрузки.
3. Выполнять uncordon узла, чтобы вернуть его в рабочее состояние.

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