Протокол служби виявлення

Протокол служби виявлення допомагає новому учаснику etcd виявити всіх інших учасників у фазі завантаження кластера за допомогою спільної URL-адреси виявлення.

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

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

У решті статті ми розглянемо процес виявлення на прикладах, які відповідають кластеру виявлення, що розміщується на власному хостингу. Публічна служба виявлення, discovery.etcd.io, функціонує так само, але з додатковим шаром для абстрагування некрасивих URL-адрес, автоматичного генерування UUID і надання деяких захистів від надмірних запитів. У своїй основі публічна служба виявлення все ще використовує кластер etcd як сховище даних, як описано в цьому документі.

Робочий процес протоколу

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

У наступному прикладі робочого процесу ми перераховуємо кожен крок протоколу у форматі curl для зручності розуміння.

За звичаєм протокол виявлення etcd використовує префікс ключа _etcd/registry. Якщо http://example.com розміщує кластер etcd для служби виявлення, повна URL-адреса до простору ключів виявлення буде http://example.com/v2/keys/_etcd/registry. Ми будемо використовувати це як префікс URL у прикладі.

Створення нового токена виявлення

Згенеруйте унікальний токен, який буде ідентифікувати новий кластер. Це буде використано як унікальний префікс у просторі ключів виявлення у наступних кроках. Легкий спосіб зробити це — використовувати uuidgen:

UUID=$(uuidgen)

Вказання очікуваного розміру кластера

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

curl -X PUT http://example.com/v2/keys/_etcd/registry/${UUID}/_config/size -d value=${cluster_size}

Зазвичай розмір кластера становить 3, 5 або 7. Перевірте оптимальний розмір кластера для отримання додаткової інформації.

Запуск процесів etcd

Враховуючи URL-адресу виявлення, використовуйте її як прапорець -discovery і запускайте процеси etcd. Кожен процес etcd буде виконувати наступні кілька кроків внутрішньо, якщо вказано прапорець -discovery.

Реєстрація себе

Перше, що робить процес etcd, це реєструє себе в URL-адресі виявлення як учасника. Це робиться шляхом створення ідентифікатора учасника як ключа у URL-адресі виявлення.

curl -X PUT http://example.com/v2/keys/_etcd/registry/${UUID}/${member_id}?prevExist=false -d value="${member_name}=${member_peer_url_1}&${member_name}=${member_peer_url_2}"

Перевірка статусу

Перевіряється очікуваний розмір кластера і статус реєстрації у URL-адресі виявлення та вирішується, що робити далі.

curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}/_config/size
curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}

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

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

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

Очікування всіх учасників

Процес очікування докладно описаний у документації API etcd.

curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}?wait=true&waitIndex=${current_etcd_index}

Учасник продовжує чекати, поки не знайде всіх учасників.

Публічна служба виявлення

CoreOS Inc. розміщує публічну службу виявлення за адресою https://discovery.etcd.io/, яка надає деякі приємні функції для зручності використання.

Маскування префіксу ключа

Публічна служба виявлення перенаправляє https://discovery.etcd.io/${UUID} на кластер etcd позаду для ключа за адресою /v2/keys/_etcd/registry. Вона маскує префікс ключа реєстрації для короткої та читабельної URL-адреси виявлення.

Отримання нового токена

GET /new

Sent query:
	size=${cluster_size}
Possible status codes:
	200 OK
	400 Bad Request
200 Body:
	generated discovery url

Процес генерації у службі слідує крокам від Створення нового токена виявлення до Вказання очікуваного розміру кластера.

Перевірка статусу виявлення

GET /${UUID}

Статус цього токена виявлення, включаючи машини, які були зареєстровані, можна перевірити, запитуючи значення UUID.

Репозиторій з відкритим вихідним кодом

Репозиторій знаходиться за адресою https://github.com/coreos/discovery.etcd.io. Його можна використовувати для створення власної служби виявлення.