etcd-operator присоединяется к Cozystack с новым API версии v1alpha2

Сообщество написало рабочий инструмент, а в CNCF решили сделать «свой, официальный». В итоге забуксовали. А тем временем хитрый оператор etcd продолжает обрастать фичами и успешно крутиться в продакшене.

Проект etcd-operator, разрабатывающий инструмент для развертывания и обслуживания кластеров etcd в Kubernetes, стал частью экосистемы Cozystack. Вместе с передачей прав авторы представили полностью переписанную реализацию под новым API: etcd-operator.cozystack.io/v1alpha2. Она пришла на смену предыдущей версии etcd.aenix.io/v1alpha1.

Главное архитектурное новшество — отказ от управления узлами через StatefulSet. Теперь оператор работает с кластером напрямую через нативный Membership API самого etcd, используя операции MemberAdd, MemberPromote и MemberRemove. Это дает полный и предсказуемый контроль над составом кластера. Код с нуля написал Тимофей Ларкин, один из мейнтейнеров оригинальной версии (ее исходники сохранены в ветке v1alpha1). Проект написан на Go и доступен под лицензией Apache 2.0.

Как работает новая архитектура управление кластерами. Она строится вокруг двух ресурсов.

1. EtcdCluster описывает желаемое состояние: количество реплик, версию etcd, параметры хранилища, TLS, аутентификацию и тюнинг.

2. EtcdMember создается оператором индивидуально для каждого узла и управляет его Pod’ом и PVC.

Здесь нет привычного StatefulSet — каждый узел синхронизируется (reconcile) независимо. Изменения состава проходят строго через API: новые участники добавляются в режиме обучения (MemberAdd) и только потом получают право голоса (MemberPromote). Удаление происходит через аккуратный вывод из кворума (MemberRemove). Если кластер ставится на паузу, идентификаторы узлов не теряются. Подробное обоснование такой архитектуры можно найти в файле concepts.md репозитория.

Хотите выиграть призы и бонусы на аренду серверов?

Приглашаем решить ИТ-кроссворд! Более 100 вопросов на разные темы из мира ИИ и машинного обучения — ежедневно с 6 по 9 июля. 

Зарегистрироваться →

Что изменилось по сравнению с v1alpha1

• API-группа переехала с etcd.aenix.io на etcd-operator.cozystack.io.

• На смену монолитному StatefulSet пришли независимые ресурсы EtcdMember.

• Опасный свободный словарь spec.options заменен на строго типизированный набор параметров (quota-backend-bytes, настройки auto-compaction, snapshot-count). Раньше неверные флаги могли сломать логику оператора.

• Ресурс EtcdBackup переименован в EtcdSnapshot при сохранении логики работы.

• Валидация манифестов перенесена из вебхука в CEL-правила.

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

Для бесшовного перехода написана утилита etcd-migrate. Она проводит in-place миграцию: подхватывает живой кластер старого оператора без перемещения данных, перезапуска подов или потери кворума. Инструмент просто меняет владельцев объектов, лейблы и аннотации, после чего управление переходит к v1alpha2. Клиенты, обращающиеся к кластеру по DNS, даже не замечают подмены (подробнее процесс описан в migration.md).

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

• Масштабирование в ноль (пауза/возобновление) с сохранением идентичности.

• Хранение данных в памяти (tmpfs) с автоматической заменой узлов силами самого оператора.

• CEL-валидация на стороне apiserver без лишних компонентов (ни вебхуков, ни сертификатов).

• Автоматический PodDisruptionBudget, нацеленный строго на голосующие узлы.

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

• Сквозной проброс правил планировщика (affinity, topologySpreadConstraints) и слияние additionalMetadata для всех дочерних объектов.

• Инструмент для безопасной in-place миграции.

• Плагин kubectl-etcd для повседневного обслуживания.

Подробности — на странице CNCF.

Напишите, что думаете, в комментариях. Например, что принесет отказ от StatefulSet? Управление через Membership API не идет вразрез с классическими туториалами Kubernetes?