В нём хранится состояние кластера: поды, деплойменты, секреты, конфигурации, ноды, правила доступа и другие объекты.
По этим данным управляющий контур понимает, что сейчас есть в кластере и какое состояние нужно поддерживать.
➡️ Особенности
С etcd напрямую работает API-сервер Kubernetes.
Остальные компоненты получают данные уже через него.
Так Kubernetes централизованно проверяет запросы, права доступа и изменения в состоянии кластера.
Данные в etcd хранятся с версиями.
Когда объект меняется, Kubernetes видит это изменение и реагирует: создаёт под, обновляет конфигурацию, приводит сервис к нужному состоянию.
➡️ Как работает
Обычно etcd работает как кластер из нескольких узлов.
Один узел принимает изменения, остальные синхронизируют с ним данные.
Запись считается подтверждённой, когда её приняло большинство узлов.
Изменения в etcd фиксируются только после подтверждения большинством узлов. Поэтому в production чаще используют 3 или 5 узлов: так проще сохранить кворум при отказе и продолжить работу управляющего контура.
Потеря etcd без актуального бэкапа может привести к потере управляемого состояния Kubernetes-кластера.
Сами ноды при этом могут быть живы, но Kubernetes уже не сможет нормально управлять объектами, конфигурациями и доступами.
Поэтому снимок состояния etcd — обязательная часть эксплуатации.
➡️ Снять снимок можно командой:
etcdctl snapshot save /backup/etcd-$(date +%F).db
➡️ Проверить состояние узлов:
etcdctl endpoint status --cluster -w table
etcd хранит состояние Kubernetes-кластера. Поэтому бэкап должен быть не просто настроен, а проверен: снимок нужно уметь восстановить до того, как это потребуется в аварийной ситуации.
#заметкиИнженера