Как удалить ноду из кластера Kubernetes

Удаление ноды из кластера Kubernetes

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

Основные этапы удаления ноды

1. Дренирование (drain) ноды — это критически важный шаг, который позволяет безопасно завершить работу подов на удаляемой ноде, переместив их на другие узлы в кластере. Команда kubectl drain выполняет следующие действия:

   • Помечает ноду как недоступную для планирования новых подов.
   • Эвакуирует (удаляет и пересоздаёт) поды с ноды, учитывая политики управления подами (например, для DaemonSet поды не будут перемещены, если не указана опция --ignore-daemonsets).

   Пример команды для дренирования ноды:

   kubectl drain <node-name> --ignore-daemonsets --delete-local-data
   

   Где:

   • --ignore-daemonsets игнорирует поды DaemonSet, которые обычно не могут быть перемещены.
   • --delete-local-data удаляет данные из подов, использующих emptyDir (только если это безопасно для приложения).

2. Ожидание завершения работы подов — после дренирования необходимо убедиться, что все поды (кроме DaemonSet) были успешно перемещены. Проверить состояние можно командой:

   kubectl get pods --all-namespaces --field-selector spec.nodeName=<node-name>
   

   В выводе не должно быть пользовательских подов, только системные (например, от DaemonSet).

3. Удаление ноды из кластера — после завершения дренирования нода удаляется из API Kubernetes:

   kubectl delete node <node-name>
   

   Эта команда удаляет объект ноды из etcd, но не затрагивает саму физическую или виртуальную машину.

Дополнительные шаги и рекомендации

• Очистка на самой ноде: После удаления из кластера необходимо выполнить очистку на самой ноде, чтобы избежать конфликтов при возможном повторном добавлении:

  sudo kubeadm reset
  

  Эта команда сбрасывает состояние kubeadm, удаляет конфигурации и сетевые интерфейсы, связанные с Kubernetes.

• Освобождение ресурсов: Если нода управляется облачным провайдером (например, в GKE, EKS или AKS), удаление может быть интегрировано с системой автомасштабирования. В таких средах часто используется управление нодами через NodePool или группы инстансов, где удаление из Kubernetes триггерит депровизионинг инфраструктуры.

• Безопасное удаление для Stateful-приложений: Если на ноде работали поды с состоянием (например, базы данных), убедитесь, что репликация данных настроена корректно перед дренированием, чтобы не произошло потери данных.

Пример полного процесса в виде скрипта

#!/bin/bash
NODE_NAME="worker-node-01"

# Шаг 1: Дренирование ноды
echo "Дренируем ноду $NODE_NAME..."
kubectl drain $NODE_NAME --ignore-daemonsets --delete-local-data --timeout=300s

# Шаг 2: Проверка, что поды перемещены
echo "Проверяем оставшиеся поды на ноде..."
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=$NODE_NAME

# Шаг 3: Удаление ноды из кластера
echo "Удаляем ноду $NODE_NAME из кластера..."
kubectl delete node $NODE_NAME

# Шаг 4: Очистка на самой ноде (выполняется на удаляемой ноде)
ssh $NODE_NAME "sudo kubeadm reset --force"

Потенциальные проблемы и их решение

• Поды в состоянии Pending: Если поды не могут быть перемещены из-за недостатка ресурсов на других нодах, необходимо масштабировать кластер или проверить ResourceQuotas.
• DaemonSet поды: Они остаются на ноде даже после дренирования — это нормально, так как DaemonSet предназначены для работы на всех нодах. Их можно игнорировать или удалить вручную, если это необходимо.
• Нарушение политик PodDisruptionBudget (PDB): Если для приложения настроен PDB, дренирование может быть заблокировано. В этом случае нужно проверить PDB и, при необходимости, временно изменить его или дождаться подходящего момента для удаления.

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