Розподілене сховище etcd виступає фактичним «мозком» будь-якого кластера Kubernetes, де будь-яка нестабільність може спровокувати лавиноподібний відказ усієї системи. Поки офіційні ініціативи CNCF щодо створення стандартизованих інструментів керування часто заплутуються в бюрократичних лабіринтах, спільнота продовжує розробляти прагматичні та гнучкі рішення. Перехід проєкту etcd-operator під егіду Cozystack став не простою зміною власника, а фундаментальним переосмисленням принципів роботи зі станом. Нова версія API v1alpha2 пропонує радикальний відхід від стандартних абстракцій Kubernetes на користь нативних механізмів самого etcd.
Еволюція інструментів автоматизації для etcd часто виглядає як протистояння між академічними концепціями та суворими реаліями експлуатації. Поки офіційні розробки буксують, оператор etcd трансформувався в інструмент, здатний ефективно працювати у високонавантажених продакшн-середовищах. Останнім значущим етапом став перехід проєкту в екосистему Cozystack та випуск API версії etcd-operator.cozystack.io/v1alpha2, яка повністю переписує логіку взаємодії з кластером.
Ключовою архітектурною зміною стала відмова від використання StatefulSet для управління вузлами. У традиційному підході Kubernetes намагається нав'язати власну логіку іменування та послідовності запуску подів, що часто конфліктує з внутрішніми механізмами консенсусу Raft, які використовує etcd. Тепер оператор взаємодіє з кластером безпосередньо через нативний Membership API, застосовуючи операції MemberAdd, MemberPromote та MemberRemove. Це забезпечує абсолютну передбачуваність складу кластера й усуває конфлікти, що виникають, коли Kubernetes намагається «виправити» стан вузлів на власний розсуд.
Логіка керування тепер розподілена між двома базовими ресурсами. Ресурс EtcdCluster виступає декларативним маніфестом, де описується цільовий стан: кількість реплік, версія рушія, параметри TLS та тонкі налаштування продуктивності. Водночас EtcdMember відповідає за життєвий цикл кожного конкретного вузла, керуючи відповідним подом і постійним сховищем (PVC).
Такий підхід гарантує незалежну синхронізацію кожного вузла. Процес зміни складу кластера став суворо регламентованим: нові учасники спочатку додаються в режимі навчання через MemberAdd і лише після підтвердження готовності отримують право голосу за допомогою MemberPromote. Видалення ж відбувається шляхом акуратного виведення вузла з кворуму, що гарантує цілісність даних та доступність сервісу. Більше того, при постановці кластера на паузу ідентифікатори вузлів зберігаються, що робить процес відновлення роботи прозорим і безпечним.
Порівняння нової версії з v1alpha1 свідчить про серйозну роботу над помилками в області типізації та валідації. Словник spec.options, що використовувався раніше, був занадто гнучким, що дозволяло передавати некоректні прапорці, здатні порушити логіку роботи оператора. У v1alpha2 цей механізм замінено суворо типізованим набором параметрів для керування квотами пам'яті (quota-backend-bytes), автоматичним стисненням даних та кількістю снапшотів.
Валідація маніфестів також пройшла через якісну трансформацію: громіздкі вебхуки були замінені на CEL-правила (Common Expression Language). Це дозволило перенести перевірку коректності безпосередньо на рівень API-сервера, позбавивши систему зайвих мережевих стрибків та потреби керувати сертифікатами для вебхуків. Додатково сервіс кластера було переведено в headless-режим, що є критично важливою умовою для забезпечення стабільності DNS-імен вузлів усередині мережі Kubernetes.
Для мінімізації ризиків під час оновлення було розроблено утиліту etcd-migrate. Вона реалізує стратегію in-place міграції, дозволяючи перевести живий кластер під керування нової версії API без переміщення даних або перезапуску подів. Інструмент фактично переписує власників об'єктів та анотації «на льоту», що робить перехід непомітним для клієнтів, які звертаються до кластера через DNS.
Окрім базового функціоналу, версія v1alpha2 запроваджує низку просунутих можливостей, що виходять за межі стандартних дорожніх карт. Серед них — підтримка масштабування в нуль зі збереженням ідентичності вузлів та можливість використання tmpfs для зберігання даних в оперативній пам'яті, що є критичним для надшвидких ефемерних середовищ.
Інтеграція з інфраструктурою Kubernetes стала глибшою: тепер оператор автоматично створює PodDisruptionBudget, орієнтуючись суворо на вузли, що мають право голосу, щоб уникнути втрати кворуму під час обслуговування нод. Реалізація сабресурсу /scale дозволяє використовувати стандартні команди kubectl scale та інтегруватися з VerticalPodAutoscaler. Завершує технологічний стек плагін kubectl-etcd, який переносить рутинні операції з обслуговування кластера безпосередньо в командний рядок адміністратора, перетворюючи складний процес керування розподіленим станом на серію простих і зрозумілих дій.
Цифрова незалежність з оновленням Immich 3.0
