Comment tester la recette d'un cluster Kubernetes avant la production

Un cluster OpenShift ou OKD fraîchement installé vous accueille avec une console pleine de vert. Chaque operator se déclare available, chaque nœud est ready, et il est tentant de considérer le travail terminé. Le vert vous dit que les composants ont démarré. Il ne vous dit pas qu'un volume peut être restauré, que le trafic survit à la perte d'un nœud, ou qu'un tenant ne peut pas lire les secrets d'un autre. Cela, vous devez le tester, délibérément, avant que quoi que ce soit d'important n'y tourne.

L'état n'est pas le comportement

Les contrôles de santé du cluster sont faits pour signaler si un composant tourne. La production dépend de la façon dont la plateforme se comporte quand quelque chose tourne mal : un nœud meurt, un disque se remplit, une mise à jour progressive vide un nœud qui porte une base de données. La seule façon de le savoir est de provoquer ces conditions de manière contrôlée et d'observer. Le plan de test ci-dessous couvre les couches qui comptent le plus. Adaptez-le, mais écrivez le vôtre, exécutez chaque étape à la main la première fois, et conservez les preuves.

Stockage : créer, écrire, agrandir, snapshot, restaurer, comparer

Les charges de travail stateful tiennent ou tombent avec le stockage. Pour chaque storage class que vous comptez proposer :

oc apply -f test-pvc.yaml
oc rsh <test-pod> sh -c 'dd if=/dev/urandom of=/data/blob bs=1M count=256 && sha256sum /data/blob'
oc patch pvc test-pvc -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'
oc apply -f test-snapshot.yaml
oc apply -f restore-pvc-from-snapshot.yaml
oc rsh <restore-pod> sha256sum /data/blob

Les sommes de contrôle doivent correspondre. Confirmez que l'agrandissement est visible à l'intérieur du pod avec df, pas seulement dans le claim. Pour du stockage partagé read-write-many, montez le même claim depuis des pods sur deux nœuds différents et confirmez que chacun voit les écritures de l'autre. Puis vérifiez ce qui se passe quand un claim est supprimé : les données de production doivent reposer sur une storage class dont la reclaim policy conserve le volume, pour qu'une suppression par erreur ne le détruise pas.

Panne : tuez un nœud et chronométrez la reprise

Choisissez le nœud qui porte le trafic ingress en production et coupez-le depuis son contrôleur de gestion, pas par un arrêt poli. Depuis l'extérieur du cluster, lancez une boucle qui horodate chaque requête :

while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code}\n' --max-time 2 https://test-app.example.com/
  sleep 0.2
done

La sortie montre exactement combien de temps le service a été indisponible, c'est-à-dire le chiffre que vos utilisateurs ressentiraient. Observez ensuite ce que fait l'orchestrateur : combien de temps avant que le nœud soit marqué not ready, si les pods sont replanifiés, si les pods stateful reviennent avec leurs données. Rallumez le nœud et confirmez qu'il rejoint proprement le cluster. La façon dont le réseau apprend la panne compte ici. Si l'adresse du service est annoncée depuis chaque nœud en BGP et que le côté réseau utilise une détection de panne rapide comme BFD, le trafic peut quitter un nœud mort en quelques secondes, bien avant que Kubernetes lui-même n'ait décidé que le nœud est perdu.

Maintenance : prouvez que les disruption budgets conservent le quorum

La maintenance progressive des nœuds et les mises à jour de la plateforme vident les nœuds les uns après les autres. Une base de données en cluster a besoin d'une majorité de membres actifs à tout moment, et un PodDisruptionBudget est la façon de le dire à la plateforme :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: galera-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: galera

Puis testez-le. Avec un cluster de trois membres et un membre déjà arrêté (son nœud vidé, de sorte que seuls deux membres tournent), essayez de vider le nœud d'un second membre :

oc adm cordon <node-a>
oc adm drain <node-b> --ignore-daemonsets --delete-emptydir-data
oc get pdb

Le drain doit attendre plutôt qu'expulser, parce qu'expulser briserait le quorum. S'il expulse, le budget est faux ou absent, et vous venez de l'apprendre dans un test plutôt qu'au cours d'une mise à jour. Répartissez les membres sur les nœuds avec des topology spread constraints ou de l'anti-affinité, pour qu'une panne de nœud ne puisse jamais emporter deux membres.

Les builds et le registry

Confirmez que le cluster peut construire et exécuter ses propres images, parce qu'un registry interne qui n'accepte pas de push ne sera découvert que le jour d'un déploiement :

oc new-build --name=smoke --binary --strategy=docker
oc start-build smoke --from-dir=. --follow
oc new-app smoke

Accès : testez ce qu'un tenant ne peut pas faire

La multi-tenance se définit par ce qui est refusé à un utilisateur. Créez un utilisateur de test à périmètre restreint par tenant et vérifiez explicitement les frontières :

oc auth can-i get secrets -n tenant-b --as=tenant-a-user
oc auth can-i create pods -n tenant-a --as=tenant-a-user
oc auth can-i list nodes --as=tenant-a-user

La première et la troisième doivent répondre non, la deuxième oui. Vérifiez que les quotas empêchent un tenant de consommer le cluster, que l'ingress de chaque tenant ne sert que ses propres domaines avec un certificat valide, et que le trafic qui quitte le cluster vers vos autres systèmes provient de l'identité d'egress que votre firewall attend.

Conservez les preuves

Enregistrez chaque test avec sa commande, sa sortie et son résultat. Quand quelque chose change plus tard, une mise à jour de la plateforme ou une nouvelle storage class, rejouez la section concernée et comparez. Un cluster qui a passé ses tests une fois et n'a jamais été retesté devient lentement un cluster non testé.

Comment nous le faisons

Nous construisons OpenShift et OKD sur des serveurs HPE dédiés, avec du stockage bloc persistant et du stockage partagé dans le cluster, des adresses de service publiques annoncées par les nœuds en BGP, et un ingress et des certificats par tenant. Avant qu'un cluster ne porte une charge de travail client, il passe par plus de trente contrôles manuels de ce type, des restaurations de stockage octet par octet aux pannes forcées et au cloisonnement des accès. Lors d'une recette, nous avons coupé le nœud qui portait le trafic en production, et le réseau a rerouté en environ trois secondes, bien avant que l'orchestrateur ne déclare le nœud perdu. Les bases de données en cluster sur la plateforme sont construites selon le standard ci-dessus : des disruption budgets qui conservent le quorum, du stockage conservé, des membres répartis sur les nœuds.

Si vous êtes sur le point de mettre de la production sur un nouveau cluster et que vous ne l'avez vu que vert, nous vous aiderons volontiers à le tester correctement d'abord.

Parler à un ingénieur

related line: Voir aussi : Kubernetes privé sur bare metal, OpenShift et OKD · Serveurs bare metal sur HPE et Dell · Private cloud sur KVM avec OLVM

footer line: Publié le 22 octobre 2026. Toutes les notes de terrain