Что произойдет с подами, если отвалится etcd в kubernetes?

Влияние сбоя etcd на работоспособность кластера Kubernetes

Etcd — это распределенное, отказоустойчивое key-value хранилище, которое выступает в роли единого источника истины (single source of truth) для всего кластера Kubernetes. В нем хранится вся критическая информация о состоянии кластера: объекты (поды, сервисы, деплойменты, конфигурации), информация о нодах, назначения pod'ов, секреты и конфигурации. Поэтому сбой etcd — это одно из самых серьезных событий, способных парализовать работу всего кластера.

Что конкретно произойдет с подами?

1. Существующие поды (уже запущенные на нодах)

• Продолжат работу без изменений. Это ключевой момент. Поды — это процессы, запущенные на рабочих нодах (Worker Nodes). Управление жизненным циклом контейнеров внутри пода выполняет kubelet на каждой ноде, используя локально кэшированную информацию (Pod Spec). Пока нода жива и kubelet функционирует, контейнеры будут работать, обслуживать трафик и выполнять свои задачи.
• Станут "осиротевшими" (orphaned) с точки зрения плоскости управления. API Server больше не сможет получать информацию об их текущем состоянии, так как лишился возможности читать данные из etcd. В веб-интерфейсе (например, в Dashboard) или по команде kubectl get pods информация о этих подах перестанет обновляться и, скорее всего, пропадет.

2. Управление подами (операции через API Server)

• Все операции управления через kubectl или API будут невозможны. API Server полностью зависит от etcd для хранения и извлечения состояния. При недоступности etcd любой запрос на создание, удаление, масштабирование или обновление пода (и любого другого ресурса) завершится ошибкой. Типичная ошибка: The connection to the server <server>:6443 was refused - did you specify the right host or port? или etcdserver: leader changed.
• Нельзя создать новые поды. Запросы на создание Deployment, StatefulSet, Job или просто Pod будут отклонены.
• Нельзя удалить или изменить существующие поды. Команды kubectl delete, kubectl edit, kubectl scale не сработают.
• Самовосстановление (self-healing) перестанет работать. Если под упадет на ноде, контроллер (например, ReplicaSet Controller), отвечающий за поддержание желаемого количества реплик, не сможет зафиксировать это изменение в etcd и, следовательно, не отдаст команду на создание нового пода. Система не сможет реагировать на сбои.

3. Сервисы и сетевое взаимодействие

• Сетевое взаимодействие между подами через Service продолжится. kube-proxy на каждой ноде управляет правилами iptables или IPVS на основе информации, которую он получил от API Server до сбоя. Эти правила статичны и будут продолжать перенаправлять трафик на IP-адреса существующих подов. CoreDNS также будет использовать кэшированные записи.
• Обновление Endpoint'ов прекратится. Если IP-адрес пода изменится (что невозможно без перезапуска пода, который сейчас тоже невозможен) или появится новый под для Service, эти изменения не попадут в etcd, и сетевые правила не будут обновлены. Новые сервисы создать нельзя.

Пример состояния API Server при сбое etcd

Запрос к API Server, когда etcd недоступен, может выглядеть так (в логах самого API Server):

# Логи kube-apiserver
E0301 10:00:00.123456   12345 status.go:71] "apiserver received an error that is not an metav1.Status"
grpc: the client connection is closing
failed to check if etcd cluster has enough space, error: context deadline exceeded

А команда kubectl просто не получит ответа или вернет ошибку 500/503.

Длительность сбоя и процедура восстановления

• Кратковременный сбой (секунды-минуты): Если это отказ одного члена etcd в кластере (при корректно настроенной отказоустойчивости, например, 3 или 5 нодах), кворум сохранится, кластер etcd выберет нового лидера и продолжит работу. Влияние будет минимальным, возможны лишь небольшие задержки в обработке запросов.
• Продолжительный сбой или потеря кворума: Если отказало слишком много нод etcd для формирования кворума (например, 2 из 3), кластер etcd становится неработоспособен (unavailable). Восстановление требует ручного вмешательства администратора кластера.

    *   Необходимо восстановить работоспособность самого кластера etcd, возможно, из последней **резервной копии (backup)**. Резервное копирование etcd — критически важная процедура для production-кластеров.
    *   После восстановления данных etcd нужно перезапустить контрольную плоскость Kubernetes (API Server, Controller Manager, Scheduler).
    *   **Важно:** Если после сбоя etcd в кластере продолжались какие-либо изменения (например, запускались контейнеры через docker напрямую), может возникнуть **расхождение состояния (split-brain)** между реально работающими подами и данными в восстановленном etcd. Это сложная ситуация, часто требующая ручной реконсиляции или принятия решения о принудительном пересоздании workload'ов.

Резюме и выводы для DevOps-инженера

1. Работающие поды "на земле" не остановятся — это обеспечивает устойчивость stateless-приложений.
2. Управление кластером полностью блокируется — невозможны деплой, масштабирование, обновление.
3. Кластер теряет способность к самовосстановлению — это главная угроза для долговременной отказоустойчивости.
4. Для минимизации рисков необходимо:

    *   Развертывать **кластер etcd из 3 или 5 нод** на отдельных, надежных серверах.
    *   **Регулярно создавать и тестировать резервные копии etcd** (например, с помощью `etcdctl snapshot save`).
    *   Настраивать **мониторинг** здоровья etcd (задержки, лидер, размер хранилища).
    *   Рассмотреть использование **управляемых Kubernetes-сервисов** (GKE, EKS, AKS), где контроль за etcd и его резервным копированием берет на себя провайдер.

Таким образом, сбой etcd не приводит к немедленной остановке приложений, но полностью обездвиживает систему оркестрации, превращая кластер из динамической, самоисцеляющейся системы в набор статических, неуправляемых серверов.