Kubernetes already runs. Changing it is the problem.
Somebody set it up, possibly two jobs ago. It holds until it has to move, and then nobody is confident enough to move it.
The bill grows, nobody can attribute it to a team, and requests and limits were guessed once and never revisited.
Growing, unattributedNo network policy, RBAC nobody has read since it was written, secrets sitting in manifests — and someone now asking for evidence.
No evidence trailSeveral versions behind, deprecated APIs still in use, and an upgrade nobody will volunteer to run.
Falling behindEngineers spending their week on cluster maintenance rather than product, with one person who understands any of it.
Single ownerof container users now run Kubernetes in production, up from 66% in 2023 — with culture, training and security reported as the barriers, not the technology.
of teams running production Kubernetes describe their own clusters as snowflakes. If that sounds like your estate, it is the normal case rather than a failure of yours.
We build and fix clusters. Running them is a separate job.
Managed Cloud
The cloud underneath — services, workloads, and running the estate day to day.
Go to the pageKubernetes engineering
Design, build, migrate, upgrade, secure, scale and right-size clusters. Project work with a beginning and an end.
Platform Engineering
The layer above: a GitOps operating model for the whole cloud, of which the cluster is the runtime.
Go to the pageOpsHero Managed is the name of that continuous engagement, and it is what Managed Cloud sells. Buying the engineering without it is a normal outcome, not a half-sale — plenty of clients operate the result themselves.
Build it, fix it, size it, secure it
Consulting, design and build
EKS, AKS, GKE or self-hosted, written as Terraform so a cluster can be rebuilt rather than nursed — networking, nodes, ingress, storage and identity, with the design decisions written down. Plus the architecture review, for a cluster you want checked.
Implementation, migration and upgrades
Onto Kubernetes from VMs or a container service, between providers, or between distributions — including the recovery case: out of support, versions behind, deprecated APIs in use. Rehearsed in the lower environments first.
Cost and right-sizing
Requests and limits set against observed usage, not guesswork. HPA, VPA or KEDA and Karpenter or Cluster Autoscaler where each fits, spot and ARM where the workload tolerates them, and per-team spend visibility with OpenCost or Kubecost.
Shaping applications for the cluster
Done with your teams, because a well-built cluster running badly-shaped workloads still falls over: probes, resource profiles, secrets, graceful shutdown, and decisions about state and multi-tenancy.
Deployment and GitOps
Argo CD or Flux for delivery, Helm and Kustomize for packaging, progressive rollout, and a rollback that has been run. What the cluster runs is what the repository says.
Security and monitoring
RBAC, network policy with Cilium or Calico, policy as code with Kyverno or OPA Gatekeeper, image and infra scanning, secrets via External Secrets or SOPS, and SSO onto the cluster API — with Prometheus, Grafana, Loki, actionable alerts and rehearsed Velero backups.
Investigate
What is genuinely running: clusters, versions, workloads, policy, cost, and how a deploy happens today. You get a written picture of the current state and a scope in priority order — what is dangerous, what is expensive, and what can wait.
Your provider manages the control plane. Count what is left.
This is the honest version of a comparison most pages skip. EKS, AKS and GKE take real work off you — and they take one layer, not the stack.
Your cloud provider
The control plane: API server, etcd, and its availability. Managed node group plumbing where you use it. The provider does this well, and it is genuinely worth paying for.
Still yours
Upgrades and version currency. Node sizing and scaling. Networking and ingress. RBAC, network policy and admission control. Observability. Cost. Backup and restore. And every workload running on it.
What you are actually choosing between
| Option | Left as code | Upgrades as routine | Actively cuts cost | Security you can evidence | No key-person risk | Best fit when… |
|---|---|---|---|---|---|---|
| Hire a specialist | the work is genuinely continuous — then hiring is the right call. | |||||
| Generalist MSP | you only need the cluster kept alive. | |||||
| Leave it alone | nothing has broken, been audited, or been queried yet. | |||||
| OpsHero | the work comes in bursts and has to outlast us. |
Kubernetes is not right for everybody
Below roughly ten engineers, with one or two services, Kubernetes is usually the expensive way to get something a managed runtime would give you for less. We would rather say that on a page than halfway through an engagement.
Tick the ones that are true
Five quick questions. Your answers stay in your browser.
Frequently asked questions
Our cloud provider already manages Kubernetes.
Half true, and worth being precise about. Managed means the control plane. Upgrades, nodes, networking, policy, scaling, observability, cost and the workloads all remain yours — the comparison above lists them.
Can you take over clusters somebody else built?
Yes, and it is the normal case rather than an exception. An estate nobody has documented is the engagement, not a reason to be embarrassed.
How do you handle security?
By mechanism: RBAC, network policy, admission control and policy as code, image and infrastructure-code scanning, secrets kept out of manifests, and SSO onto the cluster API — each producing evidence a reviewer can check. Note that a cloud provider’s compliance certifications belong to the provider; we tell you what we implement and what it evidences.
Which platforms do you support?
EKS on AWS, AKS on Azure, GKE on Google Cloud, and self-hosted Kubernetes.
What kind of support does this include?
These are scoped engineering engagements rather than a support contract. If you want a cluster run continuously by our engineers, that is OpsHero Managed — the day-to-day engagement under Managed Cloud — and a different conversation.
Will we be locked in?
Your repositories, your accounts, your cluster — documented and reproducible. Nothing we build depends on us still being here.
Talk to a Kubernetes engineer
Not a salesperson. You will get a read on your clusters, the specific risks in them, and what the work would involve.
- A written picture of what is actually running, and what state it is in
- The risks in priority order — dangerous, expensive, and can wait
- What the work would involve, and in what sequence
- Everything delivered into your own repositories and cloud accounts