Administration Kubernetes : tout comprendre au composant central etcd
La base etcd est accessible à chaque nœud d’un cluster Kubernetes. Découvrez le fonctionnement d’etcd et apprenez à l’utiliser dans Kubernetes.
L’un des composants essentiels de Kubernetes est etcd, une base clé-valeur (« key-value store ») dont la tâche principale est de stocker les informations de fonctionnement du cluster. Si vous travaillez avec Kubernetes, il est important de comprendre comment fonctionne etcd et comment l’utiliser au sein d’un cluster.
La base clé-valeur Open source etcd (prononcer « ett-see-dee ») stocke des données dans diverses situations. Un key-value store est un type de base de données non relationnelle. Plutôt que d’utiliser la structure complexe des tables et des lignes d’une base de données conventionnelle, les bases clé-valeur contiennent une variété de clés et chacune d’entre elles a une valeur assignée.
La base etcd est efficace, fiable et rapide. Elle fonctionne bien dans les environnements distribués où l’instance d’une telle base fonctionne sur un serveur différent de celui des applications et des services, ceux-ci ayant donc leurs données de configuration stockées dans la base clé-valeur.
Origine du nom etcd
Etcd est ainsi nommé parce qu’il remplit une fonction similaire au répertoire /etc des systèmes Linux. Sous Linux, la plupart des fichiers de configuration, y compris ceux des applications installées, résident dans divers sous-répertoires et fichiers contenus dans /etc. De même, sous Kubernetes, les données de configuration du cluster, ainsi que les données qui suivent l’état du cluster, sont stockées dans la base etcd.
La base etcd est essentiellement une version distribuée de /etc. Contrairement au répertoire /etc, qui stocke les données pour un seul serveur, etcd fonctionne dans des environnements distribués – d’où le « d » dans le nom etcd.
Comment fonctionne etcd au sein de Kubernetes ?
Parce qu’il n’a pas été conçu à l’origine pour Kubernetes, etcd a une variété de cas d’utilisation au-delà de ceux impliquant spécifiquement Kubernetes. Cependant, dès le début, Kubernetes a utilisé etcd pour stocker les données de ses clusters, en l’occurrence les informations qui lui sont nécessaires pour gérer les nœuds, les pods et les services.
Il existe deux façons de déployer etcd dans Kubernetes : sur les nœuds de contrôle ou sur des serveurs dédiés.
Stocker etcd sur les nœuds de contrôle est l’approche la plus simple – et celle que la plupart des environnements Kubernetes utilisent par défaut. Elle consiste à exécuter une instance etcd sur chaque nœud de contrôle à l’intérieur d’un cluster.
Bien que cette approche soit facile à mettre en place, elle n’est pas très fiable. Si un nœud de contrôle tombe en panne, etcd cessera de fonctionner. Dans le pire des cas, une corruption du système de fichiers ou une défaillance matérielle sur le nœud de contrôle peut détruire définitivement les données etcd.
La deuxième approche consiste à exécuter des instances etcd, sur d’autres serveurs qui sont considérés comme faisant partie du cluster Kubernetes. La première étape est d’installer etcd sur ce ou ces serveurs, en récupérant l’archive de la dernière version depuis la page de téléchargement officielle ou sous la forme d’un paquet pour la distribution Linux utilisée sur ce ou ces serveurs.
Notez que, sur chacun de ces serveurs, le fichier de configuration d’etcd est /etc/etcd/etcd.conf. Il est notamment important de savoir que le port qu’utilise chaque etcd pour communiquer avec ses pairs est 2380, tandis que le port utilisé pour communiquer avec le reste du cluster Kubernetes est 2379. Par ailleurs, ces serveurs etcd ont chacun une adresse IP, mais il est possible de leur donner un nom en changeant la valeur de la ligne ETCD_NAME = dans leur fichier de configuration.
On active etcd sur chacun de ces serveurs en tapant la commande :
etcd --listen-client-urls=http://$PRIVATE_IP:2379 \ --advertise-client-urls=http://$PRIVATE_IP:2379
Ensuite, sur le serveur de contrôle qui partage les API du clusters Kubernetes, il faut démarrer le serveur d’API avec l’option suivante, soit en la précisant sur la ligne de commande, soit en l’ajoutant dans le fichier /etc/kubernetes/apiserver qui sert à configurer le serveur d’API, à la ligne qui commence par KUBE_ETCD_SERVERS= (remplacez $PRIVATE-IP par l’adresse IP du serveur etcd) :
--etcd-servers=$PRIVATE_IP:2379
Précisons que cet exemple n’est utile qu’à des fins de test, car l’utilisation d’une base etcd depuis un seul serveur présente les mêmes risques de fiabilité que l’exécution d’etcd directement sur les nœuds de contrôle.
Pour une plus grande disponibilité, il convient d’installer etcd sur plusieurs serveurs et configurer la ligne du /etc/kubernetes/apiserver sur le serveur d’API Kubernetes par une ligne de la sorte (indiquez les adresses IP correspondantes aux serveurs etcd) :
--etcd-servers=$IP1:2379,$IP2:2379,$IP3:2379,$IP4:2379,$IP5:2379
Les serveurs etcd devraient dès lors s’afficher dans la liste des pods présents dans le cluster, liste que l’on obtient, depuis la machine d’administration, avec la commande kubectl get pods -A.
Pour les scénarios de déploiement de clusters etcd plus complexes, envisagez d’utiliser un opérateur Kubernetes tel que Etcd Cluster Operator. Les opérateurs simplifient le processus de déploiement et permettent des configurations de cluster etcd personnalisées qui ne nécessitent pas d’ajuster les arguments de la ligne de commande.
Il est à noter qu’etcd installe une commande, etcdctl, qui offre diverses fonctions. Notamment la sauvegarde de la base etcd sous forme de snapshot. En l’occurrence, il y a trois composants à sauvegarder aussi dans le snapshot, ce qui se fait à l’aide de la commande suivante :
etcdctl snapshot save snapshot_location.db --cert /etc/kubernetes/pki/etcd/server.crt --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key
Pour restaurer ces trois bases, il suffit de taper la commande etcdctl snapshot restore snapshot_location.db.
Il est par ailleurs possible d’installer sur la machine d’administration une commande etcd cliente, par exemple en tapant apt install etcd-client si cette machine est sous Linux. Pour piloter à distance les serveurs etcd, il suffit dès lors d’ajouter à la commande l’option --endpoints http://hostname:2379, en remplaçant hostname par le nom ou l’adresse IP de ce serveur.
