Page d'accueil du site de LOG
Menu de navigation

Préparation à la CKA - 01 - Installation d'un cluster

Publié le 23/06/2023 par Ali Sanhaji

Avant-propos

Bonjour à tous les curieux de Kubernetes,

Cet article est le premier d’une longue série qui aura pour but d’apprendre et de comprendre comment fonctionne Kubernetes, et qui permet de préparer la CKA.

La certification CKA (Certified Kubernetes Administrator) teste la capacité des administrateurs à :

  • Installer et configurer un cluster Kubernetes :

    • Comprendre les différentes architectures de cluster.
    • Installer Kubernetes sur des machines physiques ou virtuelles.

  • Gérer les applications :

    • Déployer, mettre à l’échelle et gérer des applications conteneurisées.
    • Utiliser des objets Kubernetes tels que Pods, Deployments et Services.

  • Surveiller et dépanner :

    • Utiliser des outils de surveillance pour suivre les performances des applications et du cluster.
    • Diagnostiquer et résoudre des problèmes liés aux applications et au cluster.

  • Sécuriser le cluster :

    • Mettre en œuvre des pratiques de sécurité pour protéger le cluster et les applications.
    • Gérer les accès et les autorisations.

  • Maintenir le cluster :

    • Effectuer des mises à jour et des sauvegardes.
    • Gérer les ressources et l’intégrité du cluster.

Ce guide est basé sur mon repo de préparation de la CKA que vous pouvez trouver ici : https://github.com/alijahnas/CKA-practice-exercises/

Pendant l’examen de la CKA, vous aurez uniquement accès à la documentation officielle de Kubernetes, disponible à l’adresse suivante : https://kubernetes.io/docs/

Une compétence essentielle est de savoir chercher efficacement dans la documentation officielle, car la plupart des réponses s’y trouvent. L’objectif n’est pas de tout retenir par cœur, mais de savoir où et comment chercher.

Installation d’un cluster

Nous allons parcourir ensemble toutes les étapes d’installation d’un cluster Kubernetes, en comprenant à chaque fois ce que nous faisons et le rôle des composants que nous mettons en place. À la fin, vous aurez un cluster fonctionnel qui servira de base pour suivre le guide de préparation à la CKA. L’objectif est non seulement de réussir la certification, mais aussi d’être réellement à l’aise avec Kubernetes. Il y a du travail, alors c’est parti !

Si vous n’avez pas de machines virtuelles dans le cloud, vous pouvez créer des VMs localement sur une machine Linux disposant de suffisamment de CPU et de RAM. Pour cela, voici un guide utilisant Terraform avec le provisioner libvirt :
https://github.com/alijahnas/CKA-practice-exercises/blob/CKA-v1.23/cluster-architecture-installation-configuration.md#provision-underlying-infrastructure-to-deploy-a-kubernetes-cluster

Et voici le script Terraform à déployer :
https://github.com/alijahnas/CKA-practice-exercises/blob/CKA-v1.23/terraform/cluster-infra.tf

Pour cette installation, nous utiliserons des systèmes Ubuntu 20.04 afin de mettre en place Kubernetes v1.23. Le cluster se composera de trois machines virtuelles :

  • une VM jouera le rôle de Control Plane (on n’utilise plus le terme Master),
  • deux autres seront des Nodes (anciennement appelés Workers, et surtout pas Slaves).

1. Configuration requise

  • Système : Linux avec support de la virtualisation (Intel VT-x ou AMD-V)
  • CPU : 4 cœurs minimum
  • RAM : 12 Go recommandés
  • Espace disque : 50 Go libres minimum

Vérifiez le support de la virtualisation :

egrep -c '(vmx|svm)' /proc/cpuinfo

Note : Il est possible d’installer Kubernetes complètement à la main, comme dans le célèbre guide de Kelsey Hightower :
https://github.com/kelseyhightower/kubernetes-the-hard-way/

Installer Kubernetes “from scratch” (à partir des binaires) permet de comprendre en profondeur le fonctionnement de l’orchestrateur. Cependant, cette méthode demande beaucoup d’efforts et comporte davantage de risques d’erreurs.
La CKA n’exige pas de savoir installer Kubernetes de cette manière.

