Оголошення про випуск etcd v3.6.0

Автор Benjamin Wang (VMware by Broadcom) |

Це оголошення спочатку було опубліковане в блозі etcd.

Сьогодні ми випускаємо etcd v3.6.0, перший мінорний реліз з моменту випуску etcd v3.5.0 15 червня 2021 року. Цей реліз вводить кілька нових функцій, робить значний прогрес у тривалих зусиллях, таких як підтримка зниження версії та міграція на v3store, і вирішує численні критичні та основні проблеми. Він також включає великі оптимізації в використанні памʼяті, покращуючи ефективність і продуктивність.

На додачу до функцій v3.6.0, etcd приєднався до Kubernetes як SIG (sig-etcd), що дозволяє нам покращити стійкість проєкту. Ми впровадили систематичне тестування на надійність, щоб забезпечити правильність і надійність. За допомоги робочої групи etcd-operator ми плануємо також покращити зручність використання.

Далі наведені найзначніші зміни в etcd v3.6.0, а також обговорення планів майбутнього розвитку. Для детального списку змін, будь ласка, зверніться до CHANGELOG-3.6.

Щира подяка всім учасникам, які зробили цей реліз можливим!

Безпека

etcd ставиться до безпеки серйозно. Щоб підвищити безпеку програмного забезпечення в v3.6.0, ми покращили наші перевірки робочого процесу, інтегрувавши govulncheck для сканування вихідного коду та trivy для сканування контейнерних образів. Ці покращення також були перенесені на підтримувані стабільні релізи.

etcd продовжує дотримуватися процесу безпеки випуску для забезпечення належного управління та вирішення вразливостей.

Функції

Міграція на v3store

v2store був визнаний застарілим з моменту випуску etcd v3.4, але його все ще можна було активувати за допомогою --enable-v2. Він залишався джерелом істини для даних про членство. У etcd v3.6.0 v2store більше не може бути активований, оскільки прапорець --enable-v2 був видалений, а v3store став єдиним джерелом істини для даних про членство.

Хоча v2store все ще існує в v3.6.0, etcd не зможе запуститися, якщо він міститиме будь-які дані, крім інформації про членство. Щоб допомогти з міграцією, etcd v3.5.18+ надає команду etcdutl check v2store, яка перевіряє, чи містить v2store лише дані про членство (див. PR 19113).

У порівнянні з v2store, v3store пропонує кращу продуктивність і транзакційну підтримку. Він також є системою зберігання, що перебуває в стані активної підтримки, що просувається вперед.

Видалення v2store все ще триває і відстежується в issues/12913.

Зниження версії

etcd v3.6.0 — це перша версія, яка повністю підтримує зниження версії. Зусилля для цього завдання зниження версії охоплюють обидві версії 3.5 і 3.6, а вся повʼязана робота відстежується в issues/11716.

На високому рівні процес охоплює міграцію схеми даних до цільової версії (наприклад, v3.5), а потім — поетапне зниження версії.

Переконайтеся, що кластер справний, і зробіть резервну копію знімка. Переконайтеся, що пониження до нижчого рівня є дійсним:

$ etcdctl downgrade validate 3.5
Downgrade validate success, cluster version 3.6

Якщо пониження є валідним, увімкніть режим пониження:

$ etcdctl downgrade enable 3.5
Downgrade enable success, cluster version 3.6

etcd перенесе схему даних у фоновому режимі. Після завершення перейдіть до поетапного оновлення.

За деталями звертайтесь до керівництва Downgrade-3.6.

Функціональні можливості

У etcd v3.6.0 ми впровадили функціональні можливості в стилі Kubernetes для управління новими функціями. Раніше ми вказували на нестабільні функції через префікс --experimental у назвах прапорців функцій. Префікс видалявся після стабілізації функції, що призводило до зламу. Тепер функції починаються з Alpha, переходять в Beta, потім GA або застарівають. Це забезпечує набагато плавніший процес оновлення та зниження версії для користувачів.

Дивіться feature-gates для деталей.

Перевірки livez / readyz

etcd тепер підтримує точки доступу /livez і /readyz, що відповідає перевіркам життєздатності та готовності в Kubernetes. /livez вказує, чи є екземпляр etcd життєздатним, тоді як /readyz вказує, коли він готовий обслуговувати запити. Ця функція також була перенесена на release-3.5 (починаючи з v3.5.11) і release-3.4 (починаючи з v3.4.29). Дивіться livez/readyz для деталей.

Наявна точка доступу /health залишається функціональною. /livez подібна до /health?serializable=true, тоді як /readyz подібна до /health або /health?serializable=false. Очевидно, що точки доступу /livez і /readyz надають чіткішу семантику і легші для розуміння.

