Средний

5 мин

1.1K

В рамках проекта etcd-operator сообщество развивает оператор для развёртывания и сопровождения кластеров etcd в Kubernetes. На днях он был передан проекту Cozystack (CNCF Sandbox). Перед этим команда опубликовала написанную с нуля реализацию оператора с новой версией API — etcd-operator.cozystack.io/v1alpha2. Эта версия пришла на смену etcd.aenix.io/v1alpha1. Вместо управления узлами через StatefulSet новый оператор напрямую задействует штатный Membership API etcd (операции MemberAdd, MemberPromote и MemberRemove), что позволяет ему полностью контролировать состав кластера. Автор новой реализации — Тимофей Ларкин, один из мейнтейнеров прежнего оператора (старый код остался в ветке v1alpha1). Проект написан на Go и распространяется под лицензией Apache 2.0.

Изначально etcd-operator начала разрабатывать команда Ænix, вокруг проекта быстро образовалась инициативная группа в русскоязычном сообществе Kubernetes. После завершения базовой реализации сообщество пыталось передать проекта в CNCF, но в итоге в проекте etcd пришли к выводу, что необходим официальный оператор, и сформировали собственную рабочую группу, которая предпочла писать оператор с нуля — так появился etcd-io/etcd-operator. По функциональности официальный оператор пока не достиг уровня нашего поректа, который уже успешно зарекомендовал себя в продакшене, в том числе в таких проектах, как Cozystack и Kamaji. Именно поэтому мы не примкнули к официальному оператору, а продолжили дотягивать сво проект (сравнение можно посмотреть в конце статьи).

Оператор управляет кластерами etcd при помощи двух ресурсов: EtcdCluster описывает желаемое состояние кластера (число реплик, версия etcd, параметры хранилища, TLS, аутентификация, настройки etcd), а EtcdMember создаётся самим оператором для каждого узла кластера и владеет его Pod и PVC. В отличие от типовых решений оператор не использует StatefulSet — Pod и PVC каждого узла обслуживаются независимо, а изменение состава кластера выполняется через Membership API etcd: новые узлы добавляются в режиме learner (MemberAdd) с последующим повышением до голосующего члена (MemberPromote), удаление выполняется с корректным выводом из кворума (MemberRemove), а приостановка кластера сохраняет идентичность узлов. Обоснование такой архитектуры приведено в файле concepts.md.

Основные возможности:

• развёртывание кластера и масштабирование в обе стороны по одному узлу за раз: добавление в режиме learner, корректное удаление с выводом из кворума;

• остановка кластера без потери данных (spec.replicas: 0) и возобновление работы с теми же идентификаторами кластера и узлов;

• хранение данных в PVC (по умолчанию) или в tmpfs — для данных, которые допустимо восстановить заново; узлы с хранилищем в памяти автоматически пересоздаются при потере Pod;

• раздельная настройка TLS для клиентских и межузловых соединений: можно подключить свои Secret или поручить оператору выпуск и автоматическое продление сертификатов через cert-manager;

• аутентификация с единственным пользователем root, учётные данные которого задаются через Secret;

• создание снапшотов в S3 или PVC через ресурс EtcdSnapshot и восстановление кластера из снапшота при первоначальном развёртывании;

• автоматически создаваемый PodDisruptionBudget, не позволяющий операциям drain нарушить кворум;

• валидация спецификаций средствами apiserver (CEL-выражения в CRD) без применения webhook и зависимости от cert-manager;

• подресурс /scale, благодаря которому работают kubectl scale и VerticalPodAutoscaler, порт метрик 2381, проброс affinity и topologySpreadConstraints;

• плагин kubectl-etcd для повседневных эксплуатационных задач (day-2 operations), выполняемых после развёртывания кластера.

По сравнению со старой реализацией etcd.aenix.io/v1alpha1 внесены следующие изменения:

• API-группа сменилась с etcd.aenix.io на etcd-operator.cozystack.io;

• вместо StatefulSet применяются отдельные ресурсы EtcdMember на каждый узел;

• произвольный словарь spec.options заменён типизированным набором параметров (quota-backend-bytes, режим и интервал автокомпактификации, snapshot-count) — свободная map позволяла передавать флаги, конфликтующие с логикой оператора;

• ресурс EtcdBackup переименован в EtcdSnapshot с сохранением семантики;

• валидация перенесена с webhook на CEL-правила в CRD;

• сервис кластера переведён в режим headless, что необходимо для стабильных DNS-имён узлов.

Миграция выполняется при помощи инструмента etcd-migrate: работающий кластер старого оператора адаптируется без перемещения данных, перезапуска Pod и потери кворума — изменяются только владельцы объектов, метки и аннотации, после чего управление переходит к новому оператору. Клиенты, которые обращаются к кластеру по DNS-имени, продолжают работать без изменений. Процедура описана в migration.md.

Реализация закрывает большинство пунктов плана развития официального etcd-оператора, развиваемого проектом etcd. Статус по пунктам этого плана:

1. Создание нового кластера etcd, например из 3 или 5 узлов, с указанной версией etcd — реализовано.

2. Определение состояния здоровья кластера — реализовано.

3. Включение TLS-шифрования соединений, включая продление сертификатов — реализовано.

4. Обновление в пределах патч-версий или на одну минорную версию — реализовано частично: значение spec.version применяется только к создаваемым узлам.

5. Масштабирование в обе стороны, например 1 -> 3 -> 5 узлов и обратно — реализовано.

6. Настройка параметров etcd (через флаги или переменные окружения) — реализовано, в виде типизированного закрытого набора параметров.

7. Восстановление одного отказавшего члена кластера (кворум сохранён) — реализовано частично: автоматическая замена членов с повреждённым PVC пока отсутствует.

8. Восстановление после отказа нескольких членов кластера (потеря кворума) — не реализовано, работа запланирована.

9. Создание резервной копии кластера по запросу — реализовано.

10. Периодическое резервное копирование кластера — сознательно вынесено за рамки оператора: периодические снапшоты предлагается запускать штатным CronJob.

Помимо этого плана, v1alpha2 предоставляет возможности, не упомянутые в плане развития официального оператора и продиктованные мультитенантным сценарием использования в Cozystack и Kamaji:

• остановка кластера до нуля реплик (пауза и возобновление) с сохранением идентичности кластера и узлов;

• хранилище в памяти (tmpfs) с автоматической заменой узлов силами оператора;

• валидация на стороне apiserver через CEL — без webhook и зависимости от сертификатов;

• автоматически создаваемый PodDisruptionBudget, охватывающий голосующие узлы;

• подресурс /scale с заполненным status.selector, благодаря чему напрямую работают kubectl scale и VerticalPodAutoscaler.targetRef;

• проброс параметров планирования (affinity, topologySpreadConstraints) и объединение additionalMetadata во всех создаваемых объектах;

• инструмент миграции с прежнего оператора без остановки кластера;

• плагин kubectl-etcd для эксплуатационных задач (day-2 operations).