Wir betreiben ein Kubernetes-Cluster. Derzeit (08/2022) läuft dies auf 3 VMs in unserer VM-Infrastruktur.
Die Kubernetes-API ist nur aus dem RWTH-Netz unter https://api.k8s.fsmpi.rwth-aachen.de erreichbar.
Der Login erfolgt per OpenID Connect. Zunächst installiere man kubectl und kubectl-login gemäß Packungsanweisung. Den Login konfiguriert man wie folgt:
touch ~/.kubectl-login.yaml chmod 0600 ~/.kubectl-login.yaml kubectl login \ --k8s-api-server https://api.k8s.fsmpi.rwth-aachen.de \ --k8s-server-ca-path /etc/ssl/certs/ISRG_Root_X1.pem \ --oidc-client-id kubernetes \ --oidc-server https://keycloak.fsmpi.rwth-aachen.de/realms/fsmpi
Mit kubectl whoami –all kann man dann sehen, mit welchen Gruppen man eingeloggt ist.
Man sollte vermeiden, Kubernetes-Nodes ohne sie vorher als unverfügbar zu markieren und von Containern zu befreien neu zu starten (also so wie mit Ganeti und VMs auch schon). Insbesondere sollte man keinesfalls das Quorum der Control Plane unterschreiten (bei aktuell (03/2023) drei also nie mehr als einen gleichzeitig offline nehmen).
Vorgehen (hier exemplarisch mit `k8s-hydrogen`):
kubectl cordon k8s-hydrogen # Node als "unschedulable" markieren kubectl get pods -A -l application=spilo -o wide -L spilo-role -w # Warten, bis kein Postgres-Pod auf k8s-hydrogen mehr master ist (spilo-role) kubectl drain k8s-hydrogen --ignore-daemonsets --delete-emptydir-data --dry-run=server # Schauen, ob das drainen funktionieren würde … kubectl drain k8s-hydrogen --ignore-daemonsets --delete-emptydir-data # … und machen # Reboot. kubectl get nodes -w # Warten, bis k8s-hydrogen wieder "Ready" ist kubectl uncordon k8s-hydrogen # Node wieder freigeben
Das ist leider ein bisschen umständlich, aber ohne sauberen Postgres-Failover (durch explizit erst cordon und warten, nicht einfach drain und hü) riskiert man leider eine ungeplante Datenbank-Wartung mit ggf. Postgres-Cluster aus Backup neu aufbauen.