ETCD : découverte et premiers pas

ETCD est un élément très important d’un cluster Kubernetes. Sans lui, le cluster n’existe plus. On va découvrir ensemble ce qu’est ETCD et à quoi ça sert au sein d’un cluster Kubernetes.

Warning

Ce contenu date un peu, il est possible que les éléments présentés aient changés depuis.

Table of Contents

ETCD : qu’est-ce que c’est ?

ETCD est une base de données distribuée de type clé/valeur.

ETCD est open-source, développé en Go, fait parti des incubateurs de la CNCF (Cloud Native Computing Fundation) et est utilisé par de gros projets tels que Kubernetes, OpenStack, Rook, etc…

ETCD : comparaison avec une base de données « classique »

Base de données « classique »

1 colonne = 1 attribut
duplication des lignes possible

Dans une base de données « classique », une colonne est égale à un attribut. Ici ce sont les attributs « prénom » et « âge ». Chaque ligne de cette table représente alors un enregistrement.

Il peut bien évidemment y avoir plusieurs « Nicolas » ou plusieurs personne qui ont « 30 » en âge dans une base de données classique (sauf si l’un de ces attributs est une clé unique).

ETCD – Base de données clé/valeur

clés uniques !
n’est pas un remplacement d’une BDD “classique”
travailler avec de petits morceaux de données (ex. : éléments de configuration)
opérations écriture/lecture rapides

Dans une base de données de type clé/valeur comme ETCD, il y a deux colonnes : « clé » et « valeur ». Lorsque l’on ajoute un enregistrement on spécifie le nom de la clé ainsi que sa valeur. Il ne peut pas y avoir plusieurs clés similaires.

Les bases de données telles que ETCD sont très pratiques pour stocker des éléments de configuration comme par exemple un mot de passe de connexion, l’ip d’une machine, etc…

De plus, ETCD est spécialisé dans les opération d’écriture et de lecture très rapides.

ETCD : installation simple et rapide

En soit, ETCD est très simple à installer et à utiliser. Bien évidemment, cela se complexifie lorsque l’on veut faire de la haute disponibilité avec un cluster ETCD.

Dans cette partie je vous montre très basiquement comment installer ETCD en mode mono-nœud. Je rappelle que dans un environnement de production il est conseillé d’avoir un cluster ETCD.

Par défaut ETCD écoute sur le port 2379.

Télécharger le binaire ETCD

ETCD_VER=v3.3.8

# choose either URL
GOOGLE_URL=https://storage.googleapis.com/etcd
GITHUB_URL=https://github.com/coreos/etcd/releases/download
DOWNLOAD_URL=${GOOGLE_URL}

rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
rm -rf /tmp/test-etcd && mkdir -p /tmp/test-etcd

curl -L ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz -o /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
tar xzvf /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz -C /tmp/test-etcd --strip-components=1

# sudo cp /tmp/test-etcd/etcd* [YOUR_EXEC_DIR]
# sudo mkdir -p /usr/local/bin/ && sudo cp /tmp/test-etcd/etcd* /usr/local/bin/

/tmp/test-etcd/etcd --version
ETCDCTL_API=3 /tmp/test-etcd/etcdctl version

Extraire le binaire ETCD

ETCD_VER=v3.3.8

tar xzvf /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz -C /tmp/test-etcd --strip-components=1

sudo cp /tmp/test-etcd/etcd* [YOUR_EXEC_DIR]

sudo mkdir -p /usr/local/bin/ && sudo cp /tmp/test-etcd/etcd* /usr/local/bin/

Démarrer ETCD

/tmp/test-etcd/etcd

ETCDCTL_API=3 /tmp/test-etcd/etcdctl version

Lien officiel pour l’installation : http://play.etcd.io/install

ETCD : utilisation basique

Voyons maintenant comment utiliser très basiquement ETCD. Encore une fois je précise que je ne vais pas faire une démonstration complète. Si ETCD vous intéresse je vous conseille d’aller voir le site officiel, la documentation est bien faite.

On va utiliser le CLI « etcdctl » afin d’interagir avec notre mono-nœud ETCD.

