Managed Kubernetes Overview
A managed Kubernetes service runs the control plane for you — the API server, etcd, scheduler, and controllers — so you operate only your nodes and your workloads. Almost everyone should use one; running the control plane yourself is real, ongoing work with little upside for most teams.
The whole chapter comes back to one diagram: the shared-responsibility line. Knowing exactly what the provider owns and what stays yours is what makes comparing EKS, GKE, and AKS meaningful rather than marketing.
What 'Managed' Covers
The provider takes the control plane: it runs and scales the API server, manages etcd and backs it up, applies control-plane patches, and exposes upgrades as a button or API call. The pieces that most often break or get neglected on a self-hosted cluster — etcd durability, control-plane HA, certificate rotation — become the provider's problem. This is the bulk of the operational burden removed.
What Stays Yours
Managed does not mean hands-off. You still own your worker nodes (or choose a serverless node mode), your workloads and their configuration, your networking choices (CNI, policies, ingress), storage classes, security posture (RBAC, Pod Security, secrets), and observability. "Managed control plane" is precise: the control plane is managed; the data plane and everything you deploy is yours. Teams that read "managed" as "no ops" are surprised.
| Provider runs | You run |
|---|---|
| API server, etcd, scheduler, controllers | Workloads and their config |
| Control-plane patches and HA | Worker nodes (or serverless mode) |
| Control-plane upgrades (you trigger) | Networking, storage, security, observability |
The Node Management Spectrum
Providers offer a spectrum of how much of the nodes they manage too. At one end you run node groups and patch the OS yourself; in the middle, managed node groups handle provisioning and upgrades; at the far end, serverless node modes (Fargate, GKE Autopilot) remove nodes from your view entirely — you submit Pods and the provider runs them, billing per Pod. More management means less control and usually higher per-unit cost, the familiar trade-off.
Pricing and Lock-In
Two practical concerns. Pricing differs: some providers charge a per-cluster control-plane fee, others bundle it; serverless modes bill per Pod resources rather than per node. Lock-in is real but bounded — the Kubernetes API is portable, so your manifests move between clouds, but the surrounding integrations (load balancers, IAM, storage classes, add-ons) are provider-specific. Choosing managed is choosing the provider's ecosystem around a portable core; weigh the integrations, not just the control plane.
Self-managed — you run the control plane, etcd, certs, and upgrades. Full control; substantial ongoing work.
Managed — the provider runs the control plane; you run nodes and workloads. The default for nearly everyone.
- Reading "managed" as "no operations" — nodes, networking, security, and workloads are still yours.
- Ignoring the shared-responsibility line and assuming the provider handles your RBAC or backups of app data.
- Choosing a provider on control-plane features alone, ignoring the surrounding integrations you'll depend on.
- Underestimating lock-in from provider-specific load balancers, IAM, and add-ons.
- Picking a serverless node mode without checking its constraints against your workloads.
- Use a managed control plane unless on-prem, air-gapped, or edge constraints force otherwise.
- Read the provider's shared-responsibility model and own your side deliberately.
- Choose the node-management level (self/managed groups/serverless) per workload control and cost needs.
- Keep manifests portable and isolate provider-specific integrations to ease any future move.
- Compare providers on the whole ecosystem (networking, IAM, storage, add-ons), not just the control plane.
Knowledge Check
In managed Kubernetes, what does the provider run?
- The control plane — API server, etcd, scheduler, controllers — plus its patching and HA
- Your workloads, their configuration, and the manifests that define them
- Your CNI plugin, RBAC policies, and StorageClass definitions, configured and maintained for you
- Everything end to end, including running your application code
What is a common misconception about managed Kubernetes?
- That 'managed' means no operations — nodes, networking, security, and workloads remain yours
- That the provider runs and patches the control plane for you
- That the cluster can be upgraded to newer Kubernetes versions
- That the Kubernetes API exposed is identical to a cluster you self-host with kubeadm yourself
What does choosing a serverless node mode (Fargate, Autopilot) trade away?
- Node-level control, often at higher per-unit cost, in exchange for not managing nodes
- The ability to schedule and run any containerized Pod workloads on the cluster at all
- Direct access to the Kubernetes API for submitting workloads
- Provider-run management of the cluster control plane
You got correct