Kubernetes Platform Engineering

Kubernetes & EKS Consulting

You already adopted Kubernetes. Now make it cheap, safe and boring to operate.

Most teams do not have a Kubernetes problem. They have an under-resourced Kubernetes problem — requests set once and never revisited, autoscaling that thrashes, no idea which team owns which half of the bill, and an upgrade nobody wants to schedule. We fix the operational layer on EKS and self-managed clusters, without a rewrite.

EKSKARPENTERHELMGITOPSARGOCDCILIUMMULTI-TENANCYDAY-2 OPS

Measured

Right-sizing from real usage data, not guesses

Attributed

Spend broken out per namespace, team and workload

Reversible

Every change lands through Git — rollback is a revert

3–8 weeks

Typical engagement, from cluster audit to hardened production

Why Zenthos

Kubernetes is rarely the wrong choice. It is frequently an under-resourced one.

Teams adopt Kubernetes for good reasons — many services deploying independently, standard rollout and rollback semantics, a scheduler that does not care which cloud it is on. Then they staff it with the same two engineers who already own CI, the VPN and the on-call rota. The platform keeps doing exactly what it says it will. What decays is everything around it, because nobody has the hours to own it.

The symptoms are consistent. Requests and limits were set during the migration and never revisited, so the scheduler bin-packs against fiction and you pay for reserved capacity that no pod ever uses. Cluster autoscaler thrashes on mixed workloads — it scales a node group that cannot actually fit the pod that triggered it, then scales back down ten minutes later. There is no namespace-level cost attribution, so the cluster line item is one number and no team owns any part of it. Version upgrades get deferred past two or three releases until they stop being routine and start being a project with a risk register. And the cluster is described as multi-tenant when multi-tenancy means a namespace label and nothing else: no default-deny NetworkPolicy, no ResourceQuota, no PodDisruptionBudget, so one team’s runaway job can take down another team’s API.

We do not rebuild your platform. We start read-only — utilisation data, manifests, node groups, RBAC, add-on versions — and come back with a prioritised list of what is costing money and what is going to hurt. Then we land changes through your GitOps pipeline, in your repos, in an order that puts the low-risk savings first and the structural work second. We will also tell you when Kubernetes is the wrong tool for a specific workload and the honest answer is to move it to ECS, Fargate or a managed PaaS. That conversation is cheaper in week one than in month six.

What We Deliver

Core Capabilities

[01]

Cluster Architecture & EKS Setup

Greenfield clusters, or a second opinion on the one you already run. VPC and subnet layout, node group topology, IRSA and EKS Pod Identity, add-on selection, and the boring decisions — CNI, ingress, storage classes — that are genuinely painful to change later.

[02]

Autoscaling: Karpenter, HPA & VPA

Three layers that have to agree: pods scale on a signal that reflects load, nodes arrive fast enough to matter, and neither fights the other. We tune HPA targets, run VPA in recommendation mode to fix requests, and move node scaling to Karpenter where it earns its complexity.

[03]

Cost Allocation & Right-Sizing

Requests reset against measured usage, idle and orphaned resources reclaimed, spot introduced only where interruption is tolerable, and per-namespace and per-label reporting through OpenCost or Kubecost — so the bill arrives with an owner attached.

[04]

GitOps Delivery

Argo CD or Flux as the single path into the cluster, with environments modelled as overlays rather than tribal knowledge. Drift becomes visible, rollback becomes a revert, and shipping no longer requires anyone to hold kubectl apply access against production.

[05]

Security & Multi-Tenancy Hardening

Default-deny NetworkPolicy, ResourceQuota and LimitRange per namespace, Pod Security Admission, RBAC that maps to real teams, and admission policy via Kyverno or Gatekeeper. Isolation that is enforced by the cluster rather than assumed by the wiki.

[06]

Upgrade Strategy & Day-2 Operations

A repeatable upgrade path: deprecated-API scan, add-on compatibility matrix, blue/green node groups, PodDisruptionBudgets that actually hold, and a runbook your on-call can follow at 3am without calling the one person who remembers how it works.

How It Compares

Karpenter vs. Cluster Autoscaler vs. fixed managed node groups

Three ways to decide how many nodes you have and what shape they are. They fail differently, and the fastest option is not automatically the right one.

KarpenterCluster AutoscalerFixed managed node groups
Scale-up latencyFast. Calls the EC2 fleet API directly — no Auto Scaling group round-trip.Slower. Polls for unschedulable pods, raises ASG desired capacity, then waits for the node to boot and join.Zero while you have headroom. Past that, someone changes a number by hand.
Instance-type flexibilityWide. A NodePool can span families, sizes and architectures, and it picks the cheapest that fits the pending pods.Bounded by the node groups you defined. Instances within a group should share a shape or scheduling estimates drift.Fixed at creation. Changing shape means a new node group and a migration.
Spot handlingNative. Spreads across many spot pools, drains on the interruption notice, and can consolidate spot onto spot.Workable via mixed-instance ASGs and a termination handler, but the pool choice is set at node-group creation.Possible, but fixed capacity means an interruption leaves you short until the group refills.
Bin-packing efficiencyHigh. Sizes the node to the pods, and consolidation replaces underused nodes with cheaper ones.Moderate. Removes a node once it has been underused long enough, but cannot swap it for a smaller type.You pay for the headroom whether the scheduler uses it or not.
Operational complexityA controller, its CRDs, IAM and an interruption queue to own. Major versions have carried breaking API changes.Mature and well understood. The cost is node-group sprawl as you add instance shapes.Lowest. Nothing extra to run, nothing extra to debug during an incident.
Best whenMixed pod shapes, bursty demand, or serious spot usage on AWS.Uniform node shapes, existing ASG tooling, or a platform where the Karpenter provider is not yet mature.Small, steady workloads where the traffic curve is basically flat.

