ZeusK8s
Day-2 Operations

Es zum Laufen zu bringen war der leichte Teil. Es am Laufen zu halten ist der Job.

Day-2 ist, wo Kubernetes still Teams frisst: Upgrades, die etwas Undokumentiertes brechen, Node Loss mit stale Runbook und Config, die nur eine Person erklären kann. Zeus macht Upgrades, Scale und Teardown aus derselben Console bedienbar, in der Sie provisionieren.

Tribal Knowledge ist keine DR-Strategie.

Die Person, die den Cluster aufgesetzt hat, versteht ihn. Alle anderen raten. Config driftet von dem, was sie sein soll. Upgrades werden deferred, weil niemand sicher ist, dass sie nichts brechen. Die Node Group, die den Payments Service läuft, hat einen Taint, den niemand erinnert hinzugefügt zu haben.

Zeus macht Kubernetes nicht einfacher — es macht die Komplexität verständlich und die Operations wiederholbar. Provisioning, Scaling, Upgrading und Tear Down von Clustern folgt demselben guided Flow — unabhängig davon, wer es tut oder auf welcher Cloud es läuft.

Zeus · Clusters
Clusters
6 clusters · 3 providers
Live New Cluster
NameProviderRegionVersionNodesStatus
production-usAWS EKSus-east-11.306Ready
production-euGKEeurope-west31.304Ready
stagingAWS EKSus-west-21.29→1.30 ⚠3Ready
edge-apacGKEasia-east11.302Ready
HQ Denverk3sDenver, COv1.35.55Ready
prox-test01ProxmoxProvo, UTv1.34.1Provisioning
Wie Day-2 tatsächlich aussieht

Die vier Operations, die jeder Cluster braucht.

01

Provisioning

Ein Fünf-Schritt-Wizard — Provider, Basics, Network Plan, Add-ons, Review — funktioniert gleich für EKS, GKE, k3s und Proxmox. Live zusehen, wie er baut. Keine Terraform Modules zu pflegen, keine provider-spezifischen Skripte zu debuggen.

02

Node Groups skalieren

EKS-artige managed Node Groups auf jedem Cluster-Typ, inklusive k3s auf Bare Metal. Nodes hinzufügen, Instance Types ändern, Spot enablen, Labels und Taints setzen, live skalieren — ohne den Cluster direkt anzufassen.

03

Upgrades, die nicht mit Production zocken

Ein EOL-Banner erscheint vor Support-Ende. Preflight Checks surface Blocker — deprecated APIs, inkompatible Add-ons — bevor sich etwas bewegt. Ein gestufter Flow (Control Plane → Add-ons → Node Groups) mit Rollback bedeutet: ein Version Bump ist kein Wochenende voller Anxiety.

04

Sauberes Teardown

Destroy fegt getaggte Resources mit Keep/Delete-Checkliste: EBS Volumes, KMS Keys, Security Groups, Load Balancer. Nichts bleibt hängen. Keine orphaned Resources, die monatelang still Kosten auflaufen.

Upgrades

Ein Kubernetes Version Bump sollte kein Glücksspiel sein.

Die meisten Outages durch Upgrades passieren aus denselben Gründen: deprecated APIs, die nicht gefangen wurden, Add-ons, die die neue Version nicht supporten, Node Groups updated, bevor das Control Plane stabil war. Zeus führt Sie durch jeden Schritt in Order.

EOL Warning

Zeus trackt Kubernetes Support Windows und zeigt ein Banner, wenn Ihre Version sich dem End-of-Life nähert — bevor Sie in Eile upgraden müssen.

Preflight Checks

Bevor sich etwas bewegt, checkt Zeus deprecated API Usage, inkompatible Add-ons und bekannte Blocker für Ihren Version Jump.

Gestufter Flow

Control Plane Upgrades zuerst, dann Add-ons, dann Node Groups — in der Order, die Kubernetes erwartet. Jeder Step bestätigt, bevor es weitergeht.

Rollback

Wenn etwas schiefläuft, ist der Rollback-Pfad explizit und guided — keine manuelle Procedure, die Sie unter Druck erfinden.

Die Day-2-Checkliste

Worum Sie aufhören müssen, on the fly herauszufinden.

Version Drift zwischen Clustern
Orphaned Cloud Resources nach Teardown
Node Groups, die nur eine Person versteht
Upgrades deferred, bis sie urgent sind
Ein DR-Runbook, das niemand getestet hat
Config, die zwischen Prod und Staging abweicht, ohne dass es jemand merkt
Spot Instance Reclamation, die Capacity runterreißt
Add-on Compatibility beim Version Bump
Manuelles Taint- und Label-Management über Node Groups

Hören Sie auf, während eines echten Outages herauszufinden, dass Ihr Runbook nicht funktioniert.

Sehen Sie in einem Live-Demo, wie Zeus Provisioning, Upgrades und Operations handhabt.