RKE2 : déployer un cluster Kubernetes sécurisé sur KVM

RKE2 (Rancher Kubernetes Engine 2) est la distribution Kubernetes orientée sécurité de Rancher/SUSE, conçue pour faciliter la conformité aux benchmarks CIS. Ce guide vous accompagne dans le déploiement d'un cluster RKE2 reproductible sur KVM, prêt à être renforcé pour la production.

Prérequis : Une machine Linux avec KVM/libvirt, accès SSH avec clé, et kubectl installé sur votre poste.

Ce guide a été validé sur RKE2 v1.36.4+rke2r1 et Ubuntu 24.04.5 : c'est la version dont proviennent les sorties publiées plus bas. RKE2 avance vite, et une version plus récente peut changer un chemin ou un nom de composant packagé ; la page des releases fait foi au moment où vous installez.

Ce que vous allez apprendre

• Créer des VMs KVM avec cloud-init pour héberger le cluster
• Installer un nœud server RKE2 (control plane + etcd)
• Joindre des nœuds agent (workers) au cluster
• Récupérer l'accès kubectl et valider le déploiement
• Diagnostiquer les problèmes courants et nettoyer le lab

Pourquoi choisir RKE2 ?

RKE2 se distingue par son orientation sécurité par défaut et ses options facilitant la conformité aux benchmarks CIS Kubernetes.

Caractéristique	RKE2
Orienté sécurité	Profils et options CIS, SELinux/AppArmor
Distribution packagée	Composants intégrés, pas d'assemblage
Configuration centralisée	Un fichier /etc/rancher/rke2/config.yaml
Intégration Rancher	Compatible avec Rancher Manager
Support enterprise	SUSE/Rancher support commercial
CNI par défaut	Canal (Flannel + Calico policies)
Containerd	Runtime CRI intégré et hardené

Glissez pour voir

Cinq besoins désignent RKE2 plutôt qu'une autre distribution, et ils se recoupent tous autour de la même idée, la conformité. Vouloir un cluster durci par défaut plutôt qu'à construire. Préférer une distribution packagée à un assemblage de composants qu'il faudra maintenir. Utiliser déjà Rancher Manager, avec lequel l'intégration est native. Avoir besoin d'un support commercial, celui de SUSE. Et devoir démontrer un alignement sur les benchmarks CIS, ce que RKE2 rend vérifiable au lieu de le laisser à votre charge.

RKE2 vs autres solutions

Avant de démarrer, comparez RKE2 avec les autres options :

Critère	RKE2	kubeadm	k0s	k3s	Kubespray
Type	Distribution	Bootstrap tool	Distribution	Distribution	Playbooks Ansible
Orientation	Enterprise, sécurité	Standard upstream	Edge, prod, CI	Edge, IoT, dev	Prod, multi-cloud
Installation	Script	Commandes	k0sctl (YAML)	Script unique	Ansible
CNI défaut	Canal	Aucun	kube-router	Flannel	Configurable
HA native	✅ Intégrée	Manuel	✅ Multi-controller	✅ Multi-server	✅ Ansible
Profil CIS	✅ Intégré	Manuel	Manuel	Manuel	Selon config
Cas d'usage	Conformité, prod	Bare metal, formation	Edge, CI/CD, prod	Edge, IoT, dev	Prod automatisée

Glissez pour voir

RKE2 est nettement plus gourmand que k0s ou k3s : c'est le prix du packaging complet. Les valeurs utilisées dans ce lab sont 4 Go de RAM et 2 vCPU pour le server, 3 Go et 2 vCPU pour l'agent. Ce sont des minima de lab, pas des recommandations de production : la consommation réelle dépend de vos charges et des composants que vous laissez activés.

Le contrôleur Ingress packagé a changé

Le projet communautaire ingress-nginx est archivé en lecture seule depuis le 24 mars 2026 : plus aucune release, plus aucun correctif de faille. RKE2 packageait historiquement rke2-ingress-nginx.

C'est désormais Traefik, et cela se constate. Vérifié sur le lab de ce guide, un cluster v1.36.4+rke2r1 ne contient plus aucune trace d'ingress-nginx :

kubectl get pods -n kube-system | grep -iE 'ingress|traefik'

