When you need a Kubernetes consultant
The signals that another YAML sprint will not fix the cluster, and what a focused engagement actually changes
The question that usually arrives too late
People rarely call because they “want Kubernetes”. They call because Kubernetes is already there, workloads are running, and every release or incident still costs more than the team can explain. Someone inherited a cluster stood up in a hurry; someone else has three environments that should match and do not; security asks for evidence that nobody can produce without a week of manual work.
The useful question is not “do we need Kubernetes?”. It is when an external Kubernetes consultant is worth it, instead of another internal sprint of patches and charts.
Signals that internal effort is no longer enough
Not every cluster needs a consultant. With one environment, a handful of services and a team that knows the perimeter, time and discipline are often enough. External help becomes economical when one of these patterns shows up.
1. Day-2 is eating day-1
The cluster is “up”, but upgrading nodes, certificates, CSI, ingress or a critical chart is a project every time. There is no repeatable path — only the person who last “did it in a way that worked”.
2. Multi-tenancy in practice, governance in name only
Shared namespaces, missing or decorative ResourceQuotas, NetworkPolicies applied in patches, test environments that can touch staging secrets. The cluster hosts several teams without an explicit isolation model. That is when trivial incidents become organisational incidents.
3. Half-finished GitOps
A GitOps tool is installed — open source or commercial, it hardly matters — yet half of the changes still go through kubectl and tickets. Desired state is not the source of truth — it is a hope. Every audit and every disaster recovery then starts from scratch.
4. Drift nobody measures
Images and charts advance at different speeds across clusters and namespaces. You know you are behind; you do not know by how much, where, or what is deprecated. That is a fleet problem, not a single-deployment problem.
5. CI that builds environments “almost like” production
Tests pass on an improvised cluster or temporary namespace without the same policies, ingress rules and limits. Differences then appear in production that CI never saw. You usually need a model for ephemeral environments or virtual clusters, not another cosmetic pipeline.
What a Kubernetes consultant does (and does not)
A good engagement does not replace the team: it shrinks the surface where the team has to improvise.
In practice I work across four planes, also described on the Kubernetes consulting page:
- Architecture and boundaries — cluster vs namespace vs virtual cluster, networking, identity, limits.
- Day-2 operations — upgrades, verified backup/restore, observability that helps during incidents.
- Delivery — coherent GitOps, test environments that resemble production, pipelines that do not lie.
- Handover — runbooks and documented decisions, so the value remains after the engagement.
What I do not do is “install an operator and leave”. If three months later only I know why that NetworkPolicy exists, the engagement failed.
Consultant, training or Platform Engineering?
Three different levers, often mixed up:
- Kubernetes consulting when the problem is the cluster (or the fleet) and you need design or remediation.
- DevOps and cloud-native training when the team already has a clear direction but lacks shared practice and language.
- Platform Engineering when the problem is not one cluster, but the fact that every team reinvents the same one.
If you recognise two or more signals above and the internal cost of incidents exceeds a few weeks of focused external work, it is worth talking. If you are still deciding whether to adopt Kubernetes at all, start with a cloud adoption and migration assessment before buying complexity.
How a typical engagement runs
- Short assessment — real path from commit to production, privileges, drift, failure points.
- Motivated priorities — not a tool wishlist; an impact/effort sequence.
- Incremental implementation — stability and observability first, then automation, then self-service.
- Close with internal ownership — decision docs and pairing, not dependency.
I work as a freelance consultant, mostly remotely, with clients in Italy and across the EU. Details, FAQ and scope live on the dedicated page: Kubernetes consulting.
If you want a second opinion on your case with no commitment, email me in a few lines: managed or self-managed, how many teams share the cluster, and which incident or constraint made you open this page.
