Key takeaways

• Five delivery models all answer “yes” to “do you do Kubernetes?”. They are not selling the same thing, and three of them will be wrong for your problem.
• The deciding criterion is neither day rate nor firm size. It is who actually writes the code on your cluster, and whether that is the person you met in pre-sales.
• One question reveals incentive alignment: “what happens if we take operations back in two years?”

The market is not short of Kubernetes providers. It is short of ways to tell them apart, because five different businesses present themselves under the same phrase — “Kubernetes expertise” — and none will volunteer which one they actually are.

This guide sets out those five models, what each is really selling, and the questions that separate a pitch from a capability. It names no companies: the model is the right level of analysis, because two firms sharing a delivery model resemble each other far more than two firms sharing a headcount.
Disclosure :Edixos is a specialist cloud-native consultancy — model 3 — and also sells managed cloud operations. So we sit in two of the five models, including the one whose conflict of interest we flag. Put the same questions to us as to anyone else; we answer them at the end.

The five Kubernetes delivery models

1. The large systems integrator

The large technology consultancies, from several hundred to several thousand people, covering cloud, data, security and mobile, with framework agreements at most large enterprises.

What you are buying: capacity and contractual coverage. If you need forty people staffed next quarter, or procurement only permits pre-approved suppliers, this is the only workable model.

The trade-off : pyramid staffing. The architect who convinces you in pre-sales is not the person who writes your controllers — the margin comes precisely from that gap. On work where depth beats volume, the gap is paid in months of drift.

2. The cloud-native managed provider

Firms that build the platform and then run it, with 24/7 on-call and sometimes their own sovereign cloud.

What you are buying: the problem going away. No platform team to hire, no rotation to staff, no upgrade window to plan. For many organisations this is the right call, and it deserves saying plainly: if Kubernetes is not a strategic asset for you, operating it yourself is a cost with no return.

The trade-off: incentive alignment. A provider whose recurring revenue depends on running your platform has no economic reason to make you self-sufficient. Not bad faith — the structure of the model, and it can be contracted around. Ask directly: “contractually and technically, what happens if we want to take over operations in two years?“

3. The specialist cloud-native consultancy

Small to mid-sized firms where Kubernetes and platform engineering are the business, not one line in a catalogue of thirty expertises.

What you are buying : depth, and a handover. These teams write controllers, publish code, and work on CRDs, Crossplane, multi-tenancy and bare metal — where generalists stop. The normal deliverable is a platform your team then operates.

The trade-off: capacity. Ten people will not staff forty roles, will not clear procurement demanding three years of minimum revenue, and will not cover your security workstream in parallel. If your binding constraint is volume or process, this model wastes your time.

4. The freelancer

An independent expert, often excellent, with no overhead.

What you are buying: one precise skill, immediately. For an audit, an unblocking, or reinforcement on a team that already exists, this is frequently the best value in the market.

The trade-off: bus factor. No continuity, nobody to review the work. A control plane designed by one person without review becomes an asset you can neither evolve nor hand on. The risk is not competence — that is usually present.

5. Vendor-managed Kubernetes

GKE Autopilot, EKS, AKS, OVHcloud Managed Kubernetes, Scaleway Kapsule, with vendor support.

What you are buying: the control plane, operated by the vendor, at a cost nowhere near a human engagement. Many organisations need nothing else, and paying a consultancy for what a managed service already does is a classic procurement mistake.

The trade-off: support stops at the edge of the product. It will not design your golden path, will not write your abstractions, and will not say no to a team deploying whatever it likes. Everything that decides whether a platform gets adopted stays with you.

The decision table

This table describes models, never named companies. A single firm may sit in two models — Edixos included, which does both consulting and managed operations. When that is the case, ask which of the two carries the margin.

Seven questions to ask in pre-sales

1. “Who specifically will do the work, and can I speak to them before signing?” The one question whose answer cannot be rehearsed. A polite refusal, or “we’ll confirm staffing after signature”, is itself an answer.

2. “Show me public code.” Controllers, operators, Crossplane providers, CNCF contributions, maintained Helm charts. Real Kubernetes expertise leaves public traces; slide-deck expertise leaves none.

3. “Tell me about a production incident you caused.” An unfair question, deliberately. A team that has operated clusters has one, tells it precisely, and explains what they changed afterwards. A team without one has never been on call.

4. “What exactly is the deliverable, and what does the end of the engagement look like?” A platform engagement with no exit milestone quietly becomes open-ended staffing. Insist on the Git repository, documentation, runbooks, a handover session, and a date.