Sortie sur RKE2 v1.36.4+rke2r1

helm-install-rke2-traefik-crd-q2mjz   0/1   Completed   0   2m6s
helm-install-rke2-traefik-tpw55       0/1   Completed   2   2m6s
rke2-traefik-g22nw                    1/1   Running     0   68s
rke2-traefik-hr2s6                    1/1   Running     0   68s
rke2-traefik-hszw2                    1/1   Running     0   53s

Trois Pods rke2-traefik, un par nœud : le contrôleur reste déployé en DaemonSet, comme l'était ingress-nginx. Seule l'implémentation change.

Si vous exploitez un cluster RKE2 plus ancien, la chart rke2-ingress-nginx qu'il porte encore ne reçoit plus aucune mise à jour. Planifiez la bascule plutôt que de la subir : les composants packagés d'une distribution changent au fil des versions, et c'est la note de release de votre version exacte qui dit ce que vous obtiendrez.

Architecture du lab

Ce lab déploie un cluster RKE2 minimaliste mais fonctionnel :

Ports réseau requis

Un cluster RKE2 ne démarre pas si ces flux sont bloqués, et le symptôme est trompeur : le service se lance normalement, mais les agents n'apparaissent jamais dans kubectl get nodes. Retenez surtout le 9345, propre à RKE2 et souvent oublié dans les règles de pare-feu, et le 8472 en UDP qu'utilise le réseau overlay Canal entre les nœuds.

Port	Protocole	Source → Destination	Rôle
6443	TCP	Agents, kubectl → Server	API Kubernetes
9345	TCP	Agents → Server	Registration RKE2
10250	TCP	Server → Agents	kubelet API
8472	UDP	Tous nœuds ↔ Tous nœuds	VXLAN (Canal)

Glissez pour voir

Les ports du tableau suffisent à ce lab à un seul server. Trois familles s'y ajoutent dès que la configuration se complique : 2379 à 2381 entre servers pour etcd en haute disponibilité, 30000 à 32767 si vous exposez des NodePort, et 9099 ainsi que 51820-51821 selon la configuration du CNI Canal. La documentation des prérequis en donne la liste exacte, qui évolue d'une version à l'autre.

Prérequis

Vérifiez ces points avant de commencer : un manque à ce stade se manifeste bien plus tard, sous la forme d'une erreur qui ne le désigne pas.

Sur l'hyperviseur (votre machine)

Trois éléments sont nécessaires côté hôte : la pile KVM/libvirt pour créer les machines virtuelles, l'utilitaire cloud-localds (paquet cloud-image-utils) pour fabriquer les images cloud-init, et le client kubectl pour piloter le cluster une fois debout. Le binaire kubectl se vérifie avec la somme de contrôle publiée à côté de lui, ne l'installez jamais sans ce contrôle.

# Paquets KVM/libvirt
sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients virtinst cloud-image-utils

# Vérifier que libvirtd est actif
sudo systemctl status libvirtd

# Télécharger kubectl et sa somme de contrôle officielle
KUBECTL_VERSION="$(curl -Ls https://dl.k8s.io/release/stable.txt)"
curl -LO "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl.sha256"

# Vérifier l'empreinte avant installation (doit afficher "kubectl: OK")
echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check -

chmod +x kubectl && sudo mv kubectl /usr/local/bin/

NetworkManager sur les nœuds

Si vos VMs utilisent NetworkManager, configurez-le pour ignorer les interfaces CNI avant d'installer RKE2. Sinon, vous risquez des problèmes réseau après redémarrage :

cat << 'EOF' | sudo tee /etc/NetworkManager/conf.d/rke2-canal.conf
[keyfile]
unmanaged-devices=interface-name:cali*;interface-name:flannel*;interface-name:vxlan*
EOF
sudo systemctl restart NetworkManager

Ce lab utilise des images cloud Ubuntu qui n'ont pas NetworkManager par défaut.

Image cloud Ubuntu

Les images cloud sont des disques préinstallés, déjà équipés de cloud-init, qui évitent toute installation manuelle du système. Canonical publie un fichier SHA256SUMS dans le même répertoire : vérifiez l'empreinte avant de fabriquer les disques des trois VMs, sinon vous propagerez une image corrompue sur tout le cluster.

