# Управління кластерами etcd для Kubernetes LLMS index: [llms.txt](/llms.txt) ---

etcd — це надійне та високодоступне сховище ключ-значення, яке використовується як сховище Kubernetes для всіх даних кластера.

Якщо ваш кластер Kubernetes використовує etcd як основне сховище, переконайтеся, що у вас є план резервного копіювання даних.

Ви можете знайти докладну інформацію про etcd в офіційній документації.

## Перш ніж ви розпочнете Перш ніж слідувати інструкціям на цій сторінці щодо розгортання, керування, резервного копіювання або відновлення etcd, необхідно зрозуміти типові очікування при експлуатації кластера etcd. Зверніться до [документації etcd](https://etcd.io/docs/) для отримання додаткової інформації. Основні деталі включають: * Мінімальні рекомендовані версії etcd для використання в операційній діяльності: `3.4.29+` і `3.5.11+`. * etcd є розподіленою системою з визначенням лідера. Забезпечте, щоб лідер періодично надсилав своєчасні сигнали всім підлеглим для підтримки стабільності кластера. * Ви повинні запускати etcd як кластер з непарною кількістю членів. * Намагайтеся уникати виснаження ресурсів. Продуктивність і стабільність кластера чутлива до наявності ресурсів мережі та введення/виведення даних на диск. Будь-яка нестача ресурсів може призвести до вичерпання тайм-ауту пульсу, що призводить до нестабільності кластера. Нестабільність etcd означає, що лідер не обраний. У таких обставинах кластер не може вносити зміни до свого поточного стану, що означає, що нові Podʼи не можуть бути заплановані. ### Вимоги до ресурсів для etcd Експлуатація etcd з обмеженими ресурсами підходить тільки для тестових цілей. Для розгортання в операційній діяльності потрібна розширена конфігурація обладнання. Перед розгортанням etcd в операційній діяльності дивіться [довідник щодо вимог до ресурсів](https://etcd.io/docs/current/op-guide/hardware/#example-hardware-configurations). Підтримання стабільності кластерів etcd є критичним для стабільності кластерів Kubernetes. Тому запускайте кластери etcd на виділених машинах або в ізольованих середовищах для [гарантованих вимог до ресурсів](https://etcd.io/docs/current/op-guide/hardware/). ### Інструменти Залежно від конкретного завдання, яке ви виконуєте, вам знадобиться інструмент `etcdctl` або `etcdutl` (можливо, обидва). ## Розуміння etcdctl і etcdutl {#understanding-etcdctl-and-etcdutl} `etcdctl` і `etcdutl` — це інструменти командного рядка для взаємодії з кластерами etcd, але вони виконують різні завдання: * `etcdctl` — це основний клієнт командного рядка для взаємодії з etcd через мережу. Використовується для повсякденних операцій, таких як керування ключами та значеннями, адміністрування кластера, перевірка справності та багато іншого. * `etcdutl` — це утиліта адміністратора, призначена для роботи безпосередньо з файлами даних etcd, включаючи міграцію даних між версіями etcd, дефрагментацію бази даних, відновлення знімків і перевірку цілісності даних. Для мережевих операцій слід використовувати `etcdctl`. Для отримання додаткової інформації про `etcdutl`, ви можете звернутися до [документації з відновлення etcd](https://etcd.io/docs/v3.5/op-guide/recovery/). ## Запуск кластерів etcd {#starting-etcd-clusters} У цьому розділі розглядається запуск одно- та багатовузлового кластерів etcd. Це керівництво передбачає, що `etcd` встановлено. ### Одновузловий кластер etcd {#single-node-etcd-cluster} Використовуйте одновузловий кластер etcd лише для тестування. 1. Виконайте наступне: ```sh etcd --listen-client-urls=http://$PRIVATE_IP:2379 \ --advertise-client-urls=http://$PRIVATE_IP:2379 ``` 2. Запустіть сервер API Kubernetes з прапорцем `--etcd-servers=$PRIVATE_IP:2379`. Переконайтеся, що `PRIVATE_IP` встановлено на вашу IP-адресу клієнта etcd. ### Багатовузловий кластер etcd {#multi-node-etcd-cluster} Для забезпечення надійності та високої доступності запускайте etcd як багатовузловий кластер для операційної діяльності та періодично робіть резервні копії. В операційній діяльності рекомендується використовувати кластер з пʼятьма членами. Для отримання додаткової інформації див. [ЧаПи](https://etcd.io/docs/current/faq/#what-is-failure-tolerance). Оскільки ви використовуєте Kubernetes, у вас є можливість запускати etcd як контейнер всередині одного або декількох Podʼів. Інструмент `kubeadm` типово налаштовує etcd як статичні Podʼи, або ви можете розгорнути [окремий кластер](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) і вказати kubeadm використовувати цей кластер etcd як сховище для панелі управління. Ви можете налаштувати кластер etcd або за допомогою статичної інформації про учасників, або за допомогою динамічного виявлення. Для отримання додаткової інформації про кластеризацію дивіться [документацію з кластеризації etcd](https://etcd.io/docs/current/op-guide/clustering/). Наприклад, розглянемо кластер etcd з пʼятьох членів, що працює з наступними URL-адресами клієнта: `http://$IP1:2379`, `http://$IP2:2379`, `http://$IP3:2379`, `http://$IP4:2379` та `http://$IP5:2379`. Щоб запустити сервер API Kubernetes: 1. Виконайте наступне: ```shell etcd --listen-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 --advertise-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 ``` 2. Запустіть сервери API Kubernetes з прапорцем `--etcd-servers=$IP1:2379,$IP2:2379,$IP3:2379,$IP4:2379,$IP5:2379`. Переконайтеся, що змінні `IP` встановлені на ваші IP-адреси клієнтів. ### Багатовузловий кластер etcd з балансувальником навантаження {#multi-node-etcd-cluster-with-load-balancer} Для запуску кластера etcd з балансувальником навантаження: 1. Налаштуйте кластер etcd. 2. Налаштуйте балансувальник навантаження перед кластером etcd. Наприклад, адреса балансувальника навантаження може бути `$LB`. 3. Запустіть сервери API Kubernetes з прапорцем `--etcd-servers=$LB:2379`. ## Захист кластерів etcd {#securing-etcd-clusters} Доступ до etcd еквівалентний правам користувача root в кластері, тому ідеально, щоб доступ до нього мав лише сервер API. З урахуванням чутливості даних рекомендується надавати дозвіл лише тим вузлам, які потребують доступу до кластерів etcd. Для захисту etcd налаштуйте правила брандмауера або використовуйте засоби безпеки, надані etcd. Функції безпеки etcd залежать від інфраструктури відкритого ключа x509 (PKI). Для початку налаштуйте безпечні канали звʼязку, згенерувавши пару ключа та сертифікату. Наприклад, використовуйте пари ключів `peer.key` та `peer.cert` для захисту звʼязку між членами etcd та `client.key` та `client.cert` для захисту звʼязку між etcd та його клієнтами. Див. [приклади скриптів](https://github.com/coreos/etcd/tree/master/hack/tls-setup), надані проєктом etcd, для генерації пар ключів та файлів ЦС для автентифікації клієнтів. ### Захист комунікації {#securing-communication} Для налаштування etcd з безпечною взаємодією між членами вкажіть прапорці `--peer-key-file=peer.key` та `--peer-cert-file=peer.cert`, та використовуйте протокол HTTPS у схемі URL. Аналогічно, для налаштування etcd з безпечною взаємодією клієнтів вкажіть прапорці `--key=k8sclient.key` та `--cert=k8sclient.cert`, та використовуйте протокол HTTPS у схемі URL. Ось приклад команди клієнта, яка використовує безпечну комунікацію: ```shell ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ member list ``` ### Обмеження доступу до кластерів etcd {#limiting-access-to-etcd-clusters} Після налаштування безпечної комунікації обмежте доступ до кластера etcd лише для серверів API Kubernetes, використовуючи автентифікацію TLS. Наприклад, розгляньте пари ключів `k8sclient.key` та `k8sclient.cert`, яким довіряє ЦС `etcd.ca`. Коли etcd налаштовано з параметром `--client-cert-auth` разом з TLS, він перевіряє сертифікати від клієнтів, використовуючи системні ЦС або ЦС, передані за допомогою прапорця `--trusted-ca-file`. Вказівка прапорців `--client-cert-auth=true` та `--trusted-ca-file=etcd.ca` обмежить доступ до клієнтів з сертифікатом `k8sclient.cert`. Після коректного налаштування etcd до нього можуть отримувати доступ лише клієнти з дійсними сертифікатами. Щоб дати серверам API Kubernetes доступ, налаштуйте їх з прапорцями `--etcd-certfile=k8sclient.cert`, `--etcd-keyfile=k8sclient.key` та `--etcd-cafile=ca.cert`.