Nous allons donc utiliser kubeadm, l’outil communautaire recommandé pour créer et configurer un cluster Kubernetes :
https://kubernetes.io/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

Petite précision : k8s = Kubernetes, car il y a 8 lettres entre le k et le s dans le mot Kubernetes.

Container runtime

Avant d’utiliser kubeadm, il faut installer un container runtime. Voici la procédure pour Ubuntu :
https://github.com/alijahnas/CKA-practice-exercises/blob/CKA-v1.23/cluster-architecture-installation-configuration.md#install-container-runtime

Documentation officielle :
https://kubernetes.io/docs/setup/production-environment/container-runtimes/

Nous allons commencer par installer sur nos trois VMs les modules nécessaires, configurer les paramètres système, puis installer les outils permettant d’utiliser le container runtime.

Configuration préalable

# containerd preinstall configuration
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# Setup required sysctl params, these persist across reboots.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system


# Install containerd
## Set up the repository
### Install packages to allow apt to use a repository over HTTPS
sudo apt-get update
sudo apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

## Add Docker’s official GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

## Add Docker apt repository.
echo \
  "deb \[arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Nous pouvons enfin installer containerd :

## Install packages
sudo apt-get update
sudo apt-get install -y \
  containerd.io

# Configure containerd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# Restart containerd
sudo systemctl restart containerd

Mais au fait, c’est quoi containerd ? Et c’est quoi un container runtime ?

Un container runtime est le composant chargé d’exécuter et de gérer les containers sur les nœuds du cluster. Kubernetes, en tant qu’orchestrateur, décide quoi exécuter, mais c’est le runtime qui lance réellement les containers.

Beaucoup de personnes ont découvert les containers grâce à Docker, qui a popularisé leur usage dans les architectures microservices. Docker repose aujourd’hui sur plusieurs composants indépendants, notamment containerd et runc :

  • runc : container runtime bas niveau.
    C’est un binaire qui exécute directement les containers sur les nœuds.

  • containerd : container runtime haut niveau.
    C’est un daemon (le “d” signifie daemon) qui expose des APIs pour gérer les containers. Kubernetes interagit avec containerd, qui à son tour utilise runc pour exécuter les containers.

Kubernetes supporte aujourd’hui plusieurs runtimes conformes à CRI (Container Runtime Interface), comme containerd, CRI-O ou encore Mirantis Container Runtime.

Kubeadm, Control plane

Maintenant que containerd (avec runc comme dépendance) est installé sur nos machines, nous pouvons procéder à l’installation du cluster Kubernetes sur nos nœuds en utilisant kubeadm.

Nous allons d’abord installer les outils nécessaires sur nos trois VMs :

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

echo "deb \[signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet=1.23.9-00 kubeadm=1.23.9-00 kubectl=1.23.9-00
sudo apt-mark hold kubelet kubeadm kubectl

Nous avons ainsi installé trois composants essentiels :

  • kubeadm : outil utilisé pour initialiser et configurer le cluster Kubernetes. Il automatise la création du Control Plane et la jonction des nœuds

  • kubelet : agent qui s’exécute sur chaque nœud du cluster et communique avec le container runtime (containerd). Il applique les spécifications des Pods et gère leur cycle de vie.

  • kubectl : CLI permettant d’interagir avec l’API server de Kubernetes. Il s’exécute depuis le poste de l’utilisateur ou depuis un nœud pour gérer et administrer le cluster.

Initialisation du Control Plane avec kubeadm

Nous allons maintenant installer notre cluster Kubernetes à l’aide de kubeadm.
La première étape consiste à initialiser le Control Plane.
Assurez-vous que chaque VM possède un hostname distinct, condition indispensable au déploiement.

Sur la machine dédiée au Control Plane, exécutez :

sudo kubeadm init --kubernetes-version=1.23.9 --pod-network-cidr=10.244.0.0/16

Composants du Control Plane installés par kubeadm init