# Télécharger l'image cloud Ubuntu 24.04 et les sommes de contrôle
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
wget https://cloud-images.ubuntu.com/noble/current/SHA256SUMS

# Vérifier l'empreinte (doit afficher "OK" pour l'image téléchargée)
sha256sum --ignore-missing --check SHA256SUMS

# Renommer une fois la vérification réussie
mv noble-server-cloudimg-amd64.img ubuntu-24.04-cloudimg.img

Création des VMs KVM

Les trois machines virtuelles sont créées à partir de la même image cloud, en copie sur écriture : chaque disque QCOW2 ne stocke que ses différences avec l'image de base, ce qui rend la création quasi instantanée. La configuration (nom d'hôte, clé SSH, adresse IP fixe, désactivation du swap) est injectée par cloud-init au premier démarrage, sans aucune intervention manuelle.

1. Créer les disques QCOW2

   # Créer un disque basé sur l'image cloud
   for VM in rke2-cp1 rke2-worker1 rke2-worker2; do
     qemu-img create -f qcow2 -F qcow2 \
       -b ubuntu-24.04-cloudimg.img \
       ${VM}.qcow2 20G
   done

2. Générer la configuration cloud-init

   Créez un fichier cloud-init-cp1.yaml pour le server :

   #cloud-config
   hostname: rke2-cp1
   manage_etc_hosts: true
   
   users:
     - name: kube
       sudo: ALL=(ALL) NOPASSWD:ALL
       shell: /bin/bash
       ssh_authorized_keys:
         - ssh-ed25519 AAAA... votre-clé-publique
   
   # Désactiver le swap (requis pour Kubernetes)
   swap:
     filename: /swap.img
     size: 0
   
   # Configuration réseau statique
   write_files:
     - path: /etc/netplan/50-cloud-init.yaml
       content: |
         network:
           version: 2
           ethernets:
             enp1s0:
               addresses: [192.168.122.10/24]
               routes:
                 - to: default
                   via: 192.168.122.1
               nameservers:
                 addresses: [192.168.122.1]
   
   runcmd:
     - netplan apply
     - swapoff -a
     - sed -i '/swap/d' /etc/fstab

   Deux détails de ce fichier méritent votre attention. Il utilise routes et non gateway4, déprécié dans les versions récentes de Netplan. Et le nom d'interface enp1s0 est celui de ce lab : vérifiez le vôtre avant d'appliquer.

   Deux valeurs sont à remplacer avant d'appliquer ce fichier : la clé publique ssh-ed25519 AAAA..., par la vôtre, sans quoi vous ne pourrez pas vous connecter, et les adresses IP si votre réseau diffère de celui du lab.

3. Créer les ISOs cloud-init

   for VM in rke2-cp1 rke2-worker1 rke2-worker2; do
     cloud-localds ${VM}-cloud-init.iso cloud-init-${VM}.yaml
   done

4. Créer les VMs avec virt-install

   # Server (4 Go RAM)
   virt-install --name rke2-cp1 \
     --memory 4096 --vcpus 2 \
     --disk rke2-cp1.qcow2 \
     --disk rke2-cp1-cloud-init.iso,device=cdrom \
     --os-variant ubuntu24.04 \
     --network network=default \
     --graphics none --console pty,target_type=serial \
     --noautoconsole --import
   
   # Workers (3 Go RAM chacun)
   for WORKER in rke2-worker1 rke2-worker2; do
     virt-install --name ${WORKER} \
       --memory 3072 --vcpus 2 \
       --disk ${WORKER}.qcow2 \
       --disk ${WORKER}-cloud-init.iso,device=cdrom \
       --os-variant ubuntu24.04 \
       --network network=default \
       --graphics none --console pty,target_type=serial \
       --noautoconsole --import
   done

   L'option --network network=default raccorde la VM au réseau NAT virbr0 que libvirt installe par défaut. Si vous avez monté un pont, remplacez-la par --network bridge=br0 ou son équivalent chez vous.

5. Attendre la disponibilité SSH

   for IP in 192.168.122.10 192.168.122.20 192.168.122.21; do
     until ssh -o ConnectTimeout=5 -o StrictHostKeyChecking=no kube@${IP} exit 2>/dev/null; do
       echo "Attente de ${IP}..."
       sleep 5
     done
     echo "${IP} accessible"
   done

