Πώς να κάνετε acceptance test σε ένα Kubernetes cluster πριν την παραγωγή

Ένα φρεσκοεγκατεστημένο cluster OpenShift ή OKD σάς υποδέχεται με μια κονσόλα γεμάτη πράσινο. Κάθε operator αναφέρει available, κάθε κόμβος είναι ready, και είναι δελεαστικό να το θεωρήσετε τελειωμένο. Το πράσινο σάς λέει ότι τα components ξεκίνησαν. Δεν σας λέει ότι ένα volume μπορεί να γίνει restore, ότι η κίνηση επιβιώνει την απώλεια ενός κόμβου, ή ότι ένας tenant δεν μπορεί να διαβάσει τα secrets ενός άλλου. Αυτά πρέπει να τα δοκιμάσετε, επίτηδες, πριν τρέξει εκεί οτιδήποτε σας ενδιαφέρει.

Η κατάσταση δεν είναι συμπεριφορά

Οι έλεγχοι υγείας του cluster είναι φτιαγμένοι να αναφέρουν αν ένα component τρέχει. Η παραγωγή εξαρτάται από το πώς συμπεριφέρεται η πλατφόρμα όταν κάτι πάει στραβά: ένας κόμβος πεθαίνει, ένας δίσκος γεμίζει, ένα rolling update αδειάζει έναν κόμβο που κουβαλά βάση δεδομένων. Ο μόνος τρόπος να το ξέρετε είναι να προκαλέσετε αυτές τις συνθήκες με ελεγχόμενο τρόπο και να παρακολουθήσετε. Το σχέδιο δοκιμών παρακάτω καλύπτει τα επίπεδα που μετρούν περισσότερο. Προσαρμόστε το, αλλά γράψτε το δικό σας, τρέξτε κάθε βήμα με το χέρι την πρώτη φορά, και κρατήστε τα τεκμήρια.

Storage: δημιουργία, εγγραφή, μεγέθυνση, snapshot, restore, σύγκριση

Οι stateful φόρτοι στέκονται ή πέφτουν με το storage. Για κάθε storage class που σκοπεύετε να προσφέρετε:

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

Τα checksums πρέπει να ταιριάζουν. Επιβεβαιώστε ότι η επέκταση είναι ορατή μέσα στο pod με df, όχι μόνο στο claim. Για κοινόχρηστο storage read-write-many, κάντε mount το ίδιο claim από pods σε δύο διαφορετικούς κόμβους και επιβεβαιώστε ότι το καθένα βλέπει τις εγγραφές του άλλου. Μετά ελέγξτε τι συμβαίνει όταν διαγράφεται ένα claim: τα δεδομένα παραγωγής πρέπει να κάθονται σε storage class του οποίου το reclaim policy κρατά το volume, ώστε μια κατά λάθος διαγραφή να μην το καταστρέψει.

Αποτυχία: σκοτώστε έναν κόμβο και χρονομετρήστε την ανάκαμψη

Διαλέξτε τον κόμβο που κουβαλά τη ζωντανή κίνηση ingress και κλείστε τον από τον ελεγκτή διαχείρισής του, όχι με ευγενικό shutdown. Από έξω από το cluster, τρέξτε έναν βρόχο που βάζει χρονοσφραγίδα σε κάθε αίτημα:

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

Η έξοδος δείχνει ακριβώς πόση ώρα η υπηρεσία δεν ήταν διαθέσιμη, που είναι ο αριθμός που θα ένιωθαν οι χρήστες σας. Μετά παρακολουθήστε τι κάνει ο orchestrator: πόση ώρα μέχρι ο κόμβος να μαρκαριστεί not ready, αν τα pods επαναπρογραμματίζονται, αν τα stateful pods επιστρέφουν με τα δεδομένα τους. Ανάψτε ξανά τον κόμβο και επιβεβαιώστε ότι επανεντάσσεται καθαρά. Το πώς μαθαίνει το δίκτυο την αποτυχία έχει σημασία εδώ. Αν η διεύθυνση της υπηρεσίας ανακοινώνεται από κάθε κόμβο μέσω BGP και η πλευρά του δικτύου τρέχει γρήγορη ανίχνευση αποτυχίας όπως BFD, η κίνηση μπορεί να φύγει από έναν νεκρό κόμβο σε δευτερόλεπτα, πολύ πριν αποφασίσει το ίδιο το Kubernetes ότι ο κόμβος χάθηκε.

Συντήρηση: αποδείξτε ότι τα disruption budgets κρατούν quorum