La commande kubeadm init initialise le cluster en déployant les composants essentiels du Control Plane :

  • kube-apiserver : point d’entrée principal du cluster.
    Il reçoit et traite toutes les requêtes API avant de déléguer aux autres composants.

  • etcd : base de données distribuée clé/valeur dans laquelle Kubernetes stocke l’intégralité de l’état du cluster.
    Un backup régulier est indispensable pour garantir la résilience.

  • kube-scheduler : responsable de déterminer sur quel Node seront déployés les Pods en fonction des ressources, contraintes et affinités.

  • kube-controller-manager : exécute les différents contrôleurs Kubernetes (endpoints, service accounts, nodes, replication, etc.).
    Il surveille l’état désiré et applique les ajustements nécessaires sur les objets du cluster.

Ajout des Nodes au cluster

Après l’exécution de kubeadm init, une commande de jonction (kubeadm join) est affichée.
Elle contient un token d’authentification et l’empreinte du certificat CA, permettant aux autres machines de rejoindre le cluster via l’API Server (port 6443).

Exécutez cette commande sur les deux autres VMs :

sudo kubeadm join 172.16.1.11:6443 --token h8vno9.7eroqaei7v1isdpn \
\--discovery-token-ca-cert-hash sha256:44f1def2a041f116bc024f7e57cdc0cdcc8d8f36f0b942bdd27c7f864f645407

Cette opération enregistre les VMs comme Nodes du cluster, prêts à exécuter des Pods.

Configuration de kubectl

Pour gérer le cluster depuis le Control Plane, il faut récupérer le fichier de configuration généré par kubeadm :

# Configure kubectl access
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Cela permet à kubectl d’interagir avec l’API Server en utilisant les certificats et le contexte du cluster.

Dernière étape avant la vérification : installer un plugin CNI

Avant toute vérification avec kubectl, il reste une étape essentielle : installer un plugin CNI (Container Network Interface), indispensable pour activer la communication réseau entre Pods et Nodes au sein du cluster Kubernetes.

Plugin CNI

Kubernetes est un orchestrateur modulaire qui gère principalement le déploiement des containers et leur cycle de vie, mais pas le réseau entre ces containers.
Or, une fois répartis sur les différents nœuds du cluster, les Pods doivent pouvoir communiquer entre eux.
C’est le rôle des plugins CNI (Container Network Interface) : fournir la couche réseau permettant l’interconnexion des workloads.

Choix du plugin CNI

Il existe plusieurs approches pour organiser le réseau dans Kubernetes.
Dans notre cas, nous choisissons Flannel, un plugin CNI simple à déployer, qui met en place un réseau overlay au-dessus du réseau des nœuds pour assurer la communication entre les Pods.

Voici quelques alternatives au sein de l’écosystème :

  • Calico : utilise BGP pour distribuer les routes entre les nœuds. Très utilisé en production pour sa gestion avancée des politiques réseau (Network Policies).
  • Cilium : basé sur eBPF, permet une observation, une sécurité et des performances réseau avancées.
  • Azure CNI / AWS VPC CNI / GKE CNI : CNI natifs utilisés dans les environnements cloud, permettant une intégration directe avec les réseaux des fournisseurs sans couche overlay.

Flannel s’appuiera sur la plage d’adresses Pods configurée dans la commande kubeadm init : —pod-network-cidr=10.244.0.0/16

# Deploy Flannel as a network plugin
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Vérification de l’état du cluster

Une fois Flannel déployé, vous pouvez vérifier si tous les nœuds sont opérationnels :

kubectl get nodes
NAME               STATUS   ROLES                  AGE     VERSION
k8s-controlplane   Ready    control-plane,master   4m51s   v1.23.9
k8s-node-1         Ready    <none>                 4m9s    v1.23.9
k8s-node-2         Ready    <none>                 4m8s    v1.23.9

Tous les nœuds doivent apparaître en Ready, indiquant que le cluster est fonctionnel et prêt à exécuter des workloads

Enfin ! Maintenant que le cluster est déployé, nous pouvons continuer notre guide de préparation de la CKA. Dans les prochains articles, nous allons voir comment fonctionnent tous les objets Kubernetes de base (pods, services, volumes, secrets).

Voir tous les articles

Derniers articles