v3discovery

В etcd v3.6.0 був представлений новий протокол виявлення v3discovery, заснований на clientv3. Він полегшує виявлення всіх членів кластера під час фази початкового завантаження.

Попередній протокол v2discovery, заснований на clientv2, був визнаний застарілим. Крім того, публічна служба виявлення за адресою https://discovery.etcd.io/, яка покладалася на v2discovery, більше не підтримується.

Продуктивність

Памʼять

У цьому випуску ми зменшили середнє споживання памʼяті щонайменше на 50% (див. Зображення 1). Це покращення в основному зумовлено двома змінами:

  • Стандартне значення для --snapshot-count було зменшено з 100 000 у v3.5 до 10 000 у v3.6. В результаті etcd v3.6 тепер зберігає лише 10% історичних записів у порівнянні з v3.5.
  • Історія Raft стискається частіше, про що йдеться в PR/18825.
Схема використання пам'яті

Зображення 1: Порівняння використання памʼяті між etcd v3.5.20 і v3.6.0-rc.2 за різними співвідношеннями читання/запису. Кожен графік показує використання памʼяті з часом з певним співвідношенням читання/запису. Червона лінія представляє etcd v3.5.20, тоді як бірюзова лінія представляє v3.6.0-rc.2. У всіх протестованих співвідношеннях v3.6.0-rc.2 демонструє нижче і більш стабільне використання памʼяті.

Пропускна здатність

У порівнянні з v3.5, etcd v3.6 забезпечує середнє поліпшення продуктивності приблизно на 10% як у читанні, так і в запису (див. Зображення 2, 3, 4 і 5). Це поліпшення не повʼязане з жодною окремою великою зміною, а є кумулятивним ефектом кількох незначних вдосконалень. Одним з таких прикладів є оптимізація запитів до вільних сторінок, введена в PR/419.

Продуктивність транзакцій читання etcd з високим коефіцієнтом запису

Зображення 2: Порівняння пропускної здатності читання між etcd v3.5.20 і v3.6.0-rc.2 за високого коефіцієнта запису. Коефіцієнт читання/запису становить 0.0078, що означає 1 читання на 128 записів. Права смуга показує відсоткове поліпшення пропускної здатності читання v3.6.0-rc.2 в порівнянні з v3.5.20, яке коливається від 3.21% до 25.59%.

Продуктивність транзакцій etcd читання з високим коефіцієнтом читання

Зображення 3: Порівняння пропускної здатності читання між etcd v3.5.20 і v3.6.0-rc.2 за високого коефіцієнта читання. Коефіцієнт читання/запису становить 8, що означає 8 читань на 1 запис. Права смуга показує відсоткове поліпшення пропускної здатності читання v3.6.0-rc.2 в порівнянні з v3.5.20, яке коливається від 4.38% до 27.20%.

Продуктивність транзакцій запису etcd з високим коефіцієнтом запису

Зображення 4: Порівняння пропускної здатності запису між etcd v3.5.20 і v3.6.0-rc.2 за високого коефіцієнта запису. Коефіцієнт читання/запису становить 0.0078, що означає 1 читання на 128 записів. Права смуга показує відсоткове поліпшення пропускної здатності запису v3.6.0-rc.2 в порівнянні з v3.5.20, яке коливається від 2.95% до 24.24%.

Продуктивність транзакцій запису etcd з високим коефіцієнтом читання

Зображення 5: Порівняння пропускної здатності запису між etcd v3.5.20 і v3.6.0-rc.2 за високого коефіцієнта читання. Коефіцієнт читання/запису становить 8, що означає 8 читань на 1 запис. Права смуга показує відсоткове поліпшення пропускної здатності запису v3.6.0-rc.2 в порівнянні з v3.5.20, яке коливається від 3.86% до 28.37%.

Кардинальні зміни

У цьому розділі висвітлено кілька важливих змін. Повний список можна знайти у Оновлення з v3.5 до v3.6 та CHANGELOG-3.6.

Старі бінарні файли несумісні з новими версіями схем

Старі бінарні файли etcd несумісні з новими версіями схем даних. Наприклад, etcd 3.5 не може бути запущений з даними, створеними etcd 3.6, а etcd 3.4 не може бути запущений з даними, створеними як 3.5, так і 3.6.

При пониженні версії etcd важливо дотримуватися задокументованої процедури пониження. Просте заміщення бінарного файлу або образу призведе до проблеми несумісності.

Точки доступу учасників більше не обслуговують запити клієнтів