Installation du server RKE2

Le nœud server héberge le control plane et etcd, c'est lui qui doit démarrer en premier. L'installation se déroule en deux temps : le script dépose le binaire et les unités systemd, mais ne démarre rien. Vous écrivez ensuite /etc/rancher/rke2/config.yaml, puis vous lancez le service. Cet ordre compte : un service démarré avant l'écriture du fichier de configuration générerait des certificats sans les noms alternatifs (tls-san) attendus.

1. Installer RKE2 sur le server

   ssh kube@192.168.122.10 << 'EOF'
   # Télécharger le script officiel puis l'exécuter (inspectez-le au préalable)
   curl -sfL https://get.rke2.io -o rke2-install.sh
   sudo INSTALL_RKE2_VERSION="v1.36.4+rke2r1" sh rke2-install.sh
   EOF

   Épinglez la version, ne comptez pas sur le canal. Sans INSTALL_RKE2_VERSION, le script demande au serveur de canaux quelle version correspond à « stable ». Ce service est actuellement hors d'usage et l'installation échoue, comme le montre le relevé donné après ces étapes. Épingler est de toute façon la bonne pratique : c'est ce qui rend une installation rejouable à l'identique.

   Les méthodes documentées couvrent aussi l'installation par paquets, mieux adaptée à un parc géré.

2. Configurer le server RKE2

   Créez /etc/rancher/rke2/config.yaml sur le server :

   ssh kube@192.168.122.10 << 'EOF'
   sudo mkdir -p /etc/rancher/rke2
   sudo tee /etc/rancher/rke2/config.yaml << 'CONFIG'
   # Token stable pour les agents (à conserver !)
   token: rke2-lab-token-secure-2026
   
   # Certificats TLS valides pour ces noms/IPs
   tls-san:
     - 192.168.122.10
     - rke2-cp1
     - rke2-cp1.local
   CONFIG
   EOF

   Token important

   Le token défini ici est crucial :

   • Il permet aux agents de rejoindre le cluster
   • Il est utilisé pour chiffrer les données bootstrap
   • Conservez-le pour toute restauration ou ajout de nœuds

   En cluster HA, ce token et d'autres valeurs critiques (cluster-cidr, service-cidr) doivent être identiques sur tous les servers. Consultez la Server Configuration Reference.

3. Démarrer le service rke2-server

   ssh kube@192.168.122.10 << 'EOF'
   sudo systemctl enable rke2-server
   sudo systemctl start rke2-server
   EOF

4. Suivre les logs d'initialisation

   ssh kube@192.168.122.10 "sudo journalctl -u rke2-server -f"

   Attendez le message rke2 is up and running (environ 1-2 minutes).

Le canal stable ne se résout plus, épinglez la version

Voici ce que rend le script sans INSTALL_RKE2_VERSION, relevé sur le lab de ce guide :

[INFO]  finding release for channel stable
[INFO]  using stable as release
[INFO]  downloading checksums at https://github.com/rancher/rke2/releases/download/stable/sha256sum-amd64.txt
curl: (22) The requested URL returned error: 404

Lisez la deuxième ligne, c'est elle qui trahit le problème : using stable as release. Le script n'a pas résolu le canal, il a pris le mot « stable » pour un nom de version, puis a cherché un tag stable qui n'existe pas sur GitHub. La cause est en amont : l'endpoint que l'installeur interroge, https://update.rke2.io/v1-release/channels, répond 404.

Ce n'est pas un problème de réseau chez vous. Le domaine résout correctement, et le même endpoint côté k3s, https://update.k3s.io/v1-release/channels, répond 200 depuis la même machine. Seul le service RKE2 est concerné.

La parade tient en une variable, et elle vaut au-delà de cette panne : une version épinglée se rejoue à l'identique dans six mois, un canal non.

Jonction des agents

Une fois le server opérationnel, installez RKE2 en mode agent sur les workers :

