What is managed Kubernetes, and is EKS different from Kubernetes?
Managed Kubernetes is a service in which a provider operates the Kubernetes control plane for you: the API server, etcd, the scheduler and the controllers, including their upgrades, backups and high availability. You get a Kubernetes API endpoint and run your applications against it. Amazon EKS, Google Kubernetes Engine (GKE) and Azure Kubernetes Service (AKS) are managed Kubernetes services, not different kinds of Kubernetes.
Is EKS different from Kubernetes?
No. EKS is Kubernetes run by AWS. Amazon states that EKS is certified Kubernetes-conformant, so Kubernetes manifests, Helm charts and community tools work on it without changes. The same holds for GKE and AKS.
Conformance comes from the CNCF Certified Kubernetes program, which checks that a product supports the required Kubernetes APIs. The CNCF lists over 90 certified offerings, and vendors must certify a current Kubernetes version at least once a year to stay listed. A conformant service behaves like upstream Kubernetes at the API level.
What differs between EKS and “plain” Kubernetes is everything around the API:
- Integrations. EKS maps AWS IAM identities to Kubernetes users and service accounts, creates AWS load balancers for Services and provisions EBS volumes through a storage driver. GKE and AKS do the same with their own clouds.
- Version window. Each provider decides how long it supports a Kubernetes minor version and what it charges after that. See how long Kubernetes versions are supported.
- Defaults and add-ons. The provider picks the network plugin, DNS, storage drivers and node images it supports.
A workload that uses only standard Kubernetes APIs moves between providers with little change. A workload that depends on provider-specific annotations, identity bindings or managed add-ons needs those parts rewritten. For a side-by-side look at the two largest services, see the Amazon EKS vs Google GKE comparison.
What the provider runs and what you run
| Area | Provider | You |
|---|---|---|
| Control plane | Runs the API server, etcd, scheduler and controllers, replicates them across zones on HA tiers, patches and backs them up | Use the API, choose the Kubernetes version and upgrade timing within the provider’s window |
| Nodes | Depends on the management level (see below) | Choose instance types, operating system images and upgrade timing, unless the provider manages nodes |
| Add-ons | Ships and patches a supported set, for example the network plugin and DNS | Install and maintain everything else: ingress controllers, cert-manager, operators, monitoring |
| Workloads | Nothing | Images, manifests, scaling, Secrets, RBAC, network policies and data backups |
The Kubernetes control plane is the part every managed service takes over. The other rows are where services differ most.
Three levels of management
Managed Kubernetes covers a range from “we run the control plane” to “we run the control plane and every node”.
| Level | What the provider manages | Examples |
|---|---|---|
| Control plane only | Control plane. You create, patch and replace nodes yourself. | EKS with self-managed nodes, any service with nodes you bring yourself |
| Managed node groups | Control plane, plus node creation, OS images and rolling node upgrades for groups you define | EKS managed node groups, GKE Standard node pools, AKS node pools |
| Fully managed nodes | Control plane, plus instance selection, scaling, patching and replacement of nodes | GKE Autopilot, EKS Auto Mode, AKS Automatic |
At the fully managed level, the provider also takes on parts of the operating system. AWS documents that EKS Auto Mode nodes run a locked-down image with a read-only root file system, have no SSH access and are replaced after at most 21 days. GKE Autopilot bills general-purpose workloads by the resources their Pods request rather than by node. The trade-off is less control over node configuration in exchange for less work.
The control plane and the nodes can live apart
A managed control plane does not have to sit in the same data center as its nodes. Nodes connect to the API server over the network, so a provider can run the control plane in one place and accept nodes from elsewhere. AWS offers this with EKS Hybrid Nodes, which attach on-premises machines to an EKS control plane for a per-vCPU fee. Several open source projects run many control planes as Pods in a shared management cluster, an approach covered in what hosted control planes are.
This separation matters when you want one cluster to span a cloud region and your own hardware, or when nodes run at sites with limited capacity for control plane machines.
Managed or self-managed
Self-managed Kubernetes means your team runs the control plane: certificate rotation, etcd backups, three minor version upgrades a year and the high-availability design. Managed Kubernetes removes that work in exchange for a fee and less control over the control plane. The trade-offs are covered in managed vs self-managed Kubernetes, and the bill itself in how much managed Kubernetes costs.
Managed Kubernetes on Cloudfleet
Cloudfleet Kubernetes Engine is a CNCF-conformant managed Kubernetes service in which Cloudfleet operates the control plane and nodes can run in several clouds and on-premises within one cluster. Nodes are created through node auto-provisioning in your cloud accounts or added as self-managed nodes on any Linux server. See what Cloudfleet is and the shared responsibility model for the exact split.