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

Протокол служби виявлення допомагає новому учаснику 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. Його можна використовувати для створення власної служби виявлення.