Посібник з експлуатації on etcd

Параметри конфігурації

Mon, 01 Jan 0001 00:00:00 +0000

Ви можете налаштувати etcd за допомогою наступного:

Прапорці командного рядка
Змінні середовища: кожен прапорець має відповідну змінну середовища, яка має таку ж назву, але з префіксом ETCD_ і у форматі snake case. Наприклад, --some-flag буде ETCD_SOME_FLAG.
Файл конфігурації

Увага: Якщо ви змішуєте параметри конфігурації, то застосовуються наступні правила.

Прапорці командного рядка мають пріоритет над змінними середовища.
Якщо ви надаєте файл конфігурації, всі прапорці командного рядка та змінні середовища ігноруються.

Прапорці командного рядка

Прапорці представлені нижче у форматі --flag-name DEFAULT_VALUE.

Модель транспортної безпеки

Mon, 01 Jan 0001 00:00:00 +0000

etcd підтримує автоматичний TLS, а також автентифікацію через клієнтські сертифікати як для клієнтів до сервера, так і для звʼязку між вузлами (сервер до сервера / кластер). Зверніть увагу, що etcd стандартно не вмикає автентифікацію на основі RBAC або функцію автентифікації на транспортному рівні, щоб зменшити труднощі для користувачів, які починають працювати з базою даних. Крім того, зміна цього стандартного параметра буде порушенням для проєкту, який був заснований у 2013 році. Кластер etcd, який не вмикає функції безпеки, може експонувати свої дані будь-яким клієнтам.

Посібник з кластеризації

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Запуск кластера etcd статично вимагає, щоб кожен учасник знав іншого в кластері. У ряді випадків IP-адреси учасників кластера можуть бути невідомі заздалегідь. У таких випадках кластер etcd можна запустити за допомогою служби виявлення.

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

Цей посібник охоплює наступні механізми запуску кластера etcd:

Запуск кластерів etcd у контейнерах

Mon, 01 Jan 0001 00:00:00 +0000

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

Docker

Щоб відкрити API etcd для клієнтів за межами хосту Docker, використовуйте IP-адресу хосту контейнера. Будь ласка, дивіться docker inspect для отримання додаткової інформації про те, як отримати IP-адресу. Альтернативно, вкажіть прапорець --net=host для команди docker run, щоб пропустити розміщення контейнера всередині окремого мережевого стека.

Запуск одного вузла etcd

Використовуйте IP-адресу хосту при налаштуванні etcd:

Запуск кластерів etcd як Kubernetes StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

Нижче показано, як виконати статичний процес завантаження як Kubernetes StatefulSet.

Приклад маніфесту

Цей маніфест містить сервіс та statefulset для розгортання статичного кластера etcd у Kubernetes.

Якщо ви скопіюєте вміст маніфесту у файл з назвою etcd.yaml, його можна застосувати до кластера за допомогою цієї команди.

$ kubectl apply --filename etcd.yaml

Після застосування, зачекайте, поки podʼи стануть готовими.

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-0 1/1 Running 0 24m
etcd-1 1/1 Running 0 24m
etcd-2 1/1 Running 0 24m

Контейнер, використаний у прикладі, включає etcdctl і може бути викликаний безпосередньо всередині podʼів.

Режими відмов

Mon, 01 Jan 0001 00:00:00 +0000

Відмови є звичайним явищем у великому розгортанні машин. Машина виходить з ладу, коли її апаратне або програмне забезпечення виходить з ладу. Кілька машин виходять з ладу одночасно, коли виникають перебої з електроживленням або проблеми з мережею. Також можуть статися кілька видів відмов одночасно; майже неможливо перерахувати всі можливі випадки відмов.

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

Відновлення після катастрофи

Mon, 01 Jan 0001 00:00:00 +0000

etcd розроблений для витримування збоїв машин. Кластер etcd автоматично відновлюється після тимчасових збоїв (наприклад, перезавантаження машини) і витримує до (N-1)/2 постійних збоїв для кластера з N учасників. Коли учасник постійно виходить з ладу, хай то через апаратний збій або пошкодження диска, він втрачає доступ до кластера. Якщо кластер постійно втрачає більше ніж (N-1)/2 учасників, то він катастрофічно виходить з ладу, безповоротно втрачаючи кворум. Після втрати кворуму кластер не може досягти консенсусу і, отже, не може продовжувати приймати оновлення.

etcd gateway

Mon, 01 Jan 0001 00:00:00 +0000

Що таке etcd gateway

etcd gateway — це простий TCP-проксі, який пересилає мережеві дані до кластера etcd. Шлюз є stateless та прозорим; він не перевіряє запити клієнтів і не втручається у відповіді кластера. Він не термінує TLS-зʼєднання, не виконує TLS-рукостискання від імені своїх клієнтів і не перевіряє, чи є зʼєднання захищеним.

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

gRPC proxy

Mon, 01 Jan 0001 00:00:00 +0000

gRPC proxy — це stateless зворотний проксі-сервер etcd, що працює на рівні gRPC (L7). Проксі-сервер призначений для зменшення загального навантаження на основний кластер etcd. Для горизонтальної масштабованості він обʼєднує запити API спостереження та оренди. Щоб захистити кластер від зловмисних клієнтів, він кешує запити діапазону ключів.

gRPC proxy підтримує кілька точок доступу сервера etcd. Коли проксі-сервер запускається, він випадковим чином вибирає одну точку доступу сервера etcd для використання. Ця точка доступу обслуговує всі запити, доки проксі-сервер не виявить збій точки доступу. Якщо gRPC proxy виявляє збій точки доступу, він перемикається на іншу точку доступу, якщо вона доступна, щоб приховати збої від своїх клієнтів. Інші політики повторних спроб, такі як зважений круговий алгоритм, можуть бути підтримані в майбутньому.