Примітка:

Автентифікація etcd не планується для Kubernetes.
## Заміна несправного члена etcd {#replacing-failed-etcd-member} Кластер etcd досягає високої доступності, толеруючи невеликі відмови членів. Однак, для покращення загального стану кластера, замінюйте несправних членів негайно. Коли відмовляють декілька членів, замінюйте їх по одному. Заміна несправного члена включає два кроки: видалення несправного члена та додавання нового члена. Хоча etcd зберігає унікальні ідентифікатори членів всередині, рекомендується використовувати унікальне імʼя для кожного члена, щоб уникнути фактора людської помилки. Наприклад, розгляньте кластер etcd з трьох членів. Нехай URL буде таким: `member1=http://10.0.0.1`, `member2=http://10.0.0.2`, і `member3=http://10.0.0.3`. Коли відмовляє `member1`, замініть його на `member4=http://10.0.0.4`. 1. Отримайте ідентифікатор несправного `member1`: ```shell etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list ``` Показується наступне повідомлення: ```console 8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379 91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379 fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379 ``` 2. Виконайте одне з наступного: 1. Якщо кожен сервер API Kubernetes налаштований на спілкування з усіма членами etcd, видаліть несправного члена з прапорця `--etcd-servers`, а потім перезапустіть кожен сервер API Kubernetes. 2. Якщо кожен сервер API Kubernetes спілкується з одним членом etcd, зупиніть сервер API Kubernetes, який спілкується з несправним etcd. 3. Зупиніть сервер etcd на несправному вузлі. Можливо, інші клієнти окрім сервера API Kubernetes створюють трафік до etcd, і бажано зупинити весь трафік, щоб запобігти записам до теки з даними. 4. Видаліть несправного члена: ```shell etcdctl member remove 8211f1d0f64f3269 ``` Показується наступне повідомлення: ```console Removed member 8211f1d0f64f3269 from cluster ``` 5. Додайте нового члена: ```shell etcdctl member add member4 --peer-urls=http://10.0.0.4:2380 ``` Показується наступне повідомлення: ```console Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4 ``` 6. Запустіть новододаного члена на машині з IP `10.0.0.4`: ```shell export ETCD_NAME="member4" export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380" export ETCD_INITIAL_CLUSTER_STATE=existing etcd [flags] ``` 7. Виконайте одне з наступного: 1. Якщо кожен сервер API Kubernetes налаштований на спілкування з усіма членами etcd, додайте новододаного члена до прапорця `--etcd-servers`, а потім перезапустіть кожен сервер API Kubernetes. 2. Якщо кожен сервер API Kubernetes спілкується з одним членом etcd, запустіть сервер API Kubernetes, який був зупинений на кроці 2. Потім налаштуйте клієнти сервера API Kubernetes знову маршрутизувати запити до сервера API Kubernetes, який був зупинений. Це часто можна зробити, налаштувавши балансувальник навантаження. За додатковою інформацією про налаштування кластера etcd див. [документацію з переналаштування etcd](https://etcd.io/docs/current/op-guide/runtime-configuration/#remove-a-member). ## Резервне копіювання кластера etcd {#backing-up-an-etcd-cluster} Усі обʼєкти Kubernetes зберігаються в etcd. Періодичне резервне копіювання даних кластера etcd важливо для відновлення кластерів Kubernetes у випадку катастрофи, такої як втрата всіх вузлів панелі управління. Файл знімка містить весь стан Kubernetes та критичну інформацію. Для збереження конфіденційних даних Kubernetes в безпеці зашифруйте файли знімків. Резервне копіювання кластера etcd можна виконати двома способами: вбудованим засобами знімків etcd та знімком тому. ### Вбудовані засоби знімків {#built-in-snapshot} etcd підтримує вбудовані засоби знімків. Знімок можна створити з активного члена за допомогою команди `etcdctl snapshot save` або скопіювавши файл `member/snap/db` з [теки даних etcd](https://etcd.io/docs/current/op-guide/configuration/#--data-dir), яка в цей момент не використовується процесом etcd. Створення знімка не вплине на продуктивність члена. Нижче наведено приклад створення знімка простору ключів, який обслуговується за адресою `$ENDPOINT`, у файл `snapshot.db`: ```shell ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshot.db ``` Перевірте знімок:

