ZeusK8s
Day-two operations

Getting it running was the easy part. Keeping it running is the job.

40% of teams lack the skills to operate the Kubernetes they already deployed. Not because they're not capable — because Kubernetes operational complexity compounds quietly until an upgrade breaks something nobody can explain, or a node disappears and the runbook is a Notion doc nobody has read.

Tribal knowledge is not a DR strategy.

The person who set up the cluster understands it. Everyone else guesses. Config drifts from what it's supposed to be. Upgrades get deferred because nobody is confident they won't break something. The node group that runs the payments service has a taint nobody remembers adding.

Zeus doesn't make Kubernetes simpler — it makes the complexity understandable and the operations repeatable. Provisioning, scaling, upgrading, and tearing down clusters follows the same guided flow regardless of who does it or which cloud it runs on.

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
What day-two actually looks like

The four operations every cluster needs.

01

Provisioning

One five-step wizard — provider, basics, network plan, add-ons, review — works the same for EKS, GKE, k3s, and Proxmox. Watch it build live. No Terraform modules to maintain, no provider-specific scripts to debug.

02

Scaling node groups

EKS-style managed node groups on every cluster type, including k3s on bare metal. Add nodes, change instance types, enable spot, set labels and taints, scale live — without touching the cluster directly.

03

Upgrades that don't gamble with production

An EOL banner appears before support ends. Preflight checks surface blockers — deprecated APIs, incompatible add-ons — before anything moves. A stepped flow (control plane → add-ons → node groups) with rollback means a version bump isn't a weekend of anxiety.

04

Clean teardown

Destroy sweeps tagged resources with a keep/delete checklist: EBS volumes, KMS keys, security groups, load balancers. Nothing lingers. No orphaned resources quietly accruing charges months later.

Upgrades

A Kubernetes version bump shouldn't be a gamble.

Most outages from upgrades happen for the same reasons: deprecated APIs that weren't caught, add-ons that don't support the new version, node groups updated before the control plane was stable. Zeus walks you through each step in order.

EOL warning

Zeus tracks Kubernetes support windows and surfaces a banner when your version is approaching end-of-life — before you're forced to upgrade in a hurry.

Preflight checks

Before anything moves, Zeus checks for deprecated API usage, incompatible add-ons, and known blockers specific to your version jump.

Stepped flow

Control plane upgrades first, then add-ons, then node groups — in the order Kubernetes expects. Each step confirms before proceeding.

Rollback

If something goes wrong, the rollback path is explicit and guided — not a manual procedure you're inventing under pressure.

The day-two checklist

What you stop having to figure out on the fly.

Version drift between clusters
Orphaned cloud resources after teardown
Node groups that only one person understands
Upgrades deferred until they're urgent
A DR runbook nobody has tested
Config that differs between prod and staging without anyone noticing
Spot instance reclamation taking down capacity
Add-on compatibility on version bump
Manual taint and label management across node groups