workloads and node pools but does not administer the cluster’s critical infrastructure.

The control plane consists of Kubernetes’ standard components: the API server, etcd (the datastore that stores the cluster’s state), the scheduler and the controller manager. If the control plane fails, workloads that are already running continue to operate, but the cluster can no longer be managed: no new deployments, no scaling, and no response to kubectl commands. Managed services remove responsibility for precisely this layer from engineering teams.

Why is Kubernetes difficult to operate yourself?

Kubernetes  is a container orchestration standard, not a turnkey product. Deploying a cluster without a managed layer means handling:

• version upgrades (the Kubernetes project actively supports the three most recent minor releases);
• internal TLS certificate rotation;
• high availability of the control plane across multiple nodes;
• backup and consistency of the etcd datastore;
• security patches, often under tight time constraints.

These tasks are repetitive, consume valuable engineering time, and are a frequent source of incidents when not performed correctly. Managed services are specifically designed to remove this operational burden from product teams.

Use cases: when managed Kubernetes delivers value

Kubernetes—whether managed or self-managed—becomes relevant in specific scenarios. It is not a systematic replacement for a PaaS: the two approaches address different needs.

Managed Kubernetes is well suited when:

• the architecture includes multiple interdependent services requiring fine-grained orchestration (rolling updates, resource management by namespace);
• workloads are already built for Kubernetes and delivered as Helm charts or YAML manifests;
• the team requires multi-cluster or hybrid environments (on-premises + cloud);
• operating the control plane represents a real and measurable cost for SRE or DevOps teams.

A PaaS remains a better fit when:

• the application deployment model (code push with platform-managed build and runtime) matches the way your team works;
• you want to focus on application code without managing orchestration primitives (networking, scheduling, node management);
• your applications do not require fine-grained control over workload placement or the cluster’s network topology.

Comparison table: self-managed Kubernetes vs managed Kubernetes vs PaaS

Note: here, vanilla refers to a standard Kubernetes experience, with no changes to native Kubernetes behaviour and no proprietary tooling imposed.

Common mistakes when choosing or adopting managed Kubernetes

Managed Kubernetes in Europe: which sovereignty criteria matter?

For organisations subject to the GDPR, sector-specific regulations (healthcare, public sector, defence) or data residency requirements, where the cluster is hosted is a compliance issue, not just a performance consideration.

Points to verify:

• physical location of the    datacenters (country and applicable jurisdiction);
• identity of the operator and the involvement of foreign subcontractors in the hosting chain;
• infrastructure certifications (SecNumCloud, ISO 27001, HDS, depending on the provider and the offering);
• potential access to data by non-European third parties, particularly under extraterritorial legislation.

A managed Kubernetes service operated in France by a French provider addresses these requirements without requiring additional user-side configuration. This is the approach taken by Clever Kubernetes Engine (CKE), operated end to end in France by Clever Cloud, with no foreign hyperscaler involved in the hosting chain.

Key takeaways

Managed Kubernetes is relevant when your organisation already relies on Kubernetes and maintaining the control plane represents a meaningful operational burden. It is not a universal solution: when a PaaS deployment model matches the way your team works, it often remains the most straightforward choice. For organisations with European sovereignty requirements, the choice of provider and hosting location is critical.

The key selection criteria are: vanilla compatibility (no vendor lock-in), the release policy, a clear division of responsibilities between provider and user, and the overall cost model-list price plus internal engineering costs.

FAQ

What is managed Kubernetes?

A service in which the cloud provider manages the Kubernetes control plane (provisioning, updates and availability). The user manages workloads and node pools, but not the cluster’s critical infrastructure.

What is the difference between managed Kubernetes and a PaaS?

A PaaS handles the build, deployment and execution of what you deliver (source code or a container image) without requiring you to define the underlying orchestration. Managed Kubernetes retains the standard Kubernetes interface (kubectl, Helm and YAML manifests), allowing you to manage these primitives while delegating control plane operations to the provider. These are two distinct operational models that are complementary rather than interchangeable.

Does managed Kubernetes create a risk of vendor lock-in?

It depends on the implementation. A vanilla offering (with no changes to Kubernetes’ native behaviour and no proprietary tooling imposed) allows workloads to be migrated without rewriting them. By contrast, non-standard CRDs or exclusive networking integrations can create dependency on a specific provider.

Who is responsible for what in a managed Kubernetes cluster?

The provider manages the control plane: updates, availability and patching. The user remains responsible for node pools (sizing and scaling), workloads, application security and RBAC policies.

How can I tell whether my organisation needs managed Kubernetes rather than a PaaS?

The key question is architectural complexity. If your applications require multi-service orchestration, advanced networking interactions or are already designed for Kubernetes, managed Kubernetes is appropriate. If you are deploying relatively standard services, a PaaS will usually be faster and less expensive to operate.

Managed Kubernetes in France: what sovereign options are available?

In France, several providers offer managed Kubernetes on sovereign infrastructure, including Scaleway (Kubernetes Kapsule), OVHcloud (Managed Kubernetes Service) and Clever Cloud with CKE. Beyond location, the key differentiators are the actual level of sovereignty (operator, subcontractors involved in the hosting chain), vanilla compatibility and the shared responsibility model between provider and user.