The buyer's checklist for non-lock-in Kubernetes
Most arguments against vendor lock-in on a Kubernetes platform come from a vendor. That is the weakest possible source for the claim, because the reader has no reason to trust it over any other vendor's claim.
Swiss public-sector procurement has started writing the same argument down as a binding requirement, not a sales pitch. What follows is that requirement, in plain language, so you can carry it into your own evaluation whether or not you are running a public tender.
What "no lock-in" means when a buyer, not a vendor, defines it
A Swiss public-sector container-platform tender specifies a consistent set of technical requirements for a non-lock-in Kubernetes platform. Stated generically, as Swiss public-sector procurement practice rather than that tender's own wording:
- A CNCF-certified Kubernetes distribution. Rules out a fork or a "Kubernetes-compatible" API that has not passed the conformance test suite, however close it looks on paper.
- No proprietary orchestration that alters the Kubernetes API or impedes migration away. Rules out a managed layer that adds its own controllers, CRDs or scheduling logic you would have to reimplement elsewhere to leave.
- OCI-conformant container runtimes. Rules out a runtime that only runs images built for it.
- Both horizontal pod autoscaling and cluster autoscaling. Rules out a platform that scales your pods but makes you provision and pay for worker capacity by hand, or the reverse.
- A CNI with NetworkPolicy support. Rules out network isolation that only exists as a provider-specific security group you would have to redesign on another platform.
- Pod Security Standards. Defines standard pod-security profiles that Pod Security Admission, Kubernetes's built-in mechanism, or another policy engine can enforce, rather than profiles defined by a proprietary admission scheme.
- Both Ingress and the Gateway API. Rules out routing that only works through a provider's own load balancer configuration.
- RBAC with namespace-based tenancy. Rules out identity and access control that lives outside Kubernetes and would not travel with your workloads.
- GitOps-based deployment. Rules out a deployment pipeline wired into one provider's console rather than declared as code you keep.
None of these items is exotic. Together, they are a working definition of "you can take your workloads and leave," checkable against any platform you are evaluating, including ours.
The objection this pre-empts: "then it must be dedicated hardware, and expensive"
A platform that meets this checklist is sometimes assumed to require dedicated hardware per customer, because that is the simplest way to picture strict tenant separation. Swiss public-sector procurement has also been explicit that this assumption is wrong. When a buyer in this space has asked what "separate" tenancy requires, the answer on record has been that separate resource pools on shared hardware satisfy it; dedicated hardware is not required.
The same clarification permits shared platform components, monitoring, logging, backup, key management, the management plane and deployment pipelines, across tenants, provided audit data stays tenant-scoped and encryption keys are stored separately per tenant. That is what makes a non-lock-in, standards-based platform affordable to operate: the parts that do not need isolating are not isolated, and the parts that do are.
Where this leaves you
Take the checklist into your own evaluation, whoever you are evaluating. A platform that cannot say yes to an item without qualification has at least one axis, the API, the runtime, networking, security, access control or deployment, that will not travel with you unchanged; check what that specific gap would mean for your workloads and configuration before you sign, not after.
Managed Kubernetes is built on exactly these open standards: Kubernetes-native APIs throughout, the Gateway API and Ingress for routing, Cilium for CNI, and nothing in your workloads written against an interface only we offer. See the platform comparison and sovereignty pages for how the stack holds up against the rest of the market.
Register your interest and bring your own checklist. Measure the platform against it directly, rather than against anything we say about it.