15 мая 2025 года вышел минорный релиз etcd v3.6.0 — первый за четыре года после версии 3.5.0. Новый релиз принёс значимые изменения, например улучшения в безопасности и производительности, поддержку отката и переход на новый движок хранения данных v3store.

Основные нововведения

• Безопасность. Воркфлоу безопасности существенно усовершенствовали. Теперь исходный код сканируется с помощью govulncheck, а образы контейнеров — с помощью trivy. Эти механизмы были бэкпортированы в поддерживаемые стабильные версии.

• Миграция на v3store. Поддержка старого хранилища v2store прекращена — флаг для его включения удалён. v3store теперь единственный источник данных о составе кластера. Процесс полного удаления v2store ещё продолжается.

• Поддержка отката (downgrade). etcd v3.6.0 — первая версия с полной поддержкой отката. Работа над этим велась, начиная с версии 3.5, прогресс можно отследить в Issue #11716. Процесс отката теперь официально поддерживается и предусматривает миграцию схемы данных и постепенный rolling-откат. Подробности смотрите в руководстве по откату.

• Переключатели функциональности (feature gates). Введён механизм управления функциями, аналогичный тому, что используется в Kubernetes. Раньше нестабильные функции помечались префиксом --experimental в названиях флагов. После стабилизации префикс убирался, что вызывало несовместимость с предыдущими версиями. Теперь функции будут проходить стадии Alpha, Beta, а затем достигать статуса GA (общедоступного) или же могут быть помечены как устаревшие. Процесс обновления и отката станет гораздо более комфортным для пользователей. Подробности смотрите в разделе feature-gates.

• Новые проверки состояния /livez и /readyz. Аналогично Kubernetes появились эндпойнты для проверки живости и готовности сервиса, что улучшает мониторинг и управление. /livez показывает, работает ли etcd, а /readyz — готово ли оно выполнять задачи. Существующий эндпойнт /health по-прежнему работает. При этом /livez аналогична /health?serializable=true, а /readyz аналогична /health или /health?serializable=false.

• Новый протокол обнаружения v3discovery. Облегчает поиск компонентов кластера, заменяя устаревший протокол на базе clientv2. Публичный сервис discovery.etcd.io на базе v2discovery больше не поддерживается.

Производительность

• Память. Среднее потребление памяти снижено минимум на 50 %. Этого достигли за счёт уменьшения значения по умолчанию параметра --snapshot-count со 100 000 в версии 3.5 до 10 000 в версии 3.6, что сокращает объём сохраняемой истории, а также более частой компактизации истории Raft.

• Пропускная способность при чтении и записи. В среднем она выросла на 10 % по сравнению с версией 3.5 благодаря множеству мелких оптимизаций, включая улучшение обработки free page queries.

Исправления критических ошибок и обновления

• Несогласованность данных при сбое под нагрузкой. Ранее при применении данных etcd сначала обновляло consistent-index, а затем производило коммит данных. Но эти операции не были атомарными. Если etcd «падало» в промежутке между этими действиями, могла возникнуть несогласованность данных. Проблема появилась в v3.5.0 и исправлена в v3.5.3.

• Потеря данных несмотря на «успешную» запись. Когда клиент записывает данные и получает подтверждение об успешной записи, ожидается, что эти данные будут сохранены. Но в некоторых случаях данные пропадали, если etcd «падало» сразу после того, как клиенту отправлялся ответ «успех». Эта проблема затрагивала все предыдущие релизы. Ею занимались в v3.4.21 и v3.5.5 и окончательно решили в PR/14413.

• Несогласованность ревизий при сбое во время дефрагментации. Если etcd «падало» во время дефрагментации, то при перезапуске могли повторно примениться некоторые записи, которые уже были применены, что приводило к несогласованности ревизий. Проблему исправили в v3.5.6.

• Проблема при обновлении. Этот раздел описывает частую проблему, из-за которой процесс обновления etcd с версии 3.5 до 3.6 мог завершиться сбоем. Проблема появилась в etcd v3.5.1 и была исправлена в v3.5.20.

Внимание: сначала нужно обновиться до etcd v3.5.20 (или более новой патч-версии) и только затем до etcd v3.6.0. Иначе обновление может не пройти. Дополнительную информацию о предыстории и техническом контексте можно найти в upgrade_from_3.5_to_3.6_issue.

Обратная совместимость

• Старые версии etcd несовместимы с новыми схемами данных. Например, etcd 3.5 не запустится, если данные были созданы в etcd 3.6. Точно так же etcd 3.4 не сможет работать с данными от версий 3.5 или 3.6. Поэтому при откате необходимо использовать официальную процедуру. Просто заменить файл или образ не получится — это вызовет проблемы с совместимостью.

• Клиентские эндпойнты (--advertise-client-urls) предназначены для работы с клиентскими запросами. Пир-эндпойнты (--initial-advertise-peer-urls) используются только для связи между узлами кластера (peer communication). Однако в etcd 3.4 и 3.5 из-за ошибки реализации пир-эндпойнты по ошибке могли принимать и клиентские запросы. В etcd 3.6 это исправили.

etcd становится SIG Kubernetes

etcd официально получило статус Рабочей Группы Kubernetes (SIG-etcd). Этот шаг позволит ускорить принятие решений, лучше согласовывать планы развития с потребностями Kubernetes и привлечь больше участников из сообщества.