5. “What happens if we take operations back in two years?” The question that reveals alignment better than any reversibility clause.

6. “What are you not good at?” A provider claiming to cover everything has disqualified itself. Across a surface as wide as cloud-native, no admitted boundary means no actual specialism.

7. “What does the deliverable cost, not the day?” An isolated day rate informs nothing. A cheaper profile who takes three times as long costs more, and costs you a quarter on top. The full calculation is in what each model really costs.

Five red flags

• A cloud partner tier presented as Kubernetes expertise . A partnership measures resale volume, not engineering capability.

• The senior CV in the appendix, with no staffing commitment in the contract.

• No public trace at all — no repository, no talk, no technical writing, no post-mortem. In an ecosystem as open as the CNCF, that is abnormal.

• A proposal that opens with a tool — “we will deploy platform X” — before anyone has understood your golden path.

• A quote with no discovery phase. Nobody prices a Kubernetes migration without looking at what exists. An instant number means a change request is already planned.

Running the selection in three steps

1- Qualify the model before the firms. Half a day internally: do we need capacity, operations, depth, reinforcement, or just a managed cluster? This eliminates two-thirds of the market and stops you comparing offers that were never comparable.

2- Buy an audit before you buy a project. Two to five days of architecture review from two firms in the same model costs a fraction of the project and shows how they reason. It is the only test drive available.

3- Contract the exit at the start. Repository on your side, documentation as a deliverable, a dated handover session. An aligned partner agrees without argument.

Edixos against its own checklist

We are model 3: a small, senior consultancy building Kubernetes control planes, golden-path internal platforms, reusable Crossplane APIs and SRE agents. Here are our answers to the seven questions, in order

• Who will do the work? Named engineers, with their record and certifications published on the team page. From the first conversation you are talking to the person who will write the code — there is no bench behind us.

• Public code? A Crossplane provider for OVHcloud that we maintain, 15,000+ downloads, running in production for French social ministries. Sveltos fleet work, contributions to the Tilt ecosystem.

• A production incident? Our field notes on Talos and bare metal and on a stale eBPF network policy on GKE are published, causes and fixes included.

• Production tenure? Kubernetes in production since version 1.2, in 2015 — before CRDs, before managed offerings existed.

• Real systems? Over a thousand applications migrated for an automotive manufacturer, 150+ CRDs for a bespoke PaaS, self-service platforms in production.

• A clean end of engagement? Repository, documentation and runbooks yours from day one, and a dated handover session written into the contract.

• What are we not good at? Volume. We will not staff forty roles, will not clear heavyweight procurement, and for operations at very large scale on a provider’s own sovereign cloud another model will serve you better. We say so in the first meeting rather than cost you a quarter.

And to answer our own alignment question: we also sell managed operations , as Managed Cloud Operations. The conflict of interest described in model 2 therefore applies to us too. What you can verify in the contract rather than take on trust: it is contracted separately, never as the obligatory sequel to a build, and everything you need in order to do without us is yours from day one.

The lowest-risk next step is a two-to-five-day architecture review. You leave with an assessment you can act on even if you never work with us afterwards.

Frequently asked questions

What kind of Kubernetes consulting partner should I choose?
The one whose model matches your binding constraint. Need headcount: a large systems integrator. Need never to operate the platform: a managed provider. Need technical depth and autonomy afterwards: a specialist consultancy. Vendor size is not the criterion; the delivery model is.

How do I verify a partner's real Kubernetes expertise?
Ask for public code: controllers, Crossplane providers, CNCF contributions, published post-mortems. Then ask to speak to the engineer who will do the work, not the pre-sales architect. The gap between those two people is the most useful signal in the whole procurement.

What questions should I ask a Kubernetes provider before signing?
Who specifically will do the work, and can I speak to them? Where is your public code? Tell me about a production incident you caused. What exactly is the deliverable and what does the end of the engagement look like? What happens if we take operations back in two years?

Does a certified cloud partnership prove Kubernetes expertise?
No. A partner tier measures resale volume and commercial certification counts, not the ability to design a control plane or write a controller. It is a procurement signal, not an engineering one, and it is routinely presented as the second.

Specialist consultancy or vendor-managed Kubernetes?
If you need a reliable cluster and nothing more, vendor-managed is enough and costs far less than a human engagement. A consultancy earns its place when the value sits in the layer above: golden paths, abstractions, governance, and product-team autonomy.