1. Installer RKE2 (mode agent) sur chaque worker

   for WORKER_IP in 192.168.122.20 192.168.122.21; do
     ssh kube@${WORKER_IP} << 'EOF'
   curl -sfL https://get.rke2.io -o rke2-install.sh
   sudo INSTALL_RKE2_TYPE="agent" INSTALL_RKE2_VERSION="v1.36.4+rke2r1" sh rke2-install.sh
   EOF
   done

   La même règle vaut pour les agents : épinglez la même version que le server. Un agent installé depuis le canal, lui, échouerait exactement comme le server.

2. Configurer les agents

   for WORKER_IP in 192.168.122.20 192.168.122.21; do
     ssh kube@${WORKER_IP} << 'EOF'
   sudo mkdir -p /etc/rancher/rke2
   sudo tee /etc/rancher/rke2/config.yaml << 'CONFIG'
   # Adresse du server RKE2
   server: https://192.168.122.10:9345
   
   # Token identique au server
   token: rke2-lab-token-secure-2026
   CONFIG
   EOF
   done

   L'URL du server porte le port 9345, et non 6443 comme on s'y attendrait. Les deux coexistent et ne servent pas à la même chose : 6443 est l'API Kubernetes, 9345 est le port de supervision et d'enregistrement propre à RKE2, celui par lequel un agent demande à rejoindre. Se tromper de port est l'erreur de jointure la plus fréquente.

3. Démarrer les agents

   for WORKER_IP in 192.168.122.20 192.168.122.21; do
     ssh kube@${WORKER_IP} << 'EOF'
   sudo systemctl enable rke2-agent
   sudo systemctl start rke2-agent
   EOF
   done

4. Vérifier le statut des agents

   for WORKER_IP in 192.168.122.20 192.168.122.21; do
     ssh kube@${WORKER_IP} "sudo systemctl status rke2-agent --no-pager | head -5"
   done

Récupération de l'accès kubectl

RKE2 génère un kubeconfig complet dans /etc/rancher/rke2/rke2.yaml, avec les certificats et le compte administrateur du cluster. Ce fichier pointe vers 127.0.0.1 puisqu'il est prévu pour un usage local sur le server : pour l'utiliser depuis votre poste, il faut remplacer cette adresse par l'IP du nœud. Traitez ce fichier comme un secret, il donne un accès complet au cluster.

1. Récupérer le kubeconfig depuis le server

   # Copier le kubeconfig
   ssh kube@192.168.122.10 "sudo cat /etc/rancher/rke2/rke2.yaml" > kubeconfig
   
   # Adapter l'adresse du server
   sed -i 's/127.0.0.1/192.168.122.10/g' kubeconfig

   RKE2 installe bien kubectl, mais dans /var/lib/rancher/rke2/bin/, un chemin absent du PATH par défaut. Sur le server, deux exports suffisent à le rendre utilisable, et gagnent à être ajoutés au profil de l'utilisateur :

   export PATH=$PATH:/var/lib/rancher/rke2/bin
   export KUBECONFIG=/etc/rancher/rke2/rke2.yaml

2. Tester l'accès au cluster

   export KUBECONFIG=$PWD/kubeconfig
   kubectl cluster-info
   kubectl get nodes

   Résultat attendu :

   NAME           STATUS   ROLES                AGE   VERSION
   rke2-cp1       Ready    control-plane,etcd   10m   v1.34.5+rke2r1
   rke2-worker1   Ready    <none>               5m    v1.34.5+rke2r1
   rke2-worker2   Ready    <none>               5m    v1.34.5+rke2r1

Nœuds NotReady ?

Quand un nœud reste en NotReady au-delà de quelques minutes, remontez la chaîne du service vers le réseau, puis vers le CNI : chaque étape suppose que la précédente fonctionne.

1. Lisez les journaux du service : journalctl -u rke2-server ou rke2-agent
2. Vérifiez la connectivité vers le port 9345, celui de la jointure
3. Vérifiez que le CNI Canal est initialisé : kubectl get pods -n kube-system | grep canal

Vérification du cluster

Trois nœuds Ready ne signifient pas que le cluster est utilisable. Il reste à confirmer que les composants système tournent, que le planificateur répartit bien les charges sur les workers, et que la résolution DNS interne fonctionne. Ces trois vérifications prennent deux minutes et évitent des heures de diagnostic sur la première application déployée.

