Rendre un cluster Kubernetes hautement disponible
L’API server est la porte d’entrée du control plane : toutes les requêtes provenant d’élements extérieurs passent par cet API server. Il est donc nécessaire d’une part de pouvoir mettre à l’échelle cet API server en fonction du nombre de requêtes, et d’autre part de sécuriser cet élément essentiel en cas de panne en déployant plusieurs instances.
D’autre part, etcd est l’élément du control plane qui stocke les données. Il est nécessaire de sécuriser cet élément en cas de panne, en mettant en place un cluster etcd à plusieurs noeuds.
Installation d’un cluster etcd à plusieurs noeuds
Il vous faudra un nombre impair de machines (physiques ou virtuelles), supérieur ou égal à 3, sur lesquelles tournent un système Linux ayant un système de conteneurisation pré-installé, par exemple Docker.
Tous les noeuds du cluster etcd doivent avoir une connectivité réseau entre eux. Selon que vous déployiez vos noeuds dans un cloud public ou dans votre réseau local, il est possible que vous ayez des réglages à faire pour réaliser cette connectivité réseau. Aucune interface réseau publique n’est nécessaire pour ces machines, et vous utiliserez leurs adresses IP sur le réseau local pour les faire communiquer entre elles.
De plus, un agent nommé kubelet devra être préalablement déployé sur chaque noeud du cluster etcd. En effet, etcd sera déployé par kubelet, à partir d’un fichier manifest généré par kubeadm.
Pour déployer et configurer les instances etcd sur ces noeuds afin qu’ils travaillent ensemble, un certain nombre de tâches préalables sont nécessaires :
- utilisation ou création d’une autorité de certificat (la commande
kubeadm init phase certs etcd-capeut être utilisée pour créer une nouvelle autorité de certificat) - création de certificats pour chacun des membres du cluster
etcdet pour l’api server (qui sera client d’etcd), avec la commandekubeadm init phase certs - création d’une configuration
etcdpour que chacun des membres du clusteretcdconnaisse les autres membres du cluster.
Ensuite, il est possible de déployer chaque instance d’etcd sur chaque noeud, avec la commande kubeadm init phase etcd local.
Déploiement du premier noeud du control plane
Il vous faudra une machine (physique ou virtuelle) sur laquelle tourne un système Linux ayant un système de conteneurisation pré-installé, par exemple Docker.
De plus, l’agent kubelet devra être préalablement déployé sur le noeud.
Tous les noeuds du control plane et du cluster etcd précédemment installé doivent avoir une connectivité réseau entre eux. Selon que vous déployiez vos noeuds dans un cloud public ou dans votre réseau local, il est possible que vous ayez des réglages à faire pour réaliser cette connectivité réseau.
La commande kubeadm init permet de déployer une instance de contrôleur d’un control plane hautement disponible. Par défaut, kubeadm déploie une instance etcd locale. Dans ce cas, nous voulons utiliser un cluster etcd externe, nous devons donc créer une configuration kubeadm pour indiquer la liste des instances etcd externes.
De plus, pour que le traffic réseau soit réparti sur les différentes instances du control plane, nous devons mettre en place un équilibreur de charge devant ces instances du control plane, et indiquer à kubeadm que l’adresse d’entrée du control plane est l’adresse de l’équilibreur de charge, et non l’adresse de l’instance comme cela le serait par défaut.
Enfin, les certificats créés lors de l’installation du cluster etcd à destination de l’api server doivent être fournis à kubeadm.
La commande kubeadm init est alors utilisée pour déployer la première instance du control plane. En sortie, la commande kubeadm init vous indiquera:
- la commande à exécuter pour déployer de nouvelles instances du control plane sur d’autres machines, sour la forme
kubeadm join --control-plane. - la commande à exécuter pour déployer des workers sur d’autres machines, sour la forme
kubeadm join.
Add-on réseau
Pour être complètement opérationnel, le cluster Kubernetes a besoin d’un add-on de réseau, qui permettra aux Pods de communiquer entre eux. Aucun add-on réseau n’est installé par défaut avec les autres composants du control plane car le choix de l’add-on est laissé à l’administrateur : plusieurs add-ons réseau existent et chacun a ses spécificités. Pour débuter, vous pourrez choisir l’add-on Calico.
Ajout d’instances du control plane
Pour chaque instance supplémentaire du control plane, il vous faudra une machine (physique ou virtuelle) sur laquelle tourne un système Linux ayant un système de conteneurisation pré-installé, par exemple Docker.
De plus, l’agent kubelet devra être préalablement déployé sur l’instance.
La commande kubeadm join --control-plane donnée lors de l’installation de la première instance du control plane, exécutée depuis une nouvelle machine, est utilisée pour déployer une instance supplémentaire.
Ajout de workers
Pour chaque worker, il vous faudra une machine (physique ou virtuelle) sur laquelle tourne un système Linux ayant un système de conteneurisation pré-installé, par exemple Docker.
De plus, l’agent kubelet devra être préalablement déployé sur le worker.
Une fois le control plane installé, il est possible de rajouter des noeuds workers au cluster. Pour cela, la commande kubeadm join donnée lors de l’installation de la première instance du control plane, exécutée depuis une nouvelle machine, permet de déclarer ce worker auprès du control plane.