🤖 Control plane#
Nos serveurs IPS et noms, juste pour référence :
192.168.1.21 control00 control00.local
192.168.1.42 cube00 cube00.local
192.168.1.43 cube01 cube01.local
192.168.1.44 cube02 cube02.local
🧠 Maître / Contrôle#
Dans notre cas : control00
Il s’agit de notre nœud principal.
Nous allons installer la version K3s de Kubernetes, qui est suffisamment légère pour être gérée par nos ordinateurs monocartes. Utilisez la commande suivante pour télécharger et initialiser le nœud maître de K3s.
curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644 --disable servicelb --token some_random_password --node-taint CriticalAddonsOnly=true:NoExecute --bind-address 192.168.1.21 --disable-cloud-controller --disable local-storage
Quelques explications :
–write-kubeconfig-mode 644 - Il s’agit du mode que nous souhaitons utiliser pour le fichier kubeconfig. Il est facultatif, mais nécessaire si vous souhaitez vous connecter ultérieurement à Rancher Manager.
–disable servicelb - Il s’agit de l’indicateur que nous souhaitons utiliser pour désactiver l’équilibreur de charge du service. (Nous utiliserons metallb à la place)
–token - Il s’agit du jeton que nous souhaitons utiliser pour nous connecter au nœud maître K3s. Choisissez un mot de passe aléatoire, mais n’oubliez pas de le mémoriser.
–node-taint - Il s’agit de l’indicateur que nous souhaitons utiliser pour ajouter une souillure au nœud maître K3s. J’expliquerai les souillures plus tard, mais cela marquera le nœud pour qu’il n’exécute aucun conteneur à l’exception de ceux qui sont critiques.
–bind-address - Il s’agit de l’indicateur que nous souhaitons utiliser pour lier le nœud maître K3s à une adresse IP spécifique.
–disable-cloud-controller - Il s’agit de l’indicateur que nous souhaitons utiliser pour désactiver le contrôleur cloud K3s. Je ne pense pas en avoir besoin.
–disable local-storage - Il s’agit de l’indicateur que nous souhaitons utiliser pour désactiver le stockage local de K3s. Je vais plutôt configurer le fournisseur de stockage Longhorn.
Nous pouvons examiner les nœuds Kubernetes en utilisant la commande suivante :
root@control00:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
control00 Ready control-plane,master 23s v1.23.6+k3s1
👨🏻🔧 Ouvriers / Workers#
Nous devons maintenant joindre nos workers ; dans notre cas, cube00 à 01. De plus, nous allons exécuter la commande join sur chaque nœud avec Ansible.
ansible workers -b -m shell -a "curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.21:6443 K3S_TOKEN=some_random_password sh -"
Attendez maintenant quelques instants pour qu’il rejoigne le cluster. Vous pouvez suivre la progression en utilisant la commande suivante :
watch kubectl get nodes
Au final, cela devrait ressembler à ceci :
root@control00:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
cube00 Ready <none> 71s v1.23.6+k3s1
cube01 Ready <none> 72s v1.23.6+k3s1
control00 Ready control-plane,master 3m45s v1.23.6+k3s1
L’ordre affiché n’a pas d’importance.
🏷️ Définition du rôle/des étiquettes#
Nous pouvons attribuer des étiquettes tag
à nos nœuds de cluster.
Ajoutons cette balise clé:valeur: kubernetes.io/role=worker
aux nœuds de travail. C’est plus esthétique, pour avoir un bon résultat de kubectl get nodes
.
kubectl label nodes cube00 kubernetes.io/role=worker
kubectl label nodes cube01 kubernetes.io/role=worker
Une autre étiquette/balise. Je vais l’utiliser pour indiquer aux déploiements de préférer les nœuds où node-type
equals workers
. Le type de nœud est le nom que nous avons choisi pour la clé, vous pouvez l’appeler comme vous le souhaitez.
kubectl label nodes cube00 node-type=worker
kubectl label nodes cube01 node-type=worker
Cluster Kubernetes complet :
root@control01:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
cube00 Ready worker 15d v1.23.6+k3s1
cube01 Ready worker 15d v1.23.6+k3s1
control00 Ready control-plane,master 15d v1.23.6+k3s1
Vous pouvez également l’utiliser kubectl get nodes --show-labels
pour afficher toutes les étiquettes des nœuds.
Et pour les taints, nous pouvons utiliser ce qui suit pour afficher toutes les taints des nœuds :
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --no-headers
Exemple:
root@control00:~# kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --no-headers
cube00 <none>
cube01 <none>
control00 [map[effect:NoExecute key:CriticalAddonsOnly value:true]]
Enfin, ajoutez ce qui suit /etc/environment
(cela permet à Helm et aux autres programmes de savoir où se trouve la configuration Kubernetes).
Sur chaque nœud :
echo "KUBECONFIG=/etc/rancher/k3s/k3s.yaml" >> /etc/environment
Ou utilisez Ansible :
ansible cube -b -m lineinfile -a "path='/etc/environment' line='KUBECONFIG=/etc/rancher/k3s/k3s.yaml'"
✅ Done !#
Par exemple, Ansible peut tout déployer (ce qui pourrait ne pas se terminer comme le mien) ; pour vous inspirer, consultez le dépôt git : https://github.com/k3s-io/k3s-ansible
Une autre solution pourrait être de faire GitOps et de créer l’infrastructure sous forme de code en utilisant Flux 2 (ou une alternative). Je pourrais faire un article séparé sur la façon de mettre cela en place, mais vous pouvez regarder ici en attendant : https://github.com/k8s-at-home/ pour plus d’inspiration"