Fixed managed node groups are the right answer more often than autoscaling advocates suggest. If your workload is small and predictable, two correctly sized node groups will cost you less in engineering attention than any autoscaler will save you in EC2.

How We Work

Our Process

01

Cluster Audit

Read-only access first. We pull utilisation against requests, review manifests, node groups, RBAC, network policy and add-on versions, and return a prioritised written list of what is wasting money and what is going to break.

02

Right-Size & Reclaim

Requests and limits reset against measured usage, orphaned volumes and load balancers removed, node groups consolidated. Lowest-risk savings first, verified against your SLOs before anything structural changes.

03

Autoscaling & Node Strategy

Karpenter, or a properly tuned Cluster Autoscaler if that is the better fit. Spot where interruption is tolerable, on-demand where it is not. Migrated one node group at a time with workloads live.

04

Guardrails & Delivery

Quotas, default-deny network policy, PodDisruptionBudgets, admission rules, and GitOps as the only route into the cluster. This is what stops step 02 from quietly reversing itself over the next two quarters.

05

Upgrade & Hand Over

We run one full version upgrade alongside your team, then leave the runbook, the dashboards and the Terraform and Helm behind. You should not need us for the next one.

Tools & Technologies

Tech Stack

We choose the right tool for the job — not the trendiest one.

Kubernetes logoKubernetes
Amazon EKS logoAmazon EKS
Karpenter
Helm
Argo CD
Terraform logoTerraform
Prometheus
Cilium
Questions

Frequently Asked Questions

Do we actually need Kubernetes?
Often, no. If you run a handful of services, deploy from one team, and have no hard requirement for custom schedulers, operators or portability across clouds, then ECS Fargate, Cloud Run, App Runner or a managed PaaS will cost you less in both dollars and attention. Kubernetes earns its complexity when several teams ship independently, when workloads have genuinely different resource shapes, or when you depend on something that only exists in that ecosystem — operators, service mesh, GPU scheduling. We would rather tell you that in week one than bill you for a platform you did not need.
EKS or self-managed Kubernetes?
For almost everyone, EKS. Running your own control plane means owning etcd backups, certificate rotation, API server availability and control-plane upgrades for a component that is not differentiating and fails badly when it fails. Self-managed makes sense in narrow cases: air-gapped or strict data-residency environments, bare-metal economics at large scale, or a need for API server flags EKS does not expose. Worth being clear about what EKS actually gives you, though — a managed control plane, not a platform. CNI choice, autoscaling, policy, delivery and upgrades are still yours.
How do you reduce cluster cost without causing downtime?
By changing the safe things first and watching each one. Requests are usually the biggest lever, and changing them is a rolling update — the same mechanism you already ship with, run behind PodDisruptionBudgets. Then idle and orphaned resources, then node consolidation, then spot for workloads that tolerate interruption. Node migrations use surge capacity: new nodes join, pods drain onto them, old nodes leave. We do not tighten limits on latency-sensitive services without load evidence, and we watch error rates and p99 through each change rather than after all of them.
Karpenter or Cluster Autoscaler?
Karpenter provisions instances directly from EC2 instead of adjusting an Auto Scaling group, so nodes arrive faster and it is free to choose whatever instance type actually fits the pending pods — which is where most of the saving comes from. Consolidation then replaces underused nodes with cheaper ones, something Cluster Autoscaler cannot do; it can only remove a node it has decided is unneeded. The trade is another controller, its CRDs and an interruption queue to keep healthy, plus API changes across major versions. If your pod shapes are uniform and your node groups are stable, Cluster Autoscaler is fine and switching is not worth the churn. If your shapes vary or you want serious spot usage, Karpenter usually pays for itself quickly.
How do you handle Kubernetes version upgrades?
Deprecated APIs first. We scan manifests and charts and check what the API server is actually being asked for through its deprecated-API metrics, because the thing that breaks an upgrade is almost always a chart nobody has touched in two years. Then the add-on compatibility matrix — CNI, CoreDNS, kube-proxy, CSI drivers, ingress controller. Then the control plane, one minor version at a time, since Kubernetes does not support skipping. Then nodes, via a new node group with workloads drained across rather than upgraded in place, so rollback is still possible. On EKS there is also a financial deadline: once a version leaves standard support you pay a premium per cluster hour to stay on it, which is usually what finally gets the upgrade scheduled.
Can you work alongside our existing platform team?
That is the normal shape of these engagements. Most of the teams we work with are perfectly capable and simply out of hours in the day, so we take a defined slice — the Karpenter migration, the multi-tenancy hardening, the upgrade — and work in their repositories, their review process and their conventions. We are not trying to own your platform. We are trying to leave your team with something they would have built themselves given a free quarter.
How long does a Kubernetes engagement take?
A cluster audit with a written findings document is one to two weeks. A focused piece of work — autoscaling migration, cost attribution, multi-tenancy hardening — is typically three to six weeks. A full programme covering audit, right-sizing, autoscaling, guardrails and a supervised upgrade usually runs eight to twelve. The variable is rarely the Kubernetes work itself; it is how much of the estate is undocumented and how many teams have to agree before something changes.
Do you work with companies in the US, UK and EU?
Yes — most of our Kubernetes work is with engineering teams in the US, UK and EU. We overlap with both US coasts and European hours, and we are used to operating inside client security reviews, DPAs and procurement. Access usually starts read-only and scoped through your own IAM, with every change arriving as a pull request in your repositories rather than as something applied by hand.
Insights

Related Articles

View all →

Not sure where your cluster is bleeding?

Tell us the shape of it — node groups, rough workload count, what version you are on, and what is worrying you. We will tell you what we would look at first, and whether it needs an engagement at all.