Управління кластерами etcd для Kubernetes
etcd — це сумісне та високодоступне сховище ключ-значення, яке використовується як сховище Kubernetes для резервування всіх даних кластера.
Якщо ваш кластер Kubernetes використовує etcd як сховище для резервування, переконайтеся, що у вас є план резервного копіювання даних.
Ви можете знайти докладну інформацію про etcd в офіційній документації.
Перш ніж ви розпочнете
Вам потрібно мати кластер Kubernetes, а також інструмент командного рядка kubectl повинен бути налаштований для взаємодії з вашим кластером. Рекомендується дотримуватися цього керівництва на кластері, що має принаймні два вузли, які не виконують роль вузлів панелі управління. Якщо у вас ще немає кластера, ви можете створити його за допомогою minikube.
Розуміння etcdctl і etcdutl
etcdctl
і etcdutl
— це інструменти командного рядка для взаємодії з кластерами etcd, але вони виконують різні завдання:
etcdctl
— це основний клієнт командного рядка для взаємодії з etcd через мережу. Використовується для повсякденних операцій, таких як керування ключами та значеннями, адміністрування кластера, перевірка здоров'я та багато іншого.etcdutl
— це утиліта адміністратора, призначена для роботи безпосередньо з файлами даних etcd, включаючи міграцію даних між версіями etcd, дефрагментацію бази даних, відновлення знімків і перевірку цілісності даних. Для мережевих операцій слід використовуватиetcdctl
.
Для отримання додаткової інформації про etcdutl
, ви можете звернутися до документації з відновлення etcd.
Передумови
Запускайте etcd як кластер з непарною кількістю членів.
etcd — це розподілена система з вибором лідера. Переконайтеся, що лідер періодично відправляє своїм підписникам пульси вчасно, щоб зберегти стабільність кластера.
Переконайтеся, що не виникає нестачі ресурсів.
Продуктивність і стабільність кластера чутлива до наявності ресурсів мережі та введення/виведення даних на диск. Будь-яка нестача ресурсів може призвести до вичерпання тайм-ауту пульсу, що призводить до нестабільності кластера. Нестабільний etcd вказує на те, що лідер не обраний. У таких обставинах кластер не може вносити зміни у свій поточний стан, що означає, що нові Podʼи не можуть бути заплановані.
Забезпечення стабільності кластерів etcd є критичним для стабільності кластерів Kubernetes. Тому запускайте кластери etcd на виділених машинах або в ізольованих середовищах для забезпечення гарантованих вимог на ресурси.
Мінімально рекомендовані версії etcd для використання в операційній діяльності —
3.4.22+
та3.5.6+
.
Вимоги до ресурсів
Використання etcd з обмеженими ресурсами підходить лише для тестування. Для розгортання в операційній діяльності потрібна розширена конфігурація апаратного забезпечення. Перед розгортанням etcd в операційному оточені перегляньте довідка щодо вимог до ресурсів.
Запуск кластерів etcd
У цьому розділі розглядається запуск одно- та багатовузлового кластерів etcd.
Одновузловий кластер etcd
Використовуйте одновузловий кластер etcd лише для тестування.
Виконайте наступне:
etcd --listen-client-urls=http://$PRIVATE_IP:2379 \ --advertise-client-urls=http://$PRIVATE_IP:2379
Запустіть сервер API Kubernetes з прапорцем
--etcd-servers=$PRIVATE_IP:2379
.Переконайтеся, що
PRIVATE_IP
встановлено на ваш IP-адрес клієнта etcd.
Багатовузловий кластер etcd
Для забезпечення надійності та високої доступності запускайте etcd як багатовузловий кластер для операційної діяльності та періодично робіть резервні копії. В операційній діяльності рекомендується використовувати кластер з пʼятьма членами. Для отримання додаткової інформації див. ЧаПи.
Налаштуйте кластер etcd або зі статичною інформацією про членів, або за допомогою динамічного виявлення. Для отримання додаткової інформації про кластеризацію див. документацію по кластеризації etcd.
Наприклад, розглянемо кластер etcd з пʼятьох членів, що працює з наступними URL-адресами клієнта: http://$IP1:2379
, http://$IP2:2379
, http://$IP3:2379
, http://$IP4:2379
та http://$IP5:2379
. Щоб запустити сервер API Kubernetes:
Виконайте наступне:
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
Запустіть сервери API Kubernetes з прапорцем
--etcd-servers=$IP1:2379,$IP2:2379,$IP3:2379,$IP4:2379,$IP5:2379
.Переконайтеся, що змінні
IP<n>
встановлені на ваші IP-адреси клієнтів.
Багатовузловий кластер etcd з балансувальником навантаження
Для запуску кластера etcd з балансувальником навантаження:
- Налаштуйте кластер etcd.
- Налаштуйте балансувальник навантаження перед кластером etcd. Наприклад, адреса балансувальника навантаження може бути
$LB
. - Запустіть сервери API Kubernetes з прапорцем
--etcd-servers=$LB:2379
.
Захист кластерів etcd
Доступ до etcd еквівалентний правам кореневого користувача в кластері, тому ідеально, щоб доступ до нього мав лише сервер API. З урахуванням чутливості даних рекомендується надавати дозвіл лише тим вузлам, які потребують доступу до кластерів etcd.
Для захисту etcd налаштуйте правила брандмауера або використовуйте засоби безпеки, надані etcd. Функції безпеки etcd залежать від інфраструктури відкритого ключа x509 (PKI). Для початку налаштуйте безпечні канали звʼязку, згенерувавши пару ключа та сертифікату. Наприклад, використовуйте пари ключів peer.key
та peer.cert
для захисту звʼязку між членами etcd та client.key
та client.cert
для захисту звʼязку між etcd та його клієнтами. Див. приклади скриптів, надані проєктом etcd, для генерації пар ключів та файлів ЦС для автентифікації клієнтів.
Захист комунікації
Для налаштування etcd з безпечною взаємодією між членами вкажіть прапорці --peer-key-file=peer.key
та --peer-cert-file=peer.cert
, та використовуйте протокол HTTPS у схемі URL.
Аналогічно, для налаштування etcd з безпечною взаємодією клієнтів вкажіть прапорці --key-file=k8sclient.key
та --cert-file=k8sclient.cert
, та використовуйте протокол HTTPS у схемі URL. Ось приклад команди клієнта, яка використовує безпечну комунікацію:
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
Після налаштування безпечної комунікації обмежте доступ до кластера 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
Кластер 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
.
Отримайте ідентифікатор несправного
member1
:etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list
Показується наступне повідомлення:
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
Виконайте одне з наступного:
- Якщо кожен сервер API Kubernetes налаштований на спілкування з усіма членами etcd, видаліть несправного члена з прапорця
--etcd-servers
, а потім перезапустіть кожен сервер API Kubernetes. - Якщо кожен сервер API Kubernetes спілкується з одним членом etcd, зупиніть сервер API Kubernetes, який спілкується з несправним etcd.
- Якщо кожен сервер API Kubernetes налаштований на спілкування з усіма членами etcd, видаліть несправного члена з прапорця
Зупиніть сервер etcd на несправному вузлі. Можливо, інші клієнти окрім сервера API Kubernetes створюють трафік до etcd, і бажано зупинити весь трафік, щоб запобігти записам до теки з даними.
Видаліть несправного члена:
etcdctl member remove 8211f1d0f64f3269
Показується наступне повідомлення:
Removed member 8211f1d0f64f3269 from cluster
Додайте нового члена:
etcdctl member add member4 --peer-urls=http://10.0.0.4:2380
Показується наступне повідомлення:
Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4
Запустіть новододаного члена на машині з IP
10.0.0.4
: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]
Виконайте одне з наступного:
- Якщо кожен сервер API Kubernetes налаштований на спілкування з усіма членами etcd, додайте новододаного члена до прапорця
--etcd-servers
, а потім перезапустіть кожен сервер API Kubernetes. - Якщо кожен сервер API Kubernetes спілкується з одним членом etcd, запустіть сервер API Kubernetes, який був зупинений на кроці 2. Потім налаштуйте клієнти сервера API Kubernetes знову маршрутизувати запити до сервера API Kubernetes, який був зупинений. Це часто можна зробити, налаштувавши балансувальник навантаження.
- Якщо кожен сервер API Kubernetes налаштований на спілкування з усіма членами etcd, додайте новододаного члена до прапорця
За додатковою інформацією про налаштування кластера etcd див. документацію з переналаштування etcd.
Резервне копіювання кластера etcd
Усі обʼєкти Kubernetes зберігаються в etcd. Періодичне резервне копіювання даних кластера etcd важливо для відновлення кластерів Kubernetes у випадку катастрофи, такої як втрата всіх вузлів панелі управління. Файл знімка містить весь стан Kubernetes та критичну інформацію. Для збереження конфіденційних даних Kubernetes в безпеці зашифруйте файли знімків.
Резервне копіювання кластера etcd можна виконати двома способами: вбудованим засобами знімків etcd та знімком тому.
Вбудовані засоби знімків
etcd підтримує вбудовані засоби знімків. Знімок можна створити з активного члена за допомогою команди etcdctl snapshot save
або скопіювавши файл member/snap/db
з теки даних etcd, яка в цей момент не використовується процесом etcd. Створення знімка не вплине на продуктивність члена.
Нижче наведено приклад створення знімка простору ключів, який обслуговується за адресою $ENDPOINT
, у файл snapshot.db
:
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
Ми також можемо створити знімок, використовуючи різноманітні параметри, надані etcdctl. Наприклад:
ETCDCTL_API=3 etcdctl -h
покаже різні параметри, доступні з etcdctl. Наприклад, ви можете створити знімок, вказавши точку доступу, сертифікати та ключ, як показано нижче:
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
snapshot save <backup-file-location>
де trusted-ca-file
, cert-file
та key-file
можна отримати з опису модуля etcd.
Масштабування кластерів etcd
Масштабування кластерів etcd підвищує доступність шляхом зниження продуктивності. Масштабування не збільшує продуктивність або можливості кластера. Загальне правило — не масштабуйте кластери etcd. Не налаштовуйте жодних автоматичних груп масштабування для кластерів etcd. Настійно рекомендується завжди запускати статичний кластер etcd з 5-ти членів для операційних кластерів Kubernetes будь-якого офіційно підтримуваного масштабу.
Доречне масштабування — це оновлення кластера з трьох до пʼяти членів, коли потрібно більше надійності. Див. документацію з переконфігурації etcd для інформації про те, як додавати учасників у наявний кластер.
Відновлення кластера etcd
etcd підтримує відновлення зі знімків, які були створені з процесу etcd версії major.minor. Відновлення версії з іншої версії патча etcd також підтримується. Операція відновлення використовується для відновлення даних несправного кластера.
Перед початком операції відновлення повинен бути наявний файл знімка. Це може бути файл знімка з попередньої операції резервного копіювання або теки даних, що залишилась.
Під час відновлення кластера використовуючи 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 після відновлення, щоб він використовував нову теку даних.
Для отримання додаткової інформації та прикладів відновлення кластера з файлу знімка, див. документацію з відновлення після збою etcd.
Якщо доступні 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, щоб усунути проблему.
Примітка:
Якщо в вашому кластері працюють будь-які сервери API, вам не слід намагатися відновити екземпляри etcd. Замість цього дотримуйтесь цих кроків для відновлення etcd:
- зупиніть всі екземпляри сервера API
- відновіть стан у всіх екземплярах etcd
- перезапустіть всі екземпляри сервера API
Ми також рекомендуємо перезапустити будь-які компоненти (наприклад, kube-scheduler
, kube-controller-manager
, kubelet
), щоб переконатися, що вони не покладаються на застарілі дані. Зауважте, що на практиці відновлення займає трохи часу. Під час відновлення критичні компоненти втрачатимуть блокування лідера та перезапускатимуться.
Оновлення кластерів etcd
Для отримання додаткових відомостей щодо оновлення etcd дивіться документацію з оновлення etcd.
Примітка:
Перш ніж ви розпочнете оновлення, будь ласка, спочатку зробіть резервне копіювання свого кластера etcd.Обслуговування кластерів etcd
Для отримання додаткових відомостей щодо обслуговування etcd дивіться документацію з обслуговування etcd.
Примітка:
Дефрагментація є дорогою операцією, тому її слід виконувати якомога рідше. З іншого боку, також необхідно переконатися, що жоден з учасників etcd не перевищить квоту зберігання. Проєкт Kubernetes рекомендує, що при виконанні дефрагментації ви використовували інструмент, такий як etcd-defrag.
Ви також можете запускати інструмент дефрагментації як Kubernetes CronJob, щоб переконатися, що дефрагментація відбувається регулярно. Дивіться etcd-defrag-cronjob.yaml
для отримання деталей.
Елементи на цій сторінці відносяться до сторонніх продуктів чи проєктів, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Ознайомтесь з настановами на вебсайті CNCF для отримання докладної інформації.
Ознайомтесь з посібником з контенту перед тим, як пропонувати додавання посилання на стороні компоненти.