Your team builds product – we tidy up the platform.

Kubernetes consulting for engineering teams: what we do differently

Kubernetes consulting for engineering teams has a bad reputation, often deservedly: someone comes in for two weeks, draws a target picture with twenty new tools, and afterwards the team is left alone with the result. We work differently. We read your code first, talk to the people who get paged at night, and then propose the smallest changes with the biggest effect. New tools only come in when they solve a concrete problem you have today.

We speak your language while doing it: manifests, pull requests, incidents, SLOs. You don't get slides – you get commits and a document your team will still understand in a year.

The review: what we look at

A review starts with read access to your repositories and clusters. We look at how deployments are created and rolled out, how access is granted, where secrets live, what the network policies look like and which versions your clusters and add-ons run. On top of that come requests and limits, node utilisation, monitoring and the question of which alerts anyone actually reads.

The result is a written report in three categories: what's good and should stay that way, what's on fire and needs tackling first, and what can wait. Every finding has a reason and a proposal for how to fix it.

Platform engineering in small steps

The report turns into a plan we work through together. Typical first steps are a clean GitOps setup with Flux in which environments and promotion are clearly defined, policies as code that catch dangerous configurations as early as the pull request, and secrets management that works without copy and paste. Later come reusable building blocks that make new services production-ready in minutes instead of days.

The order matters to us. An upgrade that's three versions overdue matters more than the prettiest internal developer platform.

Upgrades without drama

Many teams keep pushing cluster upgrades back until the provider threatens the end of support. Then a routine job becomes a project with a weekend shift. We make upgrades boring again: first we look for APIs that are removed in the target version with tools like Pluto, and check Helm charts and operators for compatibility. Then the upgrade runs in a staging environment with the same manifests as production.

In production, PodDisruptionBudgets, sensible readiness probes and enough replicas make sure nothing goes down while nodes are replaced. At the end there's a runbook your team can use to run the next upgrade itself.

Costs: requests, limits and empty nodes

For many teams, the cloud bill grows faster than the load. Usually it isn't the provider but generous requests nobody questions any more, nodes running half empty and test environments that never sleep. We measure what your workloads really need, adjust requests and limits, make sure nodes are used sensibly and switch off what nobody misses. Every change is measurable and can be rolled back.

Pairing instead of dependency

We don't want to become irreplaceable. So everything happens in your repositories, through pull requests, with reviews by your team. More complex changes are made in pairing sessions, so that at least one person on your side can follow every step. At the end there's documentation and a session in which we go through the essentials together. If you like, we stay reachable as a second opinion afterwards, billed separately.

How we build and secure clusters in general is explained on the Kubernetes consulting page. Whether a review makes sense for your team is best settled in a free first call.