Повідомлення про випуск etcd v3.6.0
Зміст
- Вступ
- Безпека
- Можливості
- Продуктивність
- Зміни, що порушують сумісність
- Тестування
- Виправлення критичних помилок
- Проблема оновлення
- Платформи
- Залежності
- Спільнота
- Розширена підтримка v3.4
- Подальший розвиток
Вступ
Сьогодні ми повідомляємо про випуск 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.
Функціональні можливості (Feature Gates)
В etcd v3.6.0 ми впровадили функціональні можливості у стилі Kubernetes для керування новими функціями. Раніше ми позначали нестабільні функції через префікс --experimental у назвах прапорців. Префікс видалявся, коли функція ставала стабільною, що спричиняло зміну, яка порушує сумісність. Тепер функції починатимуться в Alpha, переходитимуть до Beta, потім до GA або застаріватимуть. Це забезпечує користувачам набагато зручніший процес оновлення та повернення до попередньої версії.
Див. документацію з функціональних можливостей для отримання додаткових деталей.
Перевірки livez/readyz
etcd тепер підтримує точки доступу /livez та /readyz, узгоджуючись із пробами Liveness та Readiness 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.
Зображення 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%.
Зображення 3: Порівняння пропускної здатності читання між etcd v3.5.20 та v3.6.0-rc.2 за високого співвідношення читання. Співвідношення читання/запису становить 8, тобто 8 читань на запис. Права смуга показує відсоткове покращення пропускної здатності читання v3.6.0-rc.2 порівняно з v3.5.20, що становить від 4.38% до 27.20%.
Зображення 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%.
Зображення 5: Порівняння пропускної здатності запису між etcd v3.5.20 та v3.6.0-rc.2 за високого співвідношення читання. Співвідношення читання/запису становить 8, тобто 8 читань на запис. Права смуга показує відсоткове покращення пропускної здатності запису v3.6.0-rc.2 порівняно з v3.5.20, що становить від 3.86% до 28.37%.
Зміни, що порушують сумісність
У цьому розділі висвітлено кілька помітних змін, що порушують сумісність. Для повного списку зверніться до Оновлення etcd з v3.5 до v3.6 та CHANGELOG-3.6.
Старі бінарні файли несумісні з новими версіями схеми
Старі бінарні файли etcd несумісні з новішими версіями схеми даних. Наприклад, etcd 3.5 не може запуститися з даними, створеними etcd 3.6, а etcd 3.4 не може запуститися з даними, створеними або 3.5, або 3.6.
Під час пониження версії etcd важливо дотримуватися задокументованої процедури пониження версії. Проста заміна бінарного файлу або образу призведе до проблеми несумісності.
Точки доступу Peer більше не обслуговують клієнтські запити
Клієнтські точки доступу (--advertise-client-urls) призначені лише для обслуговування клієнтських запитів, тоді як peer-точки доступу (--initial-advertise-peer-urls) призначені виключно для звʼязку між peer-вузлами. Однак через недогляд у реалізації peer-точки доступу також могли обробляти клієнтські запити в etcd 3.4 та 3.5. Така поведінка була оманливою та заохочувала неправильні шаблони використання. В etcd 3.6 цю оманливу поведінку було виправлено в PR/13565; peer-точки доступу більше не обслуговують клієнтські запити.
Чітка межа між etcdctl та etcdutl
І etcdctl, і etcdutl є інструментами командного рядка. etcdutl — це офлайн-утиліта, призначена для безпосередньої роботи з файлами даних etcd, тоді як etcdctl — це онлайн-інструмент, який взаємодіє з etcd через мережу. Раніше між ними існували деякі функції, що перетиналися, але ці перетини було видалено у 3.6.0.
Видалено
etcdctl defrag --data-dirКоманда
etcdctl defragпідтримує лише онлайн-дефрагментацію і більше не підтримує офлайн-дефрагментацію. Щоб виконати офлайн-дефрагментацію, використовуйте командуetcdutl defrag --data-dir.Видалено
etcdctl snapshot statusetcdctlбільше не підтримує отримання статусу знімка. Використовуйте командуetcdutl snapshot status.Видалено
etcdctl snapshot restoreetcdctlбільше не підтримує відновлення зі знімка. Використовуйте командуetcdutl snapshot restore.
Тестування
Ми впровадили тестування надійності, щоб перевірити правильність роботи, що завжди було нашим головним пріоритетом. Воно відтворює трафік різних типів та обсягів, що надходить до кластера etcd, одночасно вводить випадкову точку відмови, реєструє всі операції (включно із запитами та відповідями), а потім виконує остаточну перевірку лінеаризованості. Воно також перевіряє, чи не було порушено гарантій [Watch API][]. Тест надійності підвищує нашу впевненість у забезпеченні якості кожного випуску etcd. Варто зазначити, що він виявив кілька давніх помилок, які існували ще до випусків версії v3.4, завдяки чому v3.6.0 потенційно є найнадійнішим випуском в історії etcd.
Ми перенесли більшість тестів робочого процесу etcd до тестової інфраструктури Prow Kubernetes, щоб скористатися її перевагами, такими як зручні інфопанелі для перегляду результатів тестів та можливість учасників самостійно повторно запускати невдалі тести.
Виправлення критичних помилок
Коректність завжди була головним пріоритетом проєкту etcd. У процесі розробки 3.6.0 ми знайшли та виправили кілька помітних помилок, які могли призвести до неузгодженості даних у конкретних випадках. Ці виправлення були перенесені до попередніх випусків, але ми вважаємо, що вони заслуговують на особливу згадку тут.
Неузгодженість даних під час збою під навантаженням
Раніше, коли etcd застосовував дані, він спочатку оновлював consistent-index, а потім фіксував дані. Однак ці операції не були атомарними. Якщо 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 з версії 3.5 до 3.6, яка може призвести до збою процесу оновлення. Для ознайомлення з повним посібником з оновлення зверніться до Оновлення etcd з v3.5 до v3.6.
Про цю проблему було повідомлено в etcd v3.5.1 та вирішено у v3.5.20.
Головне: користувачі повинні спочатку оновитися до etcd v3.5.20 (або вищої patch-версії) перед оновленням до etcd v3.6.0; інакше оновлення може завершитися невдачею.
Для додаткового контексту та технічних деталей див. Оновлення з v3.5 до v3.6.
Платформи
Зберігаючи всі поточно підтримувані платформи, ми підвищили Linux/ARM64 до рівня підтримки Tier 1. Для детальнішої інформації зверніться до issues/15951. Для повного списку підтримуваних платформ див. Підтримувані платформи.
Залежності
Посібник з оновлення залежностей
Ми опублікували офіційний посібник про те, як оновлювати залежності для головної гілки та стабільних випусків 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.x | v1.3.x | N/A |
| 3.5.x | v1.3.x | N/A |
| 3.6.x | v1.4.x | v3.6.x |
grpc-gateway@v2
Ми оновили grpc-gateway з v1 до v2 у PR/16595 в etcd v3.6.0. Це значний крок до міграції на protobuf-go, другу основну версію реалізації Go API для protocol buffer.
grpc-gateway@v2 розроблено для роботи з protobuf-go. Однак etcd v3.6 все ще залежить від застарілого gogo/protobuf, який насправді є реалізацією protocol buffer 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 стає SIG Kubernetes
etcd офіційно стало Спеціальною групою за інтересами Kubernetes: SIG-etcd. Ця зміна підкреслює важливу роль etcd як основного сховища даних для Kubernetes і створює більш структуровану та прозору платформу для довгострокового управління та співпраці між проєктами. Новий статус SIG допоможе оптимізувати процес ухвалення рішень, узгодити плани розвитку з потребами Kubernetes та залучити ширше співтовариство до участі.
Нові учасники, підтримувачі та рецензенти
Ми спостерігаємо зростаючу залученість учасників, що призвело до додавання трьох нових підтримувачів:
Їхні постійні внески були ключовими у просуванні проєкту.
Ми також вітаємо двох нових рецензентів у проєкті:
Ми цінуємо їхню відданість якості коду та готовність взяти на себе ширші обовʼязки з рецензування в межах спільноти.
Нова команда випуску
Ми сформували нову команду випуску на чолі з ivanvc та jmhbnz, оптимізувавши процес випуску шляхом автоматизації багатьох раніше ручних кроків. Натхненні SIG Release Kubernetes, ми впровадили кілька найкращих практик, включно з чітко визначеними ролями команди випуску та впровадженням release shadows для підтримки обміну знаннями та сталості команди. Ці зміни зробили наші релізи більш злагодженими та надійними, що дозволяє нам підходити до кожного релізу з більшою впевненістю та послідовністю.
Представляємо робочу групу etcd Operator
З метою подальшого підвищення ефективності роботи etcd ми створили нову робочу групу: WG-etcd-operator. Ця робоча група має на меті забезпечити автоматичну та ефективну роботу кластерів etcd, що функціонують у середовищі Kubernetes із використанням etcd-operator.
Розширена підтримка v3.4
Згідно з нашою політикою підтримки спільноти, ми зазвичай підтримуємо лише дві останні мінорні версії, наразі v3.5 та v3.6. Однак ми подовжили підтримку v3.4 ще на один рік, щоб дати користувачам, які все ще на v3.4, більше часу для оновлення до v3.5 або v3.6. Як результат, підтримка v3.4 триватиме до 15 травня 2026 року.
Подальший розвиток
Старілий v2store було визнано застарілим, починаючи з etcd v3.4, а прапорець --enable-v2 було повністю видалено у v3.6. Це означає, що, починаючи з v3.6, більше немає способу ввімкнути або використовувати v2store. Однак etcd все ще виконує початкове завантаження внутрішньо із застарілих знімків v2. Щоб вирішити цю неузгодженість, ми плануємо змінити etcd так, щоб він виконував початкове завантаження з v3store та відтворював записи WAL на основі consistent-index. Робота відстежується в issues/12913.
Однією з найбільш стійких проблем залишається великий діапазон запитів від kube-apiserver, який може призводити до аварійного завершення процесів через їхню непередбачувану природу. Можливість range stream, спочатку окреслена в блозі випуску v3.5/планах на майбутнє, залишається ідеєю, яку варто переглянути для вирішення проблем великих діапазонних запитів.
Для детальнішої інформації та майбутніх планів зверніться до планів розвитку etcd.