Приклад нижче показує, як використовувати etcdutl для перевірки знімка:

etcdutl --write-out=table snapshot status snapshot.db

Це повинно згенерувати результат, подібний до наведеного нижче прикладу:

+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 |       10 |          7 | 2.1 MB     |
+----------+----------+------------+------------+

Примітка:

Використання etcdctl snapshot status є застарілим починаючи з версії etcd v3.5.x і планується до вилучення у версії v3.6. Натомість рекомендується використовувати etcdutl.

Приклад нижче показує, як використовувати etcdctl для перевірки знімка:

export ETCDCTL_API=3
etcdctl --write-out=table snapshot status snapshot.db

Це повинно згенерувати результат, подібний до наведеного нижче прикладу:

Застаріло: Використовуйте `etcdutl snapshot status` натомість.

+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 |       10 |          7 | 2.1 MB     |
+----------+----------+------------+------------+
### Знімок тому {#volume-snapshot} Якщо etcd працює за томом сховища, який підтримує резервне копіювання, наприклад, Amazon Elastic Block Store, зробіть резервну копію даних etcd, створивши знімок тому сховища. ### Знімок за допомогою параметрів etcdctl {#snapshot-using-etcdctl-options} Ми також можемо створити знімок, використовуючи різноманітні параметри, надані etcdctl. Наприклад: ```shell ETCDCTL_API=3 etcdctl -h ``` покаже різні параметри, доступні з etcdctl. Наприклад, ви можете створити знімок, вказавши точку доступу, сертифікати та ключ, як показано нижче: ```shell ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \ --cacert= --cert= --key= \ snapshot save ``` де `trusted-ca-file`, `cert-file` та `key-file` можна отримати з опису модуля etcd. ## Масштабування кластерів etcd {#scaling-out-etcd-clusters} Масштабування кластерів etcd підвищує доступність шляхом зниження продуктивності. Масштабування не збільшує продуктивність або можливості кластера. Загальне правило — не масштабуйте кластери etcd. Не налаштовуйте жодних автоматичних груп масштабування для кластерів etcd. Наполегливо рекомендується завжди запускати статичний кластер etcd з 5-ти членів для операційних кластерів Kubernetes будь-якого офіційно підтримуваного масштабу. Доречне масштабування — це оновлення кластера з трьох до пʼяти членів, коли потрібно більше надійності. Див. [документацію з переконфігурації etcd](https://etcd.io/docs/current/op-guide/runtime-configuration/#remove-a-member) для інформації про те, як додавати учасників у наявний кластер. ## Відновлення кластера etcd {#restoring-an-etcd-cluster}