Обслуговування

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

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

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

Моніторинг etcd

Mon, 01 Jan 0001 00:00:00 +0000

Кожен сервер etcd надає локальну інформацію про моніторинг на своєму клієнтському порту через точки доступу http. Дані моніторингу корисні як для перевірки справності системи, так і для налагодження кластера.

Debug endpoint

Якщо встановлено --log-level=debug, сервер etcd експортує інформацію для налагодження на своєму клієнтському порту за шляхом /debug. Будьте обережні при встановленні --log-level=debug, оскільки це призведе до зниження продуктивності та великої кількості логів.

Точка доступу /debug/pprof є стандартною точкою доступу для профілювання виконання Go. Це можна використовувати для профілювання використання CPU, heap, mutex та goroutine. Наприклад, тут go tool pprof отримує топ 10 функцій, де etcd витрачає свій час:

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

Mon, 01 Jan 0001 00:00:00 +0000

Розуміння продуктивності

etcd забезпечує стабільну, стійку високу продуктивність. Два фактори визначають продуктивність: затримка та пропускна здатність. Затримка — це час, необхідний для завершення операції. Пропускна здатність — це загальна кількість операцій, виконаних за певний період часу. Зазвичай середня затримка збільшується зі збільшенням загальної пропускної здатності, коли etcd приймає одночасні запити клієнтів. У звичайних хмарних середовищах, таких як стандартний n-4 у Google Compute Engine (GCE) або аналогічний тип машини на AWS, кластер etcd з трьох учасників завершує запит менш ніж за одну мілісекунду при невеликому навантаженні та може виконувати понад 30 000 запитів на секунду при великому навантаженні.

Дизайн реконфігурації під час виконання

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Двофазні зміни конфігурації забезпечують безпеку кластера

У etcd кожна конфігурація під час виконання повинна проходити через дві фази з міркувань безпеки. Наприклад, щоб додати учасника, спочатку повідомте кластер про нову конфігурацію, а потім запустіть нового учасника.

Переконфігурація під час виконання

Mon, 01 Jan 0001 00:00:00 +0000

etcd підтримує інкрементальну переконфігурацію під час виконання, що дозволяє користувачам оновлювати склад кластера під час роботи.

Запити на переконфігурацію можуть оброблятися лише тоді, коли більшість членів кластера функціонують. Наполегливо рекомендується завжди мати кластер розміром понад два учасники у промисловому середовищі. Небезпечно видаляти члена з двочленного кластера. Більшість у двочленному кластері також становить два. Якщо під час процесу видалення станеться збій, кластер не зможе продовжувати роботу і потребуватиме перезапуску після втрати більшості.

Підтримувані платформи

Mon, 01 Jan 0001 00:00:00 +0000

Рівні підтримки

etcd працює на різних платформах, але гарантії, які він надає, залежать від рівня підтримки платформи:

Рівень 1: повністю підтримується супроводжувачами etcd; etcd гарантовано пройде всі тести, включаючи функціональні тести та тести на надійність.
Рівень 2: etcd гарантовано пройде інтеграційні та наскрізні тести, але не обовʼязково функціональні або тести на надійність.
Рівень 3: etcd гарантовано збирається, може бути злегка протестовано (або ні), тому збірку слід вважати нестабільною.

Поточна підтримка

У наступній таблиці наведено перелік платформ, що підтримуються на даний момент, та відповідний рівень підтримки etcd:

Версіонування

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ описує версії, які підтримуються проєктом etcd.

Версіонування сервісу та підтримувані версії

Версії etcd виражаються як x.y.z, де x — це основна версія, y — це мінорна версія, а z — це версія патчу, відповідно до термінології Семантичного Версіонування. Нові мінорні версії можуть додавати додаткові функції до API.

Проєкт etcd підтримує гілки релізів для поточної версії та попереднього випуску. Наприклад, коли v3.5 є поточною версією, v3.4 підтримується. Коли випускається v3.6, підтримка v3.4 припиняється.

Пошкодження даних

Mon, 01 Jan 0001 00:00:00 +0000

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

Включення виявлення пошкодження даних

Виявлення пошкодження даних можна зробити за допомогою:

Початкової перевірки, яка включається за допомогою прапорця --experimental-initial-corrupt-check.
Періодичної перевірки:
- Хешу ущільненої ревізії, яка включається за допомогою прапорця --experimental-compact-hash-check-enabled.
- Хешу останньої ревізії, яка включається за допомогою прапорця --experimental-corrupt-check-time.

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

Посібник з експлуатації on etcd

Параметри конфігурації

Прапорці командного рядка

Модель транспортної безпеки

Посібник з кластеризації

Огляд

Запуск кластерів etcd у контейнерах

Docker

Запуск одного вузла etcd

Запуск кластерів etcd як Kubernetes StatefulSet

Приклад маніфесту

Режими відмов

Відновлення після катастрофи

etcd gateway

Що таке etcd gateway

gRPC proxy

Рекомендації щодо обладнання

Обслуговування

Огляд

Моніторинг etcd

Debug endpoint

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

Розуміння продуктивності

Дизайн реконфігурації під час виконання

Двофазні зміни конфігурації забезпечують безпеку кластера

Переконфігурація під час виконання

Підтримувані платформи

Рівні підтримки

Поточна підтримка

Версіонування

Версіонування сервісу та підтримувані версії

Пошкодження даних

Включення виявлення пошкодження даних