Что такое etcd в Kubernetes?

Что такое etcd в Kubernetes?

Etcd — это распределённое, отказоустойчивое хранилище типа «ключ-значение», которое служит единственным источником правды (single source of truth) для всего кластера Kubernetes. В контексте Kubernetes, etcd функционирует как хранилище всех данных о состоянии кластера — его мозг и память, где записывается вся критически важная информация о конфигурации и текущем состоянии системы.

Основная роль и хранимые данные

Etcd сохраняет всю конфигурацию, состояние и метаданные кластера в структурированном виде. Ключевые типы данных включают:

• Конфигурация кластера: Глобальные настройки, информация о подключаемых модулях (аддонах), сетевые конфигурации (например, CIDR для подов и сервисов).
• Состояние рабочих нагрузок: Полная информация обо всех объектах API Kubernetes: Pod'ы, Deployments, Services, ConfigMaps, Secrets, Namespaces, их спецификации и текущий статус.
• Информация о нодах: Данные о каждом узле (Node) в кластере, их ёмкости, статусы готовности.
• Сетевые правила и эндпоинты: Информация о том, какие Pod'ы входят в состав Service (Endpoints и EndpointSlices).
• Роли и доступ (RBAC): Правила ролевого доступа, привязки ролей (RoleBindings, ClusterRoleBindings).
• Журналы лидеров и планировщика: Информация, необходимая компонентам управления (Control Plane) для согласованной работы.

Работает по модели консенсуса Raft, что гарантирует сильную согласованность (strong consistency) данных: чтение из любого узла etcd возвращает самые актуальные данные. Это фундаментально для Kubernetes, где расхождения в данных могли бы привести к катастрофическим последствиям, таким как создание дублирующих подов или потеря управляемости.

Архитектура взаимодействия в кластере

Etcd является сердцем Control Plane (Плоскости управления). Все ключевые компоненты взаимодействуют с ним:

// Упрощённая схема взаимодействия (логическая)
+----------------+       +----------------+       +----------------+
|   kube-apiserver  | <--> |      etcd       | <--> |   kube-scheduler  |
|   (единственный   |       |  (хранилище     |       |   (читает Pod'ы,   |
|   клиент etcd)    |       |   состояния)    |       |   пишет привязки) |
+----------------+       +----------------+       +----------------+
         ^                                                     ^
         |                                                     |
         v                                                     v
+----------------+                               +----------------+
|   kube-controller-manager  |                    |   kubelet (на нодах)  |
|   (читает/сравнивает       |                    |   (получает назначения |
|   состояние, пишет         |                    |   Pod'ов из API)      |
|   изменения)               |                    |                       |
+----------------+                               +----------------+

Важнейший нюанс: kube-apiserver является единственным компонентом Kubernetes, который напрямую взаимодействует с etcd на запись и чтение. Это архитектурное решение обеспечивает:

1. Единую точку аутентификации и авторизации.
2. Валидацию данных перед их сохранением.
3. Изоляцию логики — остальным компонентам (kube-scheduler, kube-controller-manager, kubelet) не нужно знать о деталях хранения, они общаются с кластером через API.

Ключевые особенности для DevOps-инженера

С точки зрения эксплуатации кластера, понимание etcd критически важно:

• Резервное копирование (Backup): Регулярный бэкап etcd — это обязательная процедура аварийного восстановления. Потеря данных etcd равносильна потере всего кластера. Бэкапы делаются с помощью утилиты etcdctl.

  # Пример команды создания снапшота бэкапа
  ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /var/lib/etcd-backup/snapshot.db
  

• Высокая доступность (HA): В продакшн-кластерах etcd всегда работает в виде кластера из нечётного числа узлов (3, 5, 7), распределённых по разным физическим машинам или зонам доступности. Это обеспечивает отказоустойчивость согласно алгоритму Raft (кластер из 3 узлов переживёт отказ одного).

• Безопасность: Доступ к etcd должен быть надёжно защищён, так как он содержит все Secrets кластера в незашифрованном виде (если не настроено внешнее шифрование). Соединение шифруется TLS, а аутентификация обычно строится на клиентских сертификатах.

• Производительность и мониторинг: Производительность всего кластера Kubernetes напрямую зависит от скорости отклика etcd. Необходимо мониторить ключевые метрики:

    *   **Задержка запросов на запись (write latency)**
    *   **Нагрузка на дисковую подсистему** (etcd очень чувствителен к задержкам ввода-вывода, рекомендуется использовать SSD).
    *   **Квота размера хранилища** (по умолчанию 2 ГБ, при достижении кластер переходит в режим только для чтения).

Проблемы и отказоустойчивость

• Потеря кворума: Если откажет более половины узлов etcd (например, 2 из 3), кластер теряет кворум и перестаёт принимать запросы на запись. K8s API становится недоступен для изменений, но существующие рабочие нагрузки продолжают работать.
• Восстановление: Восстановление из бэкапа — сложная процедура, требующая остановки etcd и аккуратного восстановления снапшота на всех узлах кластера etcd.

Итог: Etcd — это не просто база данных для Kubernetes, а его фундаментальный компонент целостности и согласованности. Для DevOps-инженера навыки обеспечения его отказоустойчивости, мониторинга, выполнения бэкапов и понимания принципов работы являются обязательными для поддержания стабильности и надёжности продакшн-кластера.