Η rolling συντήρηση κόμβων και οι ενημερώσεις πλατφόρμας αδειάζουν κόμβους τον έναν μετά τον άλλο. Μια βάση δεδομένων σε cluster χρειάζεται πλειοψηφία μελών up ανά πάσα στιγμή, και ένα PodDisruptionBudget είναι ο τρόπος να το πείτε στην πλατφόρμα:

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

Μετά δοκιμάστε το. Με cluster τριών μελών και ένα μέλος ήδη down (ο κόμβος του αδειασμένος, ώστε να τρέχουν μόνο δύο μέλη), προσπαθήστε να αδειάσετε τον κόμβο ενός δεύτερου μέλους:

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

Το drain πρέπει να περιμένει αντί να κάνει evict, επειδή το evict θα έσπαγε το quorum. Αν κάνει evict, το budget είναι λάθος ή λείπει, και μόλις το μάθατε σε δοκιμή αντί κατά τη διάρκεια ενημέρωσης. Μοιράστε τα μέλη σε κόμβους με topology spread constraints ή anti-affinity, ώστε μια αποτυχία κόμβου να μην μπορεί ποτέ να πάρει δύο μέλη.

Builds και το registry

Επιβεβαιώστε ότι το cluster μπορεί να χτίσει και να τρέξει τα δικά του images, επειδή ένα εσωτερικό registry που δεν δέχεται push θα ανακαλυφθεί μόνο σε μέρα deploy:

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

Πρόσβαση: δοκιμάστε τι δεν μπορεί να κάνει ένας tenant

Η πολυμίσθωση ορίζεται από το τι αρνείται κανείς σε έναν χρήστη. Δημιουργήστε έναν δοκιμαστικό χρήστη περιορισμένης εμβέλειας ανά tenant και ελέγξτε ρητά τα όρια:

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

Το πρώτο και το τρίτο πρέπει να πουν όχι, το δεύτερο ναι. Ελέγξτε ότι τα quotas εμποδίζουν έναν tenant να καταναλώσει το cluster, ότι το ingress κάθε tenant σερβίρει μόνο τα δικά του domains με έγκυρο πιστοποιητικό, και ότι η κίνηση που φεύγει από το cluster προς τα άλλα σας συστήματα έρχεται από την ταυτότητα egress που περιμένει το firewall σας.

Κρατήστε τα τεκμήρια

Καταγράψτε κάθε δοκιμή με την εντολή, την έξοδο και το αποτέλεσμά της. Όταν κάτι αλλάξει αργότερα, μια ενημέρωση πλατφόρμας ή ένα νέο storage class, ξανατρέξτε τη σχετική ενότητα και συγκρίνετε. Ένα cluster που πέρασε τις δοκιμές του μία φορά και δεν δοκιμάστηκε ποτέ ξανά γίνεται σιγά σιγά ένα αδοκίμαστο cluster.

Πώς το κάνουμε εμείς

Χτίζουμε OpenShift και OKD σε αποκλειστικούς servers HPE, με persistent block και κοινόχρηστο storage μέσα στο cluster, δημόσιες διευθύνσεις υπηρεσιών που ανακοινώνονται από τους κόμβους μέσω BGP, και ingress και πιστοποιητικά ανά tenant. Πριν ένα cluster κουβαλήσει φόρτο πελάτη περνά από περισσότερους από τριάντα χειροκίνητους ελέγχους αυτού του είδους, από restores storage byte προς byte μέχρι εξαναγκασμένες αποτυχίες και περιορισμό πρόσβασης. Σε ένα acceptance test κλείσαμε τον κόμβο που κουβαλούσε τη ζωντανή κίνηση, και το δίκτυο επαναδρομολόγησε σε περίπου τρία δευτερόλεπτα, πολύ πριν ο orchestrator δηλώσει τον κόμβο χαμένο. Οι βάσεις δεδομένων σε cluster στην πλατφόρμα χτίζονται με το παραπάνω πρότυπο: disruption budgets που κρατούν quorum, storage που διατηρείται, μέλη μοιρασμένα σε κόμβους.

Αν ετοιμάζεστε να βάλετε παραγωγή σε νέο cluster και το έχετε δει μόνο πράσινο, ευχαρίστως να σας βοηθήσουμε να το δοκιμάσετε σωστά πρώτα.

Μιλήστε με έναν μηχανικό

related line: Σχετικά: Ιδιωτικό Kubernetes σε bare metal, OpenShift και OKD · Bare metal servers σε HPE και Dell · Private cloud σε KVM με OLVM

footer line: Δημοσιεύτηκε 22 Οκτωβρίου 2026. Όλες οι σημειώσεις από το πεδίο