Do you work on our clusters or build new ones?

Both, though most engagements are the former. Existing clusters get reviewed, hardened and brought under GitOps in place, because a working production cluster is rarely worth rebuilding. New clusters get provisioned as Terraform or OpenTofu modules in your own cloud account, so there is nothing proprietary to unwind later.

Which cloud and which Kubernetes distribution?

EKS, AKS and GKE, plus self-managed clusters where that is what you have. The hardening, delivery and autoscaling work is substantially the same across all of them; what changes is the identity integration and the node management, which is where most of the provider-specific effort goes.

Will this disrupt production while it is happening?

Week one is read-only, so there is no risk to production at all. After that every change arrives as a pull request your team reviews and merges, applied to non-production first. Nothing is applied directly to a cluster by hand, which is also the end state the engagement is trying to reach.

Focused engagements are fixed-scope and fixed-price, quoted in writing after the scoping call and before any work begins. Pricing depends on cluster count, how many environments are in play and whether compliance evidence is in scope. Longer-term support afterwards is a monthly retainer, cancellable with 30 days notice.

What happens when the engagement ends?

Everything lives in your accounts, your repositories and your cloud, built with open-source and industry-standard tooling. You get the runbooks and a handover session. Some clients move onto a retainer for ongoing platform work; plenty do not, which is the intended outcome.

All services

Service · Kubernetes

Kubernetes consulting for teams already in production.

Cluster hardening, GitOps delivery, autoscaling and cost control, delivered as a fixed-scope engagement in your own repositories. Two to five weeks, depending on how many environments are in play.

Book a free scoping call Take the free assessment

A2DevOps provides Kubernetes consulting to SaaS and technology companies running production workloads on EKS, AKS, GKE or self-managed clusters. Engagements cover cluster hardening, GitOps delivery with Argo CD or Flux, autoscaling and resource sizing, observability, and cluster cost reduction. The work is delivered as an embedded engagement in the client's own cloud accounts and repositories, by one senior engineer, with no hand-off to a junior team.

The usual situation

Kubernetes rarely breaks. It calcifies.

The cluster that gets handed to me is almost never on fire. It works. It has worked for a year. What has happened instead is that the people who set it up made a series of reasonable decisions under time pressure, wrote none of them down, and left. Now every change is a small act of archaeology, so changes stop happening, and the cluster drifts further from the thing anybody understands.

That shows up in specific ways. Service accounts bound to cluster-admin because narrowing them once broke a deploy at 11pm. Network policy absent entirely, so every pod can reach every other pod and the blast radius of one compromised container is the whole namespace. Resource requests set during the first week by someone guessing, usually at two or three times real usage, which is why the cluster bill grows faster than the traffic. And deploys that work, but only when run by the one person who knows which step to skip.

None of that is a Kubernetes problem. It is an absence of guardrails, and guardrails are buildable in weeks.

How the engagement runs

Read-only first, then pull requests.

Nothing is applied to a cluster by hand, including by me. That is both how the work is done and the end state it is aiming for.

Week 1
Cluster review
A read-only pass over your clusters, manifests and pipelines. I look at what is actually deployed rather than what the docs say: RBAC bindings, network policy coverage, secret handling, resource requests against real usage, and how a change currently reaches production.
Done when: A written findings document, ranked by blast radius, with the quick wins separated from the structural work.
Weeks 2–3
Hardening and delivery
The structural work, applied in your repositories as reviewable pull requests. RBAC narrowed from cluster-admin sprawl to named roles, network policies moved from default-allow to default-deny, secrets moved out of manifests, and a GitOps controller made the only path to the cluster.
Done when: Every change arrives through a pull request, and nothing reaches the cluster by hand.
Weeks 3–5
Autoscaling, observability and handover
Requests and limits set from measured usage, horizontal and cluster autoscaling configured with policies that hold under load, and golden-signal dashboards and alerts that page for incidents rather than noise. Then the runbooks, and a working session with your engineers.
Done when: Your team can operate, debug and extend the platform without me.