Точки доступу клієнтів (--advertise-client-urls) призначені лише для обслуговування запитів клієнтів, тоді як точки доступу учасників (--initial-advertise-peer-urls) призначені виключно для звʼязку між учасниками. Однак через недогляд у реалізації точки доступу учасників також могли обробляти запити клієнтів в etcd 3.4 і 3.5. Ця поведінка була оманливою і сприяла неправильним шаблонам використання. У etcd 3.6 ця оманлива поведінка була виправлена за допомогою PR/13565; точки доступу учасників більше не обслуговують запити клієнтів.

Чітка межа між etcdctl і etcdutl

Обидва etcdctl і etcdutl є інструментами командного рядка. etcdutl є офлайн-утилітою, призначеною для роботи безпосередньо з файлами даних etcd, тоді як etcdctl є онлайн-інструментом, який взаємодіє з etcd через мережу. Раніше між ними існували деякі перекриття функціональності, але ці перекриття були усунені в 3.6.0.

  • Вилучено etcdctl defrag --data-dir.

    Команда etcdctl defrag підтримує лише онлайн-дефрагментацію і більше не підтримує офлайн-дефрагментацію. Щоб виконати офлайн-дефрагментацію, використовуйте команду etcdutl defrag --data-dir.

  • Вилучено etcdctl snapshot status

    etcdctl більше не підтримує отримання статусу знімка. Використовуйте команду etcdutl snapshot status замість цього.

  • Вилучено etcdctl snapshot restore

    etcdctl більше не підтримує відновлення з знімка. Використовуйте команду etcdutl snapshot restore замість цього.

Виправлення критичних помилок

Коректність завжди була основним пріоритетом для проєкту etcd. У процесі розробки 3.6.0 ми знайшли та виправили кілька помітних помилок, які могли призвести до неузгодженості даних у певних випадках. Ці виправлення були перенесені до попередніх версій, але ми вважаємо, що вони заслуговують на окрему згадку тут.

  • Неузгодженість даних при аварійному завершенні під навантаженням

    Раніше, коли etcd використовував дані, він спочатку оновлював індекс узгодженості, а потім фіксував дані. Однак ці операції не були атомарними. Якщо etcd зазнавав аварії між цими операціями, це могло призвести до неузгодженості даних (див. issue/13766). Цю проблему було введено в v3.5.0 і виправлено в v3.5.3 за допомогою PR/13854.

  • Порушення гарантії довговічності API в кластері, що складається з одного вузла

    Коли клієнт записує дані та отримує успішну відповідь, очікується, що дані будуть збережені. Однак дані можуть бути втрачені, якщо etcd зазнає аварії одразу після надсилання успішної відповіді клієнту. Це була стара проблема (див. issue/14370) яка впливала на всі попередні випуски. Вона була вирішена в v3.4.21 і v3.5.5 за допомогою PR/14400, і виправлена на стороні raft в основній гілці (тепер release-3.6) з PR/14413.

  • Неузгодженість ревізій при аварійному завершенні під час дефрагментації

    Якщо etcd зазнавав аварії під час операції дефрагментації, після перезапуску він міг повторно застосувати деякі записи, які вже були застосовані, що призводило до проблеми з неузгодженістю ревізій (див. обговорення в PR/14685). Ця проблема зʼявилась в v3.5.0 і її було виправлено в v3.5.6 за допомогою PR/14730.

Проблема з оновленням

Цей розділ висвітлює загальну проблему issues/19557 в оновленні etcd з v3.5 до v3.6, яка може призвести до збою процесу оновлення. Для отримання докладних інструкцій з оновлення зверніться до Оновлення etcd з v3.5 до v3.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, одночасно впроваджуючи випадкову точку відмови, записує всі операції (включаючи запити та відповіді) і, нарешті, виконує перевірку лінійної узгодженості. Він також перевіряє, що гарантії Watch APIs не були порушені. Тест на стійкість підвищує нашу впевненість у забезпеченні якості кожного випуску etcd.

Ми мігрували більшість тестів робочого процесу etcd до інфраструктури тестування Prow Kubernetes, щоб використати її переваги, такі як зручні інформаційні панелі для перегляду результатів тестування та можливість для учасників повторно запускати невдалі тести самостійно.

Платформи

Зберігаючи всі наявні підтримувані платформи, ми підвищили Linux/ARM64 до рівня підтримки Tier 1. Для отримання додаткової інформації зверніться до issues/15951. Для отримання повного списку підтримуваних платформ, див. supported-platform.

Залежності

Посібник з оновлення залежностей

Ми опублікували офіційний посібник з оновлення залежностей для основної гілки та стабільних випусків etcd. У ньому також описано, як оновити версію для Go. Для отримання більш детальної інформації, будь ласка, зверніться до dependency_management. Тепер, коли цей посібник доступний, будь-хто з учасників може допомогти з оновленням залежностей.

