Как перенести все сервисы с worker-ноды на другие ноды

Стратегия переноса сервисов с рабочей ноды Kubernetes

Перемещение всех сервисов с одной рабочей ноды (worker node) на другие узлы кластера — это операция, которую выполняют для обслуживания, обновления, устранения проблем или масштабирования. Для безопасного переноса без нарушения доступности сервисов применяется комбинация методов управления узлами и объектами Kubernetes.

Основные методы переноса

1. Кордон (Cordon) и декордон (Uncordon) узла

Это базовый метод, который делает ноду недоступной для новых Pod'ов, но не затрагивает существующие.

# Запретить размещение новых Pod'ов на ноде node-01
kubectl cordon node-01

# После переноса всех сервисов разрешить размещение обратно
kubectl uncordon node-01

2. Drain (Освобождение) узла

Ключевой метод для полного переноса. Он кордонит ноду и затем эвакуирует все Pod'ы (с соблюдением политик контроллеров, например, ReplicaSet).

# Эвакуировать все Pod'ы с ноды node-01, учитывая политики
kubectl drain node-01 --ignore-daemonsets --delete-emptydir-data

• --ignore-daemonsets: игнорирует DaemonSet Pod'ы (они обычно специфичны для ноды и не должны перемещаться).
• --delete-emptydir-data: удаляет данные из временных хранилищ типа emptyDir.

Планирование и выполнение переноса

Для комплексного переноса всех сервисов важно учитывать типы контроллеров:

1. Статические Pod'ы и DaemonSets: Их перенос часто невозможен или требует особых действий (например, обновления манифеста DaemonSet). При drain используйте флаг --ignore-daemonsets.
2. Pod'ы от Deployment, StatefulSet, ReplicaSet: Контроллеры автоматически создадут новые Pod'ы на других нодах при drain. Важно убедиться, что в кластере есть достаточная capacity (ресурсы) и tolerations (толеранции к taint'ам), чтобы Pod'ы могли разместиться.
3. Pod'ы с локальными storage (emptyDir): При drain данные будут потеряны. Используйте флаг --delete-emptydir-data сознательно.
4. Pod'ы с привязкой к ноде (nodeSelector, nodeAffinity): Если правила привязывают Pod к конкретной ноде, их перенос будет невозможен без изменения манифеста. Проверьте перед операцией:

   kubectl get pods --all-namespaces -o wide | grep node-01
   kubectl describe pod <pod-name> | grep -A5 -B5 "Node-Selectors"
   

Пошаговый план безопасного переноса

Шаг 1: Предварительный анализ

• Проверить ресурсы других нод (kubectl describe nodes).
• Идентифицировать типы Pod'ов на целевой ноде.
• Определить критичные сервисы и их требования к переносу.

Шаг 2: Последовательный drain (для больших кластеров) Если нода содержит много сервисов, можно drain'ить не всю ноду сразу, а применять taints и tolerations для управляемого переноса. Например, добавить taint и постепенно добавлять tolerations в Deployment'ы.

Шаг 3: Мониторинг после переноса После выполнения kubectl drain отслеживайте состояние кластера:

# Проверить, что Pod'ы перешли в состояние Running на других нодах
kubectl get pods --all-namespaces -o wide

# Проверить статус ноды (должен быть Ready,SchedulingDisabled)
kubectl get node node-01

Шаг 4: Восстановление ноды После обслуживания ноды верните её в кластер:

kubectl uncordon node-01

Альтернативные и дополнительные стратегии

• Обновление манифестов: Для сервисов, которые нельзя drain'ить автоматически (например, с жестким nodeAffinity), можно обновить Deployment или StatefulSet, временно удалив привязку к ноде.
• Горячее резервирование: Если требуется максимальная доступность, убедитесь, что у критичных сервисов настроены PodDisruptionBudgets (PDB). Drain будет соблюдать PDB.

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: my-app-pdb
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        app: my-critical-app
  

• Инструменты кластерного управления: В больших инфраструктурах используют дополнительные инструменты (например, cluster-autoscaler) для автоматического масштабирования во время переноса, если ресурсов недостаточно.

Ключевые рекомендации

• Планируйте операцию в период низкой нагрузки.
• Используйте drain с флагами для DaemonSet и локального хранилища.
• Мониторинг — обязателен: следите за метриками кластера (CPU/Мем, количество Pod'ов) во время и после операции.
• Тестируйте на не критичных нодах перед операцией на важных узлах.

Перенос всех сервисов с одной ноды — управляемая операция, если вы правильно используете механизмы cordon, drain и учитываете специфику объектов Kubernetes, управляющих вашими Pod'ами. Главная цель — обеспечить непрерывность сервисов и контролируемое состояние кластера.