Deliverables

What exists at the end that did not exist before.

Hardened clusters: RBAC scoped to named roles, default-deny network policies, no secrets in manifests
GitOps delivery with Argo CD or Flux: the cluster state is whatever the repository says it is
Horizontal and cluster autoscaling, configured from measured usage rather than defaults
Resource requests and limits derived from real consumption, with the headroom written down
Golden-signal dashboards and alerting: latency, errors, saturation, traffic
Rollback that works, tested before handover rather than during an incident
Runbooks for the failure modes your stack actually has, plus a live handover session

Evidence

The work, where you can check it.

Consulting pages are easy to write and hard to verify. These three are public.

36%

Cut from an Azure App Service Environment bill

Plans were buying memory by paying for CPU they never touched. Right-sizing to the correct SKUs saved about $9,300 a month, roughly $112,000 a year. The full numbers, including the two line items that went up, are published.

Read the breakdown

v4.21.0

Merged into the AzureRM Terraform provider

The SKUs that made that saving possible did not exist in the provider. Rather than script around the gap, the missing Isolated v2 entries were added upstream with acceptance tests, reviewed by the provider maintainers and shipped.

PR #28316

Apache-2.0

Norn, an open-source policy engine

The guardrail approach these engagements apply, written down as code you can read. Norn evaluates CEL policies against a Terraform plan before anything is applied, and reports values known only after apply as unknown rather than guessing.

How it handles unknowns

Fit

When this is worth your money, and when it is not.

A good fit if

You are running production workloads on Kubernetes and it works, but nobody is confident changing it
Deploys happen by hand, or through a pipeline only one person understands
A cluster was set up once, by someone who has since left
You need SOC 2 or ISO 27001 evidence for how changes reach production
Your cluster bill grew faster than your traffic

Not a fit if

You have no containerised workloads yet: a managed platform is cheaper and you do not need Kubernetes
You want a cluster built and handed over with no engineers to operate it afterwards
You need 24/7 on-call coverage: a solo practice cannot responsibly offer a pager rotation
You are looking for the lowest hourly rate rather than the work being done once, properly

Questions

What comes up on the call.

Do you work on our clusters or build new ones?: Both, though most engagements are the former. Existing clusters get reviewed, hardened and brought under GitOps in place, because a working production cluster is rarely worth rebuilding. New clusters get provisioned as Terraform or OpenTofu modules in your own cloud account, so there is nothing proprietary to unwind later.
Which cloud and which Kubernetes distribution?: EKS, AKS and GKE, plus self-managed clusters where that is what you have. The hardening, delivery and autoscaling work is substantially the same across all of them; what changes is the identity integration and the node management, which is where most of the provider-specific effort goes.
Will this disrupt production while it is happening?: Week one is read-only, so there is no risk to production at all. After that every change arrives as a pull request your team reviews and merges, applied to non-production first. Nothing is applied directly to a cluster by hand, which is also the end state the engagement is trying to reach.
What does it cost?: Focused engagements are fixed-scope and fixed-price, quoted in writing after the scoping call and before any work begins. Pricing depends on cluster count, how many environments are in play and whether compliance evidence is in scope. Longer-term support afterwards is a monthly retainer, cancellable with 30 days notice.
What happens when the engagement ends?: Everything lives in your accounts, your repositories and your cloud, built with open-source and industry-standard tooling. You get the runbooks and a handover session. Some clients move onto a retainer for ongoing platform work; plenty do not, which is the intended outcome.

Let's build your infrastructure roadmap.

I'll review your current stack, identify the biggest wins, and map out a plan, whether that's a long-term partnership or a focused engagement.

See where you stand, free Book a call

Not ready for a call? Drop me a line. Honest thoughts, no sales sequence.

contact@a2devops.com

I typically respond within a few hours.