Увага:

Якщо будь-які API-сервери працюють у вашому кластері, ви не повинні намагатися відновлювати екземпляри etcd. Замість цього дотримуйтесь цих кроків для відновлення etcd:

  • зупиніть усі екземпляри API-сервера
  • відновіть стан у всіх екземплярах etcd
  • перезапустіть усі екземпляри API-сервера

Проєкт Kubernetes також рекомендує перезапускати компоненти Kubernetes (kube-scheduler, kube-controller-manager, kubelet), щоб гарантувати, що вони не покладаються на застарілі дані. На практиці відновлення займає деякий час. Під час відновлення критичні компоненти втратять блокування лідера і перезапустяться.

etcd підтримує відновлення зі знімків, які були створені з процесу etcd версії [major.minor](https://semver.org/lang/uk/). Відновлення версії з іншої версії патча etcd також підтримується. Операція відновлення використовується для відновлення даних несправного кластера. Перед початком операції відновлення повинен бути наявний файл знімка. Це може бути файл знімка з попередньої операції резервного копіювання або [теки даних](https://etcd.io/docs/current/op-guide/configuration/#--data-dir), що залишилась.

Під час відновлення кластера використовуючи etcdutl використовуйте опцію --data-dir, щоб вказати, у яку теку слід відновити кластер:

etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db

де <data-dir-location> — це тека, яка буде створена під час процесу відновлення.

Примітка:

Використання etcdctl для відновлення застаріло починаючи з версії etcd v3.5.x і планується до вилучення у версії v3.6. Натомість рекомендується використовувати etcdutl.

У наведеному нижче прикладі показано використання інструмента etcdctl для операції відновлення:

export ETCDCTL_API=3
etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db

Якщо <data-dir-location> є тою самою текою, що й раніше, видаліть її та зупиніть процес etcd перед відновленням кластера. В іншому випадку, змініть конфігурацію etcd і перезапустіть процес etcd після відновлення, щоб він використовував нову теку даних: спочатку змініть /etc/kubernetes/manifests/etcd.yaml у volumes.hostPath.path для name: etcd-data на <data-dir-location>, потім виконайте kubectl -n kube-system delete pod <name-of-etcd-pod> або systemctl restart kubelet.service (або обидві команди).

Для отримання додаткової інформації та прикладів відновлення кластера з файлу знімка, див. [документацію з відновлення після збою etcd](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster). Якщо доступні URL-адреси відновленого кластера відрізняються від попереднього кластера, сервер API Kubernetes повинен бути відповідно переконфігурований. У цьому випадку перезапустіть сервери API Kubernetes з прапорцем `--etcd-servers=$NEW_ETCD_CLUSTER` замість прапорця `--etcd-servers=$OLD_ETCD_CLUSTER`. Замініть `$NEW_ETCD_CLUSTER` та `$OLD_ETCD_CLUSTER` на відповідні IP-адреси. Якщо перед кластером etcd використовується балансувальник навантаження, можливо, потрібно оновити балансувальник навантаження. Якщо більшість членів etcd є остаточно несправними, кластер etcd вважається несправним. У цьому сценарії Kubernetes не може вносити зміни у свій поточний стан. Хоча заплановані Podʼи можуть продовжувати працювати, нові Podʼи не можуть бути заплановані. У таких випадках відновіть кластер etcd та, можливо, переконфігуруйте сервери API Kubernetes, щоб усунути проблему. ## Оновлення кластерів etcd {#upgrading-etcd-clusters}

Увага:

Перш ніж ви розпочнете оновлення, будь ласка, спочатку зробіть резервне копіювання свого кластера etcd.
Для отримання додаткових відомостей щодо оновлення etcd дивіться [документацію з оновлення](https://etcd.io/docs/latest/upgrades/) etcd. ## Обслуговування кластерів etcd {#maintaining-etcd-clusters} Для отримання додаткових відомостей щодо обслуговування etcd дивіться [документацію з обслуговування](https://etcd.io/docs/latest/op-guide/maintenance/) etcd. ### Дефрагментація кластера {#cluster-defragmentation}
🛇 Цей елемент посилається на сторонній проєкт або продукт, який не є частиною Kubernetes. Докладніше
Дефрагментація є дорогою операцією, тому її слід виконувати якомога рідше. З іншого боку, також необхідно переконатися, що жоден з учасників etcd не перевищить квоту зберігання. Проєкт Kubernetes рекомендує, що при виконанні дефрагментації ви використовували інструмент, такий як [etcd-defrag](https://github.com/ahrtr/etcd-defrag). Ви також можете запускати інструмент дефрагментації як Kubernetes CronJob, щоб переконатися, що дефрагментація відбувається регулярно. Дивіться [`etcd-defrag-cronjob.yaml`](https://github.com/ahrtr/etcd-defrag/blob/main/doc/etcd-defrag-cronjob.yaml) для отримання деталей.