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.

Version testée

Ce guide a été validé avec RKE2 v1.34.5+rke2r1 sur Ubuntu 24.04. Les commandes peuvent varier selon votre version — consultez les releases officielles pour les dernières informations.

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

Quand choisir RKE2 ?

Choisissez RKE2 si vous voulez :

• Un cluster orienté sécurité avec hardening par défaut
• Une distribution packagée plutôt qu’un assemblage de composants
• Une intégration native avec Rancher Manager
• Un support enterprise de SUSE/Rancher
• Une conformité avec les benchmarks CIS

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

Ressources requises

RKE2 est plus gourmand que k0s ou k3s. Valeurs validées dans ce lab :

• Server : 4 Go RAM, 2 vCPUs
• Agent : 3 Go RAM, 2 vCPUs

Les exigences réelles dépendent de votre charge et de vos composants activés.

Changement d'Ingress prévu

Ingress NGINX arrive en fin de vie (mars 2026). À partir de RKE2 v1.36, Traefik deviendra l’Ingress par défaut pour les nouveaux clusters. Anticipez ce changement dans vos déploiements.

Architecture du lab

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

Ports réseau requis

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

Ports additionnels

Pour ce lab single-server, les ports ci-dessus suffisent. En cluster HA ou avec NodePort, ouvrez aussi :

• 2379-2381 entre servers (etcd)
• 30000-32767 pour les NodePort
• 9099, 51820-51821 selon la configuration Canal

Consultez la documentation requirements pour la liste complète.

Prérequis

Sur l’hyperviseur (votre machine)

# 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 si absent
curl -LO "https://dl.k8s.io/release/$(curl -Ls https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
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

# Télécharger l'image cloud Ubuntu 24.04
wget -O ubuntu-24.04-cloudimg.img \
  https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img

Création des VMs KVM

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

   Syntaxe Netplan

   Ce guide utilise routes plutôt que gateway4 (déprécié dans Netplan moderne). Adaptez l’interface (enp1s0) selon votre environnement.

   Personnalisation

   Remplacez ssh-ed25519 AAAA... par votre clé SSH publique réelle. Adaptez les IPs si vous utilisez un autre réseau.

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

   Réseau libvirt

   --network network=default utilise le réseau NAT virbr0 géré par libvirt. Si vous avez une configuration différente, adaptez selon votre environnement (ex: --network bridge=br0).

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

1. Installer RKE2 sur le server

   ssh kube@192.168.122.10 << 'EOF'
   # Télécharger et exécuter le script d'installation
   curl -sfL https://get.rke2.io | sudo sh -
   EOF

   Méthode d'installation

   Le script get.rke2.io est une méthode simplifiée (convenience method) qui utilise le canal stable par défaut. Pour des environnements plus contrôlés, consultez les méthodes d’installation documentées.

   Pour fixer une version : INSTALL_RKE2_VERSION=v1.34.5+rke2r1 curl -sfL https://get.rke2.io | sudo sh -

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).

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 | INSTALL_RKE2_TYPE="agent" sudo sh -
   EOF
   done

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

   Port 9345

   Notez que l’URL du server utilise le port 9345 (et non 6443). C’est le port de supervision/registration de RKE2.

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

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

   kubectl sur le server

   RKE2 installe kubectl dans /var/lib/rancher/rke2/bin/, mais ce chemin n’est pas dans le PATH par défaut. Pour l’utiliser directement sur le server :

   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 ?

Si un nœud reste en NotReady longtemps :

1. Vérifiez les logs : journalctl -u rke2-server ou rke2-agent
2. Vérifiez la connectivité réseau vers le port 9345
3. Vérifiez que le CNI (Canal) est initialisé : kubectl get pods -n kube-system | grep canal

Vérification du cluster

Pods système

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

Composants désactivables

Les composants packagés (rke2-coredns, rke2-ingress-nginx, rke2-metrics-server) peuvent être désactivés via le paramètre disable dans config.yaml. La liste exacte dépend de votre configuration.

Test de déploiement

# Créer un déploiement nginx
kubectl create deployment nginx --image=nginx:alpine --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

kubectl run test-dns --rm -it --restart=Never --image=busybox:1.36 \
  -- 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

kubectl delete deployment nginx

Premiers réflexes d’exploitation

Où trouver les fichiers

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/	Binaires additionnels (kubectl, crictl)

Glissez pour voir

Commandes utiles

# 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

Socket containerd

Le chemin du socket peut varier selon la version et la méthode d’installation. Vérifiez le chemin réel avant d’automatiser des scripts.

Erreurs fréquentes

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

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

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

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

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

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

Prochaines étapes

Configurer un Ingress Exposer vos applications avec NGINX Ingress (actuel) ou Traefik (défaut à partir de v1.36).

Stockage persistant Configurer des volumes persistants avec Longhorn ou local-path.

×

📖 Voir la documentation →