Оновлення основних залежностей

bbolt та raft є двома основними залежностями etcd.

Обидва etcd v3.4 і v3.5 залежать від bbolt v1.3, тоді як etcd v3.6 залежить від bbolt v1.4.

Для гілок release-3.4 і release-3.5 raft включено безпосередньо в репозиторій etcd, тому etcd v3.4 і v3.5 не залежать від зовнішнього модуля raft. Починаючи з etcd v3.6, raft було переміщено до окремого репозиторію (raft), а перший самостійний реліз raft — це v3.6.0. Як наслідок, etcd v3.6.0 залежить від raft v3.6.0.

Будь ласка, дивіться таблицю нижче:

версії etcdверсії bboltверсії raft
3.4.xv1.3.xN/A
3.5.xv1.3.xN/A
3.6.xv1.4.xv3.6.x

grpc-gateway@v2

Ми оновили grpc-gateway з v1 до v2 через PR/16595 в etcd v3.6.0. Це є важливим кроком до міграції на protobuf-go, другу основну версію реалізації API протоколу буферизації Go.

grpc-gateway@v2 призначений для роботи з protobuf-go. Однак etcd v3.6 все ще залежить від застарілого gogo/protobuf, який насправді є реалізацією протоколу буферизації v1. Щоб вирішити цю несумісність, ми застосували патч до згенерованих *.pb.gw.go файлів, щоб перетворити повідомлення v1 на повідомлення v2.

grpc-ecosystem/go-grpc-middleware/providers/prometheus

Ми перейшли з застарілого (і архівованого) grpc-ecosystem/go-grpc-prometheus на grpc-ecosystem/go-grpc-middleware/providers/prometheus у PR/19195. Ця зміна забезпечує подальшу підтримку та доступ до останніх функцій і вдосконалень в інтеграції gRPC Prometheus.

Спільнота

В спільноті etcd відбуваються захопливі події, які відображають нашу постійну прихильність до зміцнення співпраці, покращення підтримки та еволюції управління проєктом.

etcd стає Kubernetes SIG

etcd офіційно став Kubernetes Special Interest Group: SIG-etcd. Ця зміна відображає критичну роль etcd як основного сховища даних для Kubernetes і встановлює більш структуровану та прозору основу для довгострокового управління та співпраці між проєктами. Нова SIG допоможе спростити процес прийняття рішень, узгодити плани з потребами Kubernetes, і залучити більше учасників.

Нові учасники, підтримувачі та рецензенти

Ми спостерігали активність, що постійно зростає, з боку учасників, що призвело до додавання трьох нових підтримувачів до команди etcd:

Їхні подальші внески були вирішальними для просування проєкту вперед.

Ми також вітаємо двох нових рецензентів у проєкті:

Ми цінуємо їхню відданість якості коду та готовність взяти на себе ширші обовʼязки з рецензування в межах спільноти.

Нова команда випуску

Ми сформували нову команду випуску, очолювану ivanvc та jmhbnz, спростивши процес випуску шляхом автоматизації багатьох раніше ручних етапів. Надихнувшись Kubernetes SIG Release, ми прийняли кілька найкращих практик, включаючи чітко визначені ролі команди випуску та впровадження "тіней випуску" для підтримки обміну знаннями та стійкості команди. Ці зміни зробили наші випуски більш плавними та надійними, дозволяючи нам підходити до кожного випуску з більшою впевненістю та послідовністю.

Представляємо etcd Operator Working Group

Щоб ще більше покращити операційну досконалість etcd, ми сформували нову робочу групу: WG-etcd-operator. Робоча група присвячена питанням забезпечення автоматичної та ефективної роботи кластерів etcd, які працюють у середовищі Kubernetes за допомогою etcd-оператора.

Майбутній розвиток

v2store був визнаний застарілим з моменту виходу etcd v3.4, а прапорець --enable-v2 був повністю видалений у v3.6. Це означає, що починаючи з v3.6, більше немає способу увімкнути або використовувати v2store. Однак etcd все ще ініціалізується з внутрішніх спадкових знімків v2. Щоб вирішити цю несумісність, ми плануємо змінити etcd на bootstrap з v3store і відтворити записи WAL на основі consistent-index. Ця робота відстежується в issues/12913.

Однією з найпостійніших проблем залишаються великі запити діапазону з kube-apiserver, які можуть призвести до аварійних зупинок процесів через їх непередбачувану природу. Функція потокового діапазону, спочатку описана в v3.5 release blog/Future roadmaps, залишається ідеєю, яку варто переглянути, щоб розвʼязати проблеми з великими запитами діапазону.

Для отримання додаткової інформації та майбутніх планів, будь ласка, зверніться до планів розвитку etcd.