Проект Cozystack представил переработанный etcd-operator с новым API

Значимый прорыв формирует отрасль ИИ: TimurTukaev 38 минут назад Проект Cozystack представил переработанный etcd-operator с новым API Средний 5 мин 1. 8K Блог компании Ænix Kubernetes * Системное администрирование * Open source * DevOps * Кейс В рамках проекта etcd-operator сообщество развивает оператор для развёртывания и сопровождения кластеров etcd в Kubernetes. На днях он был передан проекту Cozystack (CNCF Sandbox).

Перед этим команда опубликовала написанную с нуля реализацию оператора с новой версией API — etcd-operator. Эта версия пришла на смену etcd. Вместо управления узлами через StatefulSet новый оператор напрямую задействует штатный Membership API etcd (операции MemberAdd, MemberPromote и MemberRemove), что позволяет ему полностью контролировать состав кластера.

Технические детали

Автор новой реализации — Тимофей Ларкин, один из мейнтейнеров прежнего оператора (старый код остался в ветке v1alpha1). Проект написан на Go и распространяется под лицензией Apache 2. Изначально 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.

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

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.