Kubernetes is a container orchestrator; the cloud is where it most often runs. The term “Kubernetes cloud” therefore covers two related realities: running Kubernetes on cloud infrastructure, and relying on a managed Kubernetes service operated by a provider.
Kubernetes Is Not a Cloud
Kubernetes is an open source container orchestrator. How Kubernetes works comes down to orchestrating containers spread across a set of machines: it schedules their placement, deploys them, supervises their lifecycle, and manages their scaling and network exposure. These containers are often built with Docker, and the distinction between Kubernetes and Docker is itself a common source of confusion.
What Kubernetes does not do is provide the underlying machines, storage, and network. It needs infrastructure to run on, and that infrastructure can take several forms: physical servers (bare metal), virtual machines, a private cloud, or a public cloud. This is the layer a cloud provider supplies.
Hence a frequent confusion: comparing “Kubernetes” with “AWS”, or Kubernetes with a cloud provider in general. The two sit at different layers. A cloud provider sells infrastructure and often offers a managed Kubernetes on top of it. Kubernetes orchestrates the containers running on that infrastructure. You do not choose between Kubernetes and the cloud: you can run Kubernetes on a cloud, or use the managed Kubernetes that cloud offers.
In other words, choosing an infrastructure and choosing who operates the cluster are two separate decisions. That is what shapes the types of offerings described below.
Running Kubernetes in the Cloud: Managed or Self-Managed
Once that relationship is clear, two operating models appear. Either you install and operate Kubernetes yourself on machines rented from a cloud provider, or you use a managed service where the provider operates the control plane for you.
The control plane is the dividing line between the two. It groups the components that drive the cluster: the apiserver, etcd (the datastore that holds the cluster state), the scheduler, and the controller-manager. Operating it yourself means handling version upgrades, which the Kubernetes project requires you to keep up with since it only supports its three most recent minor versions, internal TLS certificate rotation, high availability of these components across several nodes, etcd backup and consistency, and security patches under time pressure. A managed service takes this layer off your hands: you keep control of your workloads, your node pools, and their security, but no longer administer the cluster’s critical infrastructure.
Not every need calls for a full cluster. Lighter distributions, such as K3s, exist and are worth evaluating depending on the workload and the context. And Kubernetes, managed or not, is one operating model among others. A PaaS follows a different one: you ship code, and the platform handles the build, execution, and scaling, without you having to operate an orchestrator. PaaS and Kubernetes meet different, complementary needs, and a single organization can use both.
The Three Types of Offerings for Running Kubernetes in the Cloud
Offerings fall into three types, depending on whether you operate the cluster yourself or a provider does, and, in the latter case, on whether that provider is a global hyperscaler or a European player.
Self-Managed on Cloud Infrastructure
You rent compute, storage, and network from a provider, then install and operate Kubernetes yourself. This approach gives the most complete control over the cluster and the underlying infrastructure, at the cost of the operational burden described above. It makes sense when specific infrastructure, network, or compliance constraints are not covered by the managed offerings available. It is also the approach of teams that want to keep a hand on every component of the cluster, from the container runtime to the scheduling and internal network configuration.
Managed by a Hyperscaler
The large global cloud providers offer managed Kubernetes services: Amazon EKS, Google GKE, Microsoft AKS. The provider operates the control plane, and you deploy your workloads with the standard Kubernetes tooling. These offerings are tightly integrated with each provider’s ecosystem, which is their strength when your other services already run there, and the point to watch if you ever consider moving away. Their operators, however, fall under non-European jurisdictions, including for the regions they run in Europe. These offerings therefore do not meet a European sovereignty requirement, a decisive criterion for certain sectors and certain types of data.
Managed by a European Provider
Several European providers offer managed Kubernetes on infrastructure located within the European Union. Location matters, but it does not make an offering sovereign. A datacenter sitting in Europe remains within reach of the US CLOUD Act if the company operating it answers to a foreign jurisdiction. What determines sovereignty is the legal and capital control of the operator, not where the servers sit.
On this ground, several players offer managed Kubernetes: OVHcloud (Managed Kubernetes Service) and Scaleway (Kubernetes Kapsule). Clever Cloud offers Clever Kubernetes Engine, a managed Kubernetes operated by a European company based in France. Beyond location, these offerings differ in their real level of sovereignty, which depends on the operator and its subcontracting chain, and in how well they fit the tools you already use. For a closer look, French managed Kubernetes offerings are covered in a dedicated article.
Kubernetes Cloud: Key Takeaways
“Kubernetes cloud” refers to running Kubernetes on cloud infrastructure, along with the managed services providers offer so you do not have to operate the cluster yourself. The line between self-managed and managed runs through the control plane, the layer a provider either takes on or does not. Three types of offerings then appear: self-managed on cloud infrastructure, managed by a hyperscaler, and managed by a European provider, bearing in mind that a European location alone is not enough to make an offering sovereign. Which one fits depends on your infrastructure constraints, the tooling already in place, and your requirements around data and sovereignty. It all comes down to one distinction: the cloud supplies the infrastructure, Kubernetes orchestrates what runs on it, and the managed model determines who, the provider or you, operates the cluster in between.
What remains is to work out when a managed Kubernetes makes sense and how to choose one, and to clarify what a sovereign Kubernetes really means.
FAQ
Is Kubernetes a cloud?
No. Kubernetes is a container orchestrator, not an infrastructure provider. A cloud supplies the servers, storage, and network; Kubernetes orchestrates the containers running on top of them. You can run it on a cloud, or use the managed Kubernetes service a cloud offers.
Can you run Kubernetes outside the cloud, on bare metal or on-premises?
Yes. Kubernetes is infrastructure-agnostic: it runs on physical servers, virtual machines, a private or public cloud, and on hybrid environments combining several of these. The cloud is the most common setting, not a requirement.
Are “Kubernetes cloud” and “managed Kubernetes” the same thing?
Not exactly. “Kubernetes cloud” broadly means running Kubernetes on cloud infrastructure, which covers both a cluster you operate yourself and a managed service. “Managed Kubernetes” specifically refers to the offering where a provider operates the control plane for you. Every managed Kubernetes is Kubernetes in the cloud, but the reverse is not always true.
What is the difference between Kubernetes and a cloud provider like AWS?
They operate at different layers. AWS is a cloud provider: it sells infrastructure and offers, on top of it, a managed Kubernetes (Amazon EKS). Kubernetes is the orchestrator that drives the containers on that infrastructure. Setting them against each other is like confusing the warehouse with the system that organizes what goes into it.