Kubernetes rancher

Fiche express
Type	Plateforme de gestion multi-cluster Kubernetes
Éditeur	SUSE (Rancher Labs, racheté en 2020, à vérifier l'organisation actuelle)
Distribution associée	RKE2 (également K3s pour les environnements plus légers)
Voir aussi	Kubernetes HA · Etcdctl · Kubernetes troubleshooting

Rancher est une plateforme de gestion centralisée pour plusieurs clusters Kubernetes : elle offre une interface unique (UI et API) pour provisionner, superviser et administrer des clusters hétérogènes — clusters déployés avec ses propres distributions (RKE2, K3s), clusters managés d'un fournisseur cloud (EKS, AKS, GKE) importés dans Rancher, ou clusters existants rattachés après coup. Le projet a été créé par Rancher Labs puis racheté par SUSE en 2020 ; l'offre est aujourd'hui commercialisée sous la marque SUSE Rancher (positionnement précis à vérifier selon l'évolution de l'organisation).

RKE2 (Rancher Kubernetes Engine 2) est la distribution Kubernetes durcie que Rancher déploie le plus couramment sur des nœuds Linux classiques ; elle tourne comme service systemd (rke2-server sur les nœuds control plane, rke2-agent sur les workers) et embarque containerd, un CNI et etcd déjà intégrés, dans une configuration orientée sécurité et conformité (CIS Benchmark).

Dépannage courant : expiration de certificats

Comme tout cluster Kubernetes, RKE2 s'appuie sur des certificats X.509 internes (API server, kubelet, etcd...) à durée de vie limitée. Une expiration se manifeste typiquement par un message du type you must be logged into the server (Unauthorized) alors même que le cluster tourne normalement.

Diagnostiquer

# Contexte kubeconfig utilisé
kubectl config view
kubectl config current-context

# Connectivité vers l'API server
kubectl cluster-info
curl -k https://<ip-du-master>:6443/healthz

# Certificate Signing Requests en attente
kubectl get csr

# Date d'expiration du certificat client embarqué dans le kubeconfig
kubectl config view --raw -o jsonpath='{.users[0].user.client-certificate-data}' | base64 -d | openssl x509 -noout -dates

# Date d'expiration de l'ensemble des certificats RKE2, sur le nœud master
for cert in /var/lib/rancher/rke2/server/tls/*.crt; do
  echo "=== $cert ==="
  openssl x509 -noout -dates -in "$cert" 2>/dev/null
done

Renouveler

RKE2 régénère automatiquement ses certificats arrivés à expiration au redémarrage du service — la procédure consiste donc essentiellement à redémarrer rke2-server sur chaque nœud control plane :

sudo systemctl stop rke2-server
sleep 10
sudo systemctl start rke2-server
sudo journalctl -u rke2-server -f   # suivre le redémarrage et la régénération

# Vérifier les nouvelles dates de validité
for cert in /var/lib/rancher/rke2/server/tls/*.crt; do
  echo "=== $cert ==="
  openssl x509 -noout -dates -in "$cert" 2>/dev/null
done

Le kubeconfig généré par RKE2 (/etc/rancher/rke2/rke2.yaml) contient lui aussi les nouveaux certificats ; il doit être recopié vers le poste d'administration et son adresse locale corrigée pour pointer vers l'IP réelle du master plutôt que vers 127.0.0.1 :

sudo scp root@<ip-du-master>:/etc/rancher/rke2/rke2.yaml ~/.kube/config
sed -i 's/127.0.0.1/<ip-du-master>/g' ~/.kube/config
chmod 600 ~/.kube/config

kubectl get nodes
kubectl get pods -A

Cas d'un cluster HA (multi-master)

Sur un control plane à plusieurs nœuds (voir Kubernetes HA), les redémarrages doivent être séquentiels : redémarrer rke2-server sur un master, attendre qu'il repasse Ready, puis seulement passer au suivant.

sudo systemctl restart rke2-server   # sur master-1
watch kubectl get nodes              # attendre Ready avant master-2, etc.

Ne jamais redémarrer tous les masters simultanément : chaque nœud héberge une instance etcd (topologie empilée par défaut sous RKE2), et un redémarrage groupé fait perdre le quorum du cluster — voir Etcdctl pour la restauration à partir d'un snapshot si la situation en arrive là.

Voir aussi

• Kubernetes HA — topologies etcd et raisons de ne jamais redémarrer tous les masters à la fois
• Etcdctl — sauvegarde/restauration en cas de perte de quorum
• Kubernetes troubleshooting — méthodologie de diagnostic plus générale