etcd v3.6.0: Підвищена продуктивність та нові функції безпеки
Це оголошення спочатку з’явилося в блозі etcd.
Покращення безпеки та посилення захисту ланцюга постачання
У версії etcd v3.6.0 ми ще більше посилили нашу прихильність до безпеки, інтегрувавши govulncheck у процес зборки Go — проводячи статичний аналіз на основі бази даних вразливостей Go — та додавши сканування контейнерних образів за допомогою trivy для виявлення CVE у пакетах ОС та мовних середовищах. Обидва перевірки впроваджені в наші CI/CD робочі процеси та були перенесені на всі підтримувані стабільні гілки v3.x. Ми продовжуємо дотримуватись нашого Процесу випуску безпеки для оцінки та розкриття вразливостей. Як додатковий захід, бінарні артефакти тепер підписуються за допомогою GPG та публікуються разом з контрольними сумами для забезпечення цілісності на всіх етапах автоматизованих розгортань.
Нові функції та архітектурні досягнення
Міграція до v3store: єдина модель даних
З версії etcd v3.4 застаріла v2store була відхилена. У v3.6.0 прапорець --enable-v2 був повністю видалений. Тепер v3store є єдиним джерелом істини для членства кластеру та даних ключ-значення. v3store використовує транзакційні семантики bbolt v1.4, підтримує гарантії ACID та краще масштабується при високих навантаженнях. Якщо у ваших кластерах все ще є залишки даних v2, скористайтеся etcdutl check v2store (доступно з v3.5.18+) для перевірки, що залишилися лише записи про членство. Остаточне видалення внутрішнього v2snapshot bootstrap відслідковується у issues/12913.
Надійна підтримка зниження версії
etcd v3.6.0 став першим, який повністю реалізував безпечний шлях зниження версії з урахуванням схеми. Двохетапний процес — перевірка та активація — дозволяє вам повернутися з 3.6 до 3.5 (або раніше) без втрати даних. У фоновому режимі сервер etcd мігрує свою внутрішню схему protobuf для ключових ревізій та компакцій, а потім коректно відхиляє несумісні операції, якщо ви намагаєтеся змішати основні версії. Завжди робіть знімок перед продовженням і дотримуйтесь нашого посібника по зниженню версії 3.6, щоб уникнути неприємностей.
Кубернетес-стиль воріт для функцій
Ми впровадили трьохетапний життєвий цикл — Alpha, Beta, GA — для нових функцій, керованих воротами функцій, змодельованими за зразком Kubernetes. Цей підхід замінює старий префікс --experimental, усуває руйнівні зміни при переході прапорців у нові статуси та надає користувачам точний контроль над стабільністю та гарантіями підтримки в продуктивному середовищі. Деталі про доступні ворота та їхні стандартні стани можна знайти у ворота функцій.
Перевірки здоров’я: кінцеві точки /livez та /readyz
Щоб забезпечити плавну інтеграцію з перевірками життєздатності та готовності Kubernetes, etcd тепер надає /livez (екземпляр працює, цикл подій активний) та /readyz (raft застосував підтверджені записи, і сервер може обслуговувати лінійні читання). Ці кінцеві точки співіснують зі старою /health і дозволяють операторам відрізняти ситуації швидкого відмови (/livez) від недоступності сервісу (/readyz).
Протокол v3discovery
Новий протокол v3discovery, побудований на clientv3, замінює старий v2 discovery, транслюючи метадані пір через сервіс виявлення etcd з захистом TLS. Це спрощує процес початкового налаштування та забезпечує, щоб усі учасники дізнавалися про кінцеві точки один одного без змішування API з кількох основних версій.
Оптимізації продуктивності
Зменшення споживання пам’яті до 50%
Завдяки двом ключовим змінам — зниженню значення за замовчуванням --snapshot-count з 100,000 до 10,000 та застосуванню більш агресивної компакції журналу Raft (PR/18825) — ми скоротили середнє використання купи вдвічі. У кластерах з тривалою роботою, які обробляють мільйони операцій, це забезпечує більш стабільну продуктивність та зменшує паузи при зборі сміття.
Зростання пропускної здатності на 10%+
Детальний набір бенчмарків, що виконувався на EC2 інстансах c5.4xlarge з до 512 одночасними клієнтами, показав середнє поліпшення пропускної здатності читання та запису на 10–25%. Оптимізації включають спрощені запити на вільні сторінки в bbolt (PR/419), зменшення конкуренції за блокування в процесі читання та оновлення телеметрії, які потребують менших витрат на серіалізацію.
Значні зміни та примітки щодо оновлення
Несумісність схеми даних: Старі бінарні файли не можуть відкривати нові каталоги даних. Завжди дотримуйтесь задокументованих процедур оновлення та зниження версії.
Кінцеві точки пір та клієнтів: URL-адреси пір (налаштовані через
--initial-advertise-peer-urls) більше не обслуговують клієнтський трафік.Розмежування інструментів CLI:
etcdctlтепер підтримує лише онлайн-операції; офлайн-знімки та дефрагментація перенесені доetcdutl.
Критичні виправлення помилок
Консистентність при аварійному завершенні під навантаженням: Виправлено вікно, коли аварійне завершення між оновленням консистентного індексу та комітом могло призвести до втрати записів (PR 13854).
Стійкість у кластерах з одною нодою: Забезпечено порядок fsync, щоб клієнти могли довіряти успішній відповіді на запис (PR 14413).
Стабільність дефрагментації: Усунено повторне застосування записів після аварії під час дефрагментації (PR 14730).
Розширена підтримка платформ
Linux/ARM64 отримує підтримку першого рівня з офіційними бінарними файлами та покриттям CI. etcd v3.6.0 продовжує підтримувати x86_64 Linux, macOS, FreeBSD, Windows та s390x. Докладну інформацію можна знайти у підтримуваних платформах.
Спільнота, управління та SIG-etcd
etcd офіційно приєднався до Спеціальних Інтересів Kubernetes як SIG-etcd, зміцнюючи співпрацю між проектами, узгоджуючи дорожні карти та впроваджуючи найкращі практики SIG Release. Ми раді вітати трьох нових утримувачів та двох нових рецензентів, а також створили команду випуску за зразком ролей SIG Release. Нова Робоча група etcd-operator зосередиться на автоматизованому управлінні життєвим циклом кластерів у Kubernetes.
Додаткова секція: Методологія бенчмаркінгу
Наші бенчмарки використовували набір тестів etcd з навантаженнями на запис та читання. Тести проводилися на інстансах AWS c5.4xlarge (16 vCPU, 32 GiB RAM) з обсягами EBS на базі NVMe SSD. Ми налаштували тайм-аути виборів Raft на 500 мс та виміряли затримки p99 під 95-м перцентилем за 10-хвилинними запусками. Треті сторони, які проводили аудит у CNCF, підтвердили тестову систему для забезпечення відтворюваності.
Додаткова секція: Глибокий аналіз механізму зберігання
bbolt v1.4 вводить оптимізації рекламації простору та зменшує накладні витрати на розподіл сторінок. Ми експериментували з LMDB та BadgerDB, але виявили, що B+-дерево bbolt з додаванням лише та пам’яттю, що відображається, забезпечує найкращий компроміс між читанням та записом для типових навантажень у стилі Kubernetes. У майбутньому планується інтеграція шару LSM-дерева для зменшення підсилення запису в сценаріях з дуже високою швидкістю запису.
Додаткова секція: Найкращі практики експлуатації
Для продуктивних кластерів ми рекомендуємо:
- Використовувати перевірки життєздатності (
/livez) та готовності (/readyz) у розгортаннях Kubernetes. - Розміщувати etcd на виділених нодах з низьким мережевим джиттером — бажано 10 GbE або краще — та ізолювати зберігання на NVMe SSD.
- Автоматизувати резервне копіювання через
etcdutl snapshot saveкожні 5–15 хвилин, у поєднанні з резервним сховищем поза кластером (наприклад, S3). - Моніторити метрики (зміни лідера, тривалість пропозицій raft, затримки читання/запису в БД) через панелі Prometheus та Grafana.
Погляд у майбутнє
Ми завершуємо старий шлях завантаження v2 та досліджуємо стрімінгові запити діапазону для кращої підтримки великих API Kubernetes. Дивіться нашу дорожню карту для майбутньої роботи над шифруванням даних на диску, крос-кластерною реплікацією та покращеною багатокористувацькою ізоляцією.
Щире спасибі понад 200 учасникам, які зробили можливим вихід etcd v3.6.0!
Джерело: Блог Kubernetes