Kubernetes orchestration and optimization
Clusters that are the right size, calm on call and boring to upgrade.
For teams running AKS, EKS, GKE or Kubernetes on their own hardware who pay for half-empty nodes, fear upgrades or get paged too often. I right-size on real usage, put the cluster under GitOps and make scaling and upgrades routine, in the cloud, on bare metal or both.
Sounds familiar?
- Requests and limits were guessed once and never revisited, so nodes run half empty
- Nobody dares to upgrade the cluster, so it drifts behind supported versions
- Changes are applied by hand and nobody knows what is actually running
- Part of the workload has to stay on-premises or even offline
How I work on it
- 1
Measure a real week
Prometheus records p95 CPU and memory per workload over at least a week, including the busy days, so decisions rest on data instead of feelings.
- 2
Set requests from the data
Requests follow p95 plus headroom, limits protect neighbours, and PodDisruptionBudgets keep services up while nodes come and go.
- 3
Let the cluster shrink
The cluster autoscaler or Karpenter removes nodes the pods no longer need. In one production cluster this took us from 7 to 4 nodes with no customer impact.
- 4
Everything in Git
FluxCD and Helm apply what is in the repository, so every change is reviewed, reproducible and easy to roll back, and upgrades become a pull request.
- 5
Cloud, on-prem or both
Where it is needed, one platform spans bare metal and AWS, Windows workloads run as VMs on KubeVirt, and parts stay air-gapped.
Interactive
How many nodes do your requests really need?
Move the sliders to your numbers. Requests decide where pods fit, so oversized requests buy nodes nobody uses.
Node size
5
nodes today
2
nodes after right-sizing (200m)
60%
less node capacity
CPU only, about 90% of a node is allocatable, at least 2 nodes for availability. Check memory the same way before you remove a node.
All calculators and checklistsWhat you get
- p95 dashboards per workload in Grafana
- Requests, limits and disruption budgets set from real data
- Autoscaling that removes unneeded nodes, tested under load
- GitOps with FluxCD and Helm, including an upgrade runbook
- Alerts on business outcomes, not just CPU
Questions buyers ask
Which Kubernetes flavours do you work with?
AKS, EKS and GKE in the cloud, and Kubernetes on your own hardware such as Talos, including hybrid setups where one platform spans both.
Is right-sizing risky for production?
Not if it is done on p95 data, with headroom, disruption budgets and one change at a time. Each step has a way back, and nodes leave only after the pods have moved.
How long does it take?
One week of measuring, then the first changes. A typical right-sizing and GitOps setup is a matter of a few weeks, depending on the number of clusters and workloads.
Can my team run it afterwards?
Yes. Everything lives in Git with runbooks for upgrades and incidents, and I hand over in working sessions with your team.
How do you price it?
After a 30-minute call: a fixed scope for a defined result, or a few days per month as your platform lead.
Read more
- Right-size Kubernetes: the playbook that took a cluster from 7 to 4 nodes
- Kubernetes cost on EKS and GKE: the same playbook, different levers
- MiniMax M3: an open frontier model you can run yourself?
- Air-gapped systems: running critical software with no internet
- Free guide (PDF): Cut your cloud bill without breaking anything
Get in touch
Tell me what you're building. I'll reply within 1–2 business days.
- Company
- MADO Consulting
- Follow me on LinkedIn
Available worldwide, remote. On-site on request, depending on the country.
Opens Calendly's booking calendar here. Loading it sends data to Calendly (see Impressum).