Kubernetes für Leute, die es betreiben müssen

Ein praktischer Leitfaden zum Betreiben von Kubernetes in der Produktion, von Resource Requests bis zu etcd-Sicherungen und den Seiten, die um 3 Uhr morgens wirklich zählen.

Kubernetes-Tutorials bringen dir bei, wie du einen Pod bereitstellst. Niemand bringt dir bei, was du tust, wenn ein Node um 3 Uhr morgens stillschweigend den Ready-Status verlässt und dein On-Call-Telefon nicht aufhört zu klingeln. Das hier ist der zweite Teil.

Resource Requests und Limits sind nicht optional

Wenn du resources.requests und resources.limits bei deinen Containern auslässt, rät der Scheduler, und der kubelet weiß nicht, was es zuerst entfernen soll, wenn ein Node wenig Speicher hat. Setze Requests auf das, was der Container unter normaler Last tatsächlich nutzt, nicht auf das, was du dir erhoffst. Setze Memory Limits nahe an Requests, da OOM-getötete Pods sauber neu starten, aber CPU Limits sollten generell lockerer oder abwesend sein, es sei denn, du bekämpfst lärmige Nachbarn, weil CPU-Drosselung unter einem harten Limit Latenz-Spitzen verursacht, die miserable zu debuggen sind. Führe kubectl top pods -n your-namespace regelmäßig aus und vergleiche gegen das, was du deklariert hast. Abweichungen sammeln sich in Clustern mit mehr als einer Handvoll Services schnell an.

etcd ist der ganze Cluster, behandle es so

Alles, was Kubernetes kennt, lebt in etcd. Verliere es und du verlierst deinen Cluster-Status, nicht nur einige Metadaten. Führe etcdctl snapshot save /backup/etcd-snapshot.db nach Plan aus, und teste tatsächlich, es auf einem Scratch-Cluster mindestens einmal wiederherzustellen. Ich habe Teams mit nächtlichen Sicherungen gesehen, die sich als drei Monate lang beschädigt herausgestellt haben, weil niemand sie überprüft hat. Wenn du auf einer verwalteten Control Plane bist (EKS, GKE, AKS), verwaltest du etcd nicht direkt, aber du solltest immer noch die Backup- und Restore-Geschichte deines Providers kennen, bevor du sie brauchst, nicht während eines Incidents.

Liveness und Readiness Probes müssen manchmal unterschiedlich sein

Ein häufiger Fehler ist, denselben Endpoint für beide Liveness und Readiness Probes zu verwenden. Liveness sollte antworten

Mit KI-Unterstützung geschrieben, von Michal Pilch (CISSP), Korra Studio, überprüft und veröffentlicht.