Architecture, installation et configuration d’un cluster Kubernetes
Un cluster Kubernetes est constitué d’un ou plusieurs noeuds master, et de workers. Les noeuds master fournissent le control plane du cluster Kubernetes, et les workers permettent d’exécuter vos workloads.
Pré-requis
L’outil à maîtriser lors de la certification pour installer un cluster Kubernetes de production est l’outil kubeadm. Pour installer un noeud du cluster (master ou worker), vous aurez besoin d’une machine (physique ou virtuelle) sur laquelle tourne un système Linux ayant un système de conteneurisation pré-installé, par exemple Docker.
Tous les noeuds de votre cluster 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.
De plus, un agent nommé kubelet devra être préalablement déployé sur chaque noeud, aussi bien masters que workers.
Architecture et initialisation du master
La première étape de l’installation est l’exécution de la commande kubeadm init que installera les composants du control plane sur votre noeud master. Les composants installés sont :
- le serveur d’API, qui est le point d’entrée dans le cluster pour les outils extérieurs, et le moyen de comunication entre les composants du cluster,
- la base de données clé-valeur
etcdstockant toutes les données du cluster, - le scheduler, qui choisira sur quels workers déployer les workloads selon différents critères,
- les contrôleurs, qui adapteront les ressources déployées dans le cluster selon vos spécifications.
L’agent kubelet enregistre le noeud sur lequel il est déployé auprès du serveur d’API. Sa principale tâche est ensuite de déployer des Pods (un ensemble de conteneurs) à la demande. Les demandes proviennent principalement du serveur d’API, mais peuvent aussi provenir de fichiers contenus dans un répertoire spécifique du noeud.
Grâce à cette dernière technique, les composants du control plane (serveur d’API, etcd, scheduler et contrôleurs) sont déployés par kubelet lui-même. kubeadm a uniquement eu à créer des fichiers dans un répertoire spécifique contenant les spécifications des Pods à déployer pour ces services.
Enfin, un dernier service kube-proxy est déployé sur chaque noeud, aussi bien masters que workers. Il s’agit d’un proxy réseau qui maintient des règles permettant de router le trafic réseau vers les Pods déployés par kubelet. Ce service est aussi déployé en temps que Pod, comme les autres services du control plane.
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 de workers
Une fois le control plane installé, il est possible de rajouter des noeuds workers au cluster. Pour cela, la commande kubeadm join exécuté depuis un worker permet de déclarer ce worker auprès du control plane.