Démarrer le service

# Ou simplement etcd si le binaire est dans votre path
/tmp/test-etcd/etcd

Stocker une valeur

etcdctl set key1 value1

Récupérer une valeur

etcdctl get key1value1

Output de base

ETCDCTL_API=3 /tmp/test-etcd/etcdctl

NAME:
        etcdctl - A simple command line client for etcd3.

USAGE:
        etcdctl

VERSION:
        3.3.8

API VERSION:
        3.3

ETCD dans Kubernetes

La partie la plus intéressante maintenant. Quel est le rôle d’ETCD dans un cluster Kubernetes ? Pourquoi est-il si important ? Nous allons voir ensemble quelques points clés de l’utilisation d’ETCD au sein d’un cluster Kubernetes.

Je vous invite à aller voir la très bonne partie de la documentation officielle de Kubernetes sur ETCD.

Il peut être déployé sous forme de pod

Il est tout à fait possible de déployer ETCD en utilisant des pods Kubernetes. C’est d’ailleurs ce que fait l’utilitaire « kubeadm » lorsqu’il déploie un nouveau cluster Kubernetes.

Il utilise TLS pour sécuriser ses communications

ETCD utilise TLS afin de sécuriser et d’authentifier les requêtes. Les clients ETCD d’un cluster Kubernetes utilisent des certificats pour cela.

Il stocke les données du cluster

Vous vous en doutiez, il stocke toutes les données du cluster, notamment celles qui concernent :

les pods
les nœuds
les configs
les secrets
les comptes
les rôles
les bindings
etc…

ETCD stocke vraiment tout de notre cluster Kubernetes !

Avec kubectl, vous interagissez indirectement avec ETCD

Et oui ! Lorsque vous utilisez « kubectl », la requête par vers l’API Server qui interagit alors avec ETCD et vous retourne les résultats. Le seul élément qui utilise vraiment ETCD est toujours l’API Server. Les autres composants Kubernetes passent toujours par lui pour récupérer ou inscrire des données.

Il est LA source de vérité

Il est la seule et l’unique source de vérité du cluster. S’il y a marqué « noir » dans ETCD, alors c’est noir. Si y a marqué que le pod est dpéloyé, alors il l’est.

Tout est stocké dans ETCD

On en parlait avant, ETCD stocke les données du cluster. Mais il stocke également les états du cluster. Le bougre stocke vraiment tout ! C’est important de le souligner pour les prochains points.

Un élément stocké dans ETCD = considéré totalement complété

Cela rejoint le fait qu’il est source de vérité absolue au sein d’un cluster Kubernetes. Si un élément est stocké dans ETCD, il est considéré comme totalement complété. C’est le cas par exemple de l’enregistrement des états des pods. Si un pod est marqué prêt, il l’est.

ETCD perdu = cluster Kubernetes perdu

Et c’est là où ça peut faire mal. Vu que ETCD stocke vraiment toutes les données du cluster Kubernetes, s’il explose, le cluster est perdu. C’est pour ça qu’il est primordial d’effectuer des sauvegardes et de le mettre en « mode cluster » afin d’avoir de la haute disponibilité.

ETCD en cluster : deux possibilités

Cluster ETCD « stacked »

Dans ce cas de figure, le cluster ETCD est « stacked ». C’est à dire que les nœuds sont répartis sur les masters Kubernetes, avec un nœud par master.

Cluster ETCD externe

Et ici, le cluster est externe. Il est donc géré indépendamment des masters Kubernetes.

Je n’ai pas vraiment d’avis sur l’une ou l’autre solution. Si certains ont des retours mettez ça en commentaire ! 🙂

Merci à OpenStack pour les schémas que je trouve juste super simple et compréhensible.

Conclusion

On a finit la revue rapide d’ETCD. Il faut donc retenir que c’est l’élément le plus important d’un cluster Kubernetes (avec le Control Plane évidemment) et que sans lui le cluster est perdu.

Il est donc important de prendre soin à bien l’installer et à bien le paramétrer. Le mettre en cluster pour de la haute disponibilité est aussi un pré-requis pour la production.