Pods système

Tous les composants de RKE2 tournent dans le namespace kube-system. Les processus du control plane y apparaissent sous forme de static pods, gérés directement par le kubelet à partir de manifestes sur disque, et non par l'API server.

kubectl get pods -n kube-system

Vous devriez retrouver les static pods du control plane et les composants packagés activés :

Catégorie	Pods
Control plane	etcd-*, kube-apiserver-*, kube-controller-manager-*, kube-scheduler-*
CNI	rke2-canal-* (un par nœud)
DNS	rke2-coredns-*
Composants optionnels	rke2-ingress-nginx-*, rke2-metrics-server-* (selon config)

Glissez pour voir

Les composants embarqués, rke2-coredns, rke2-ingress-nginx et rke2-metrics-server, ne sont pas imposés : le paramètre disable du config.yaml permet d'en écarter un pour le remplacer par le vôtre. C'est le geste à connaître si vous préférez votre propre contrôleur d'entrée, et la liste exacte dépend de votre version.

Test de déploiement

Ce déploiement à deux réplicas valide toute la chaîne : téléchargement de l'image par containerd, planification, puis démarrage effectif des conteneurs. L'option -o wide ajoute la colonne NODE, indispensable ici puisque c'est la répartition qui nous intéresse.

# Créer un déploiement nginx
kubectl create deployment nginx --image=nginx:1.30@sha256:d5792f71a9496b833bc08ea834a758c46e2b6a6306c10f4be926f38a656cdc1c --replicas=2

# Vérifier le scheduling
kubectl get pods -o wide

Les pods doivent être répartis sur les workers (rke2-worker1 et rke2-worker2).

Test DNS

Sans DNS interne, aucune application ne peut joindre un Service par son nom, et les symptômes ressemblent à s'y méprendre à un problème réseau. Le Pod de test est éphémère grâce à --rm : il disparaît dès la fin de la résolution.

kubectl run test-dns --rm -it --restart=Never --image=busybox:1.37@sha256:9db7b59979c38555a39def84a31fb98b5296952f9e3afd4f6f11f05b07adfab0 \
  -- nslookup kubernetes.default.svc.cluster.local

Résultat attendu :

Server:    10.43.0.10
Address:   10.43.0.10:53

Name:      kubernetes.default.svc.cluster.local
Address:   10.43.0.1

Nettoyage du test

Supprimez le déploiement de validation avant de poursuivre : ses Pods continueraient à consommer de la mémoire sur des workers déjà justes en ressources.

kubectl delete deployment nginx

Premiers réflexes d'exploitation

RKE2 range tout au même endroit, ce qui simplifie beaucoup le diagnostic : la configuration dans /etc/rancher/rke2/, les données et les binaires dans /var/lib/rancher/rke2/. Les deux réflexes à acquérir sont la lecture des journaux du service avec journalctl et l'inspection des conteneurs avec crictl, puisque aucune commande docker n'existe sur ces nœuds.

Où trouver les fichiers

Ce tableau vous évitera de chercher : il donne la configuration à modifier, les données etcd à sauvegarder et les journaux à consulter en cas d'incident.

Chemin	Contenu
/etc/rancher/rke2/config.yaml	Configuration du nœud
/etc/rancher/rke2/rke2.yaml	Kubeconfig local (server)
/var/lib/rancher/rke2/	Données du cluster
/var/lib/rancher/rke2/server/db/	Données etcd
/var/lib/rancher/rke2/agent/logs/	Logs conteneurs
/usr/local/bin/rke2	Binaire RKE2
/var/lib/rancher/rke2/bin/	Toute la pile d'exécution embarquée par RKE2

Glissez pour voir

Commandes utiles

Ce répertoire mérite un coup d'œil, parce qu'il dit ce que RKE2 embarque réellement. Relevé sur le lab de ce guide :

ls /var/lib/rancher/rke2/bin/

Sortie

containerd  containerd-shim-runc-v2  crictl  ctr  kubectl  kubelet  runc

