Come fare l'acceptance test di un cluster Kubernetes prima della produzione

Un cluster OpenShift o OKD appena installato vi accoglie con una console piena di verde. Ogni operator riporta available, ogni nodo è ready, ed è tentante dichiararlo finito. Il verde vi dice che i componenti sono partiti. Non vi dice che un volume può essere ripristinato, che il traffico sopravvive alla perdita di un nodo, o che un tenant non può leggere i secret di un altro tenant. Quelle cose dovete testarle, di proposito, prima che ci giri qualcosa a cui tenete.

Lo stato non è il comportamento

I controlli di salute del cluster sono fatti per riferire se un componente è in esecuzione. La produzione dipende da come la piattaforma si comporta quando qualcosa va storto: un nodo muore, un disco si riempie, un rolling update drena un nodo che porta un database. L'unico modo per saperlo è provocare quelle condizioni in modo controllato e osservare. Il piano di test qui sotto copre i livelli che contano di più. Adattatelo, ma scrivete il vostro, eseguite ogni passo a mano la prima volta, e conservate le evidenze.

Storage: create, scrivete, espandete, snapshot, restore, confrontate

I carichi stateful stanno in piedi o cadono con lo storage. Per ogni storage class che intendete offrire:

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

I checksum devono corrispondere. Confermate che l'espansione sia visibile dentro il pod con df, non solo nel claim. Per lo storage condiviso read-write-many, montate lo stesso claim da pod su due nodi diversi e confermate che ciascuno veda le scritture dell'altro. Poi controllate cosa succede quando un claim viene cancellato: i dati di produzione devono stare su una storage class la cui reclaim policy conserva il volume, così una cancellazione per errore non lo distrugge.

Guasto: uccidete un nodo e cronometrate il recupero

Scegliete il nodo che porta il traffico ingress live e spegnetelo dal suo controller di gestione, non con uno shutdown educato. Da fuori del cluster, eseguite un ciclo che mette un timestamp a ogni richiesta:

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

L'output mostra esattamente per quanto tempo il servizio non è stato disponibile, che è il numero che i vostri utenti sentirebbero. Poi osservate cosa fa l'orchestratore: quanto tempo prima che il nodo sia marcato not ready, se i pod vengono rischedulati, se i pod stateful tornano con i loro dati. Riaccendete il nodo e confermate che rientri in modo pulito. Come la rete viene a sapere del guasto conta, qui. Se l'indirizzo del servizio è annunciato da ogni nodo via BGP e il lato rete esegue un rilevamento rapido dei guasti come BFD, il traffico può allontanarsi da un nodo morto in secondi, ben prima che Kubernetes stesso abbia deciso che il nodo è perso.

Manutenzione: dimostrate che i disruption budget mantengono il quorum

La manutenzione rolling dei nodi e gli aggiornamenti di piattaforma drenano i nodi uno dopo l'altro. Un database in cluster ha bisogno di una maggioranza di membri up in ogni momento, e un PodDisruptionBudget è il modo per dirlo alla piattaforma:

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

Poi testatelo. Con un cluster a tre membri e un membro già down (il suo nodo drenato, così che girino solo due membri), provate a drenare il nodo di un secondo membro:

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

Il drain dovrebbe attendere invece di fare evict, perché l'evict romperebbe il quorum. Se fa evict, il budget è sbagliato o manca, e l'avete appena scoperto in un test invece che durante un aggiornamento. Distribuite i membri sui nodi con topology spread constraint o anti-affinity, così il guasto di un nodo non possa mai portarsi via due membri.

Build e registry

Confermate che il cluster possa costruire ed eseguire le proprie immagini, perché un registry interno che non accetta push verrà scoperto solo il giorno del deploy:

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

Accesso: testate cosa un tenant non può fare

La multi-tenancy è definita da ciò che viene negato a un utente. Create un utente di test con ambito limitato per tenant e controllate esplicitamente i confini:

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

Il primo e il terzo devono dire no, il secondo sì. Controllate che le quota impediscano a un tenant di consumare il cluster, che l'ingress di ogni tenant serva solo i propri domini con un certificato valido, e che il traffico che lascia il cluster verso gli altri vostri sistemi provenga dall'identità di egress che il vostro firewall si aspetta.

Conservate le evidenze

Registrate ogni test con il suo comando, l'output e il risultato. Quando qualcosa cambia più avanti, un aggiornamento di piattaforma o una nuova storage class, rieseguite la sezione pertinente e confrontate. Un cluster che ha superato i suoi test una volta e non è mai stato testato di nuovo diventa lentamente un cluster non testato.

Come lo facciamo noi

Costruiamo OpenShift e OKD su server HPE dedicati, con block storage persistente e storage condiviso dentro il cluster, indirizzi pubblici dei servizi annunciati dai nodi via BGP, e ingress e certificati per tenant. Prima che un cluster porti un carico di un cliente passa attraverso più di trenta controlli manuali di questo tipo, dai restore dello storage byte per byte ai guasti forzati alla delimitazione degli accessi. In un acceptance test abbiamo spento il nodo che portava il traffico live, e la rete ha reinstradato in circa tre secondi, molto prima che l'orchestratore dichiarasse perso il nodo. I database in cluster sulla piattaforma sono costruiti secondo lo standard qui sopra: disruption budget che mantengono il quorum, storage che viene conservato, membri distribuiti sui nodi.

Se state per mettere la produzione su un nuovo cluster e lo avete visto solo verde, siamo lieti di aiutarvi a testarlo per bene prima.

Parla con un ingegnere

related line: Correlati: Kubernetes privato su bare metal, OpenShift e OKD · Server bare metal su HPE e Dell · Private cloud su KVM con OLVM

footer line: Pubblicato il 22 ottobre 2026. Tutte le note dal campo