Kubernetes engineering
Three things bring people to this page. A cluster somebody else built and left behind. A team weighing whether to adopt one at all. And the question that decides both, which is who upgrades it and who gets woken at three in the morning.
01Capabilities
Where scheduling stops being something you do by hand
Kubernetes work sits inside DevOps consulting and cloud infrastructure engineering, always on a managed control plane (EKS, AKS or GKE) unless a hard constraint says otherwise. Nobody should be running their own control-plane database to save a licence fee. Four shapes of work, and the decision below matters more than any of them.
- Foundations
Namespaces, access and limits, decided once
Namespaces, role-based access, ingress, secrets, resource requests and limits, and cost visibility per workload. Getting this wrong is not a day-one problem. It is a month-nine problem, which is exactly why it gets skipped.
- Migration
Workloads onto the cluster one at a time
Containerized services come off virtual machines or Compose in single steps, each with its own way back. If the images are not clean yet, that work starts on Docker and does not belong here at all.
- Isolation
Tenant separation an auditor can be shown
Per-tenant boundaries through namespaces, network policy and admission control. This is a genuine strength in healthcare and fintech work, where the boundary has to be demonstrable rather than asserted.
- Takeover
Three deploy paths, an unpatched control plane, no owner
Inherited clusters look alike: a service mesh nobody can explain, deployments made three different ways, and nothing written down. We map what actually runs, remove what nothing depends on, and get you back to one path. Where the real question is whether the platform should exist in this shape, that is cloud consulting.
02Fit
When Kubernetes earns its operational rent
Kubernetes pays off once the load and the team grow into it. It is excellent at what it does, and it charges rent in operational attention every week whether or not you use the features. Below a certain load and team size a managed container service costs less to run and far less to staff. Each row is the platform call we would make for that team and load.
| Your situation | What we recommend |
|---|---|
| Dozens of services, several teams releasing independently, and one person whose job description includes the platform | Use KubernetesOn a managed control plane. This is the case it was built for, and the weekly operational cost is justified by what comes back. |
| One team, a handful of services, and traffic that does not swing wildly | A managed serviceECS with Fargate, Azure Container Apps or Cloud Run run the same Docker images with a fraction of the surface, and you keep the option to move later. |
| Nobody can name the person who will apply upgrades and read the deprecation notes | Name the owner firstUpstream ships minor versions several times a year with short support windows, so an unowned cluster becomes an unpatched one. That is worse than a boring platform. |
| The stated reason is avoiding lock-in to a single cloud | Name the second cloudPortability still leaks through load balancers, storage classes, identity and every managed data service you use. Worth it against a concrete second target, not as insurance. |
| Already on a cluster, and it hurts every week | Simplify the clusterThe fix is usually fewer moving parts inside it: one ingress, one deploy path, limits that reflect reality. Far cheaper than a new platform. |
| You want an outside verdict on a cluster somebody else built | Different serviceA quality audit. The deliverable is a written verdict rather than a proposal, so you get an outside read before committing to any change. |
Scope
We own the recommendation and everything downstream of it. That means the upgrade path, the cost profile, the failure modes, and whether your team can operate the platform after we stop. unicrew has built platforms like this since 2012. We have 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. Where a managed service is the better fit, that is the design we write down and cost for you.
Kubernetes is the right fit when you run enough services that scheduling them by hand would be a full-time job. For a handful of services, we use a managed container service instead. Either way, we agree who owns the platform first.
Oleksandr TrofimovChief Technology Officer, unicrew03Delivery
Sequencing a platform before anyone is on call
Step one is the step people want to skip, and it is the one that sets the size of everything after it.
- Decide whether you need it, in writingThe cluster design and the managed alternative side by side, with the obligations of each spelled out: who upgrades what, who is on call, what breaks at three in the morning. Both costed against your real load rather than a hypothetical one.
- Foundations before workloadsTopology, access control, ingress, secrets, observability and resource limits go in before the first real service arrives. Retrofitting network policy onto a busy cluster is a different and much worse job.
- One real workload, all the way throughA single meaningful service reaches production with monitoring, alerts and a rehearsed way back before anything follows it. Moving ten services halfway is how a team ends up operating two platforms at once.
- Hand over the operational realityRunbooks, an upgrade calendar rather than an upgrade intention, dashboards somebody will actually open, and an honest conversation about the rota. The handover is complete when it works without us. Each step goes through the same QA and test automation practice we use on our own builds.
04Stack
The control plane and the clouds it sits on
The four neighbours of a cluster decision, each with its own page if that is the call you are really making.
05Questions
Questions that decide whether you adopt one
The six that come up before anyone signs off a platform. If yours is not here, it is a good first message.
Yes, and on platform work it is often the sensible arrangement, because your people hold the operational context. Our engineers stay accountable for the platform they help build: an architect outside the delivery team reviews the platform design, and the work runs through the same QA practice as our own projects. Team extension is managed teams; the outcome is DevOps consulting.
When you have enough independently deployed services and enough teams to need scheduling and self-service, plus a named owner for the platform itself. Traffic volume is not the test, and we settle the real one in the first conversation. One team and a handful of services runs well on a managed container service, with far less to learn and far less to maintain.
Managed services cover most of the ground: containers, autoscaling, rolling deploys, load balancing, and no control plane to keep current. You give up scheduling control, the operator ecosystem, and manifests that move between clouds. Kubernetes wins where you need those specifically, and loses where you would use a tenth of the platform at full operational price. Which description fits you is worth an hour rather than a preference.
Yes, and it is a recognisable piece of work. We map what is actually deployed against what people believe is deployed, which are rarely the same list, then check control plane and node versions against their support windows and find every deploy path in use. You get the risks ranked in writing before we change anything. Sometimes the answer is to simplify, sometimes to move the workloads somewhere less demanding.
A scoping call with an engineer. For an existing cluster we ask for read access and the last few incidents, because incidents tell the truth about a platform faster than any diagram does. What comes back is written: the design or the takeover plan, what we would fix first, and what we would deliberately keep as it is. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Weighing a cluster against something smaller?
Tell us what you run, how many people sit behind it, and who owns the platform today. You get an engineer's read on it, with the cluster and the managed alternative costed side by side.