Ce ne sont pas seulement des outils en ligne de commande : le runtime complet est là, containerd, runc et le kubelet compris. C'est ce qui permet à RKE2 de ne rien exiger de préinstallé sur la machine, contrairement à kubeadm qui suppose containerd déjà en place. Attention toutefois, ce répertoire n'est pas dans le PATH : appelez ces binaires par leur chemin complet, ou ajoutez le répertoire à votre session comme indiqué plus haut. Le binaire rke2 lui-même, lui, est bien dans le PATH, à /usr/local/bin/rke2.

# Logs du service
sudo journalctl -u rke2-server -f
sudo journalctl -u rke2-agent -f

# Status du service
sudo systemctl status rke2-server
sudo systemctl status rke2-agent

# kubectl depuis le server
sudo /var/lib/rancher/rke2/bin/kubectl \
  --kubeconfig /etc/rancher/rke2/rke2.yaml \
  get nodes

# crictl pour inspecter les conteneurs
# Identifiez d'abord le socket containerd sur votre nœud :
ls /run/containerd/ /run/k3s/containerd/ 2>/dev/null

# Puis utilisez crictl avec le socket trouvé
sudo /var/lib/rancher/rke2/bin/crictl \
  --runtime-endpoint unix:///run/k3s/containerd/containerd.sock \
  ps

Un avertissement avant d'automatiser quoi que ce soit autour de ce socket : son chemin varie selon la version de RKE2 et la méthode d'installation. Un script qui le code en dur se cassera silencieusement à la première mise à jour. Vérifiez-le à l'exécution plutôt que de le supposer.

Erreurs fréquentes

Les cinq incidents ci-dessous couvrent l'essentiel de ce qui bloque un premier déploiement RKE2. Trois d'entre eux se ramènent à deux causes : une VM sous-dimensionnée en mémoire, ou une erreur de jonction entre agent et server (token, port ou connectivité). Chaque cas donne le symptôme observé, la cause et la correction.

Le scheduler ou controller-manager échoue

Symptôme :

UnexpectedAdmissionError: preemption: error finding a set of pods to preempt:
no set of running pods found to reclaim resources: memory

Cause : Mémoire insuffisante.

Solution : Augmentez la RAM de la VM à 4 Go minimum pour le server.

---

L'agent ne rejoint pas le cluster

Symptôme : Nœud jamais visible dans kubectl get nodes

Vérifications :

1. Token identique au server ? (/etc/rancher/rke2/config.yaml)
2. URL du server correcte ? (https://IP:9345, pas 6443)
3. Connectivité réseau ? curl -k https://192.168.122.10:9345
4. Service démarré ? systemctl status rke2-agent

---

Kubeconfig : "certificate signed by unknown authority"

Cause : Le kubeconfig local contient un ancien certificat.

Solution :

# Récupérer un kubeconfig frais
ssh kube@192.168.122.10 "sudo cat /etc/rancher/rke2/rke2.yaml" > kubeconfig
sed -i 's/127.0.0.1/192.168.122.10/g' kubeconfig

---

Pods en Pending (scheduler inactif)

Symptôme : Tous les pods Helm helm-install-* restent en Pending.

Cause possible : Le kube-scheduler n'a pas démarré (voir erreur mémoire).

Vérification :

kubectl get pods -n kube-system | grep scheduler

---

NetworkManager interfère avec le CNI

Symptôme : Problèmes réseau après redémarrage.

Solution : Voir la section "Prérequis" pour la configuration de NetworkManager.

Nettoyage du lab

Le nettoyage suit cet ordre : désinstaller RKE2 sur les nœuds, puis détruire les machines virtuelles. Si vous supprimez de toute façon les VM, la première étape est facultative. Elle devient indispensable pour réinstaller RKE2 sur des machines que vous conservez : des données résiduelles empêchent une nouvelle initialisation.

Désinstallation propre de RKE2

Sur chaque nœud, utilisez le script de désinstallation installé par votre méthode d'installation :

# Le chemin dépend de la méthode d'installation
# Vérifiez lequel existe sur votre nœud :
ls -la /usr/local/bin/rke2-uninstall.sh \
      /opt/rke2/bin/rke2-uninstall.sh \
      /usr/bin/rke2-uninstall.sh 2>/dev/null

# Exécutez le script trouvé (exemple avec /usr/local/bin)
sudo /usr/local/bin/rke2-uninstall.sh

Ce script supprime le binaire RKE2, les données et les configurations. Consultez la documentation Uninstall pour les détails.

Suppression des VMs KVM

Désinstaller RKE2 ne suffit pas à libérer les ressources : les machines virtuelles, elles, continuent d'exister et de consommer mémoire et disque. Les deux commandes ci-dessous les détruisent avec leur stockage, ce qui est définitif.

Depuis l'hyperviseur :

# Arrêter et supprimer les VMs
for VM in rke2-cp1 rke2-worker1 rke2-worker2; do
  virsh destroy ${VM} 2>/dev/null
  virsh undefine ${VM} --remove-all-storage
done

# Supprimer les ISOs cloud-init
rm -f rke2-*-cloud-init.iso

Évolutions possibles

Le cluster obtenu est fonctionnel mais reste un lab : un seul server, donc un point de défaillance unique sur etcd et l'API. Trois axes le rapprochent d'une architecture de production, dans cet ordre de priorité : la haute disponibilité du control plane, l'activation du profil CIS, puis l'intégration à Rancher Manager pour la gestion multi-clusters.

Haute disponibilité (HA)

Pour un cluster HA, déployez 3 servers minimum (nombre impair) :

• Quorum etcd : etcd nécessite une majorité de nœuds disponibles (2 sur 3, 3 sur 5). Avec un nombre impair, vous tolérez la perte d'un server.
• Adresse de registration fixe : les agents et servers additionnels doivent pointer vers une adresse stable (load balancer ou VIP)
• Load balancer : HAProxy, keepalived, ou cloud LB devant les servers sur le port 9345/6443

# config.yaml sur chaque server HA
server: https://rke2-lb.example.com:9345
token: votre-token-stable
tls-san:
  - rke2-lb.example.com
  - 192.168.122.100  # VIP du load balancer

La documentation officielle détaille cette architecture : RKE2 HA

Profil CIS Hardening

RKE2 propose des options et profils facilitant la conformité CIS :

/etc/rancher/rke2/config.yaml

profile: cis

Cela active des restrictions de sécurité supplémentaires. Attention : l'installation seule ne garantit pas la conformité, elle facilite l'atteinte des benchmarks.

Intégration Rancher Manager

Le principal atout de RKE2 face aux autres distributions apparaît dès qu'il y a plusieurs clusters : Rancher Manager les pilote depuis une seule interface, avec une gestion centralisée des utilisateurs, des politiques et des mises à jour. C'est la raison pour laquelle beaucoup d'entreprises retiennent RKE2, bien avant ses arguments techniques.

RKE2 s'intègre nativement avec Rancher Manager pour :

• Gestion centralisée multi-clusters
• RBAC visuel
• Monitoring intégré
• Catalogue d'applications

À retenir

• Distribution orientée sécurité : RKE2 facilite la conformité CIS avec des profils et options intégrés, mais l'installation seule ne garantit pas la conformité.
• Configuration via YAML : Privilégiez /etc/rancher/rke2/config.yaml pour une configuration reproductible et versionnable.
• Token stable : Définissez un token explicite et conservez-le : il sert au chiffrement, à la restauration et à l'ajout de nœuds.
• Ports 6443 et 9345 : 6443 pour l'API Kubernetes, 9345 pour l'enregistrement et la supervision RKE2.

Ressources officielles

RKE2 évolue vite, et les composants qu'il embarque changent d'une version à l'autre. Prenez l'habitude de vérifier les notes de version de votre version exacte avant toute installation ou mise à jour : c'est là que sont annoncés les remplacements de composants packagés, comme celui du contrôleur Ingress.

• Introduction RKE2
• Quick Start Linux
• Requirements
• Configuration Options
• Server Config Reference
• Cluster Access
• High Availability
• Uninstall

Contrôle de connaissances

Sept questions sur ce qui distingue vraiment RKE2 et sur les erreurs qui bloquent une installation : le port de jointure, l'emplacement des binaires, et le fichier qui porte toute la configuration.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Backup et Restore : La sauvegarde de l'etcd embarqué et la restauration d'un cluster RKE2.
• Troubleshooting cluster : Le diagnostic à mener quand un agent ne rejoint pas le serveur.

×

📖 Voir la documentation →