Protocole du service de découverte

Le protocole de service de découverte aide un nouveau membre etcd à découvrir tous les autres membres du cluster pendant la phase d’initialisation, en utilisant une URL de découverte partagée.

Le protocole de service de découverte n’est utilisé que pendant la phase d’amorçage du cluster, et ne peut pas être utilisé pour la reconfiguration en temps réel ou la surveillance du cluster.

Le protocole utilise un nouveau jeton de découverte pour initialiser un unique cluster etcd. Souvenez-vous qu’un jeton de découverte ne peut représenter qu’un seul cluster etcd. Dès que le protocole de découverte associé à ce jeton est lancé, même s’il échoue en cours de route, il ne doit pas être utilisé pour initialiser un autre cluster etcd.

Le reste de cet article détaille le processus de découverte à l’aide d’exemples correspondant à un cluster de découverte auto-hébergé. Le service public de découverte, discovery.etcd.io, fonctionne de la même manière, mais avec une couche d’interface améliorée qui masque les URL complexes, génère automatiquement des UUID et met en place certaines protections contre les requêtes excessives. Au cœur de ce service public, un cluster etcd est toujours utilisé comme magasin de données, comme décrit dans ce document.

Flot de protocole

L’idée du protocole de découverte consiste à utiliser un cluster etcd interne pour coordonner le démarrage d’un nouveau cluster. Tout d’abord, tous les nouveaux membres interagissent avec le service de découverte et contribuent à générer la liste de membres attendue. Ensuite, chaque nouveau membre démarre son serveur en utilisant cette liste, ce qui permet d’obtenir la même fonctionnalité que l’option -initial-cluster.

Dans l’exemple de workflow suivant, nous allons présenter chaque étape du protocole au format curl afin de faciliter la compréhension.

Par convention, le protocole de découverte etcd utilise le préfixe de clé _etcd/registry. Si http://example.com héberge un cluster etcd pour le service de découverte, l’URL complète de l’espace de clés de découverte sera http://example.com/v2/keys/_etcd/registry. Nous utiliserons cette URL comme préfixe dans l’exemple.

Création d’un nouveau jeton de découverte

Générez un jeton unique qui identifiera le nouveau cluster. Ce jeton sera utilisé comme préfixe unique dans l’espace de clés de découverte aux étapes suivantes. Une méthode simple consiste à utiliser uuidgen :

UUID=$(uuidgen)

Spécification de la taille attendue du cluster

Le jeton de découverte attend une taille de cluster qui doit être précisée. Cette taille est utilisée par le service de découverte pour savoir quand il a trouvé tous les membres qui formeront initialement le cluster.

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

En général, la taille du cluster est de 3, 5 ou 7. Consultez taille optimale du cluster pour plus de détails.

Mise en marche des processus etcd

Étant donné l’URL de découverte, utilisez-la comme indicateur -discovery et lancez les processus etcd. Chaque processus etcd suivra automatiquement les étapes suivantes en interne s’il reçoit l’indicateur -discovery.

S’enregistrer lui-même

La première étape pour le processus etcd consiste à s’inscrire dans l’URL de découverte en tant que membre. Cela se fait en créant l’ID de membre comme clé dans l’URL de découverte.

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}"

Vérification du statut

Il vérifie la taille attendue du cluster et l’état d’inscription à l’URL de découverte, puis détermine l’action suivante.

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

Si le nombre de membres enregistrés reste insuffisant, l’attente sera poursuivie jusqu’à la réapparition de membres sortis.

Si le nombre de membres enregistrés est supérieur à la taille attendue N, le système considère les N premiers membres enregistrés comme la liste des membres du cluster. Si le membre lui-même figure dans cette liste, la procédure de découverte réussit et il récupère tous les pairs à partir de la liste des membres. Sinon, la procédure de découverte échoue, car le cluster est plein.

Dans l’implémentation etcd, le membre peut vérifier l’état du cluster même avant de s’enregistrer. Il peut donc échouer rapidement si le cluster est plein.

En attente de tous les membres

Le processus d’attente est décrit en détail dans la documentation de l’API etcd .

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

Il continue d’attendre jusqu’à la découverte de tous les membres.

Service de découverte publique

CoreOS Inc. héberge un service de découverte public à https://discovery.etcd.io/ , qui offre plusieurs fonctionnalités pratiques pour faciliter l’utilisation.

Préfixe de masquage de clé

Le service de découverte publique redirigera https://discovery.etcd.io/${UUID} vers le cluster etcd derrière pour la clé située à /v2/keys/_etcd/registry. Il masque le préfixe de clé d’enregistrement afin d’obtenir une URL de découverte plus courte et plus lisible.

Obtenir un nouveau jeton

GET /new

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

Le processus de génération dans le service suit les étapes allant de Création d’un jeton de découverte à Spécification de la taille attendue du cluster .

Vérifier l’état de découverte

GET /${UUID}

L’état de ce jeton de découverte, y compris les machines qui ont été enregistrées, peut être vérifié en demandant la valeur de l’UUID.

Dépôt open source

Le dépôt est situé à https://github.com/coreos/discovery.etcd.io .. Il peut être utilisé pour créer un service de découverte personnalisé.