What "Managed" Does and Doesn't Cover
Summary
- Definition: A managed Kubernetes service (EKS, GKE, AKS) runs and upgrades the control plane for you, while your team keeps ownership of workloads, node configuration, and everything above the API.
- Insight: "Managed" moves the responsibility boundary, it does not erase it. The line sits at the Kubernetes API server, not at the application.
- Key Concepts: shared responsibility, control plane vs data plane, managed add-ons, cluster autoscaling, security in the cluster.
- When to Use: Choose managed when you want the provider to run etcd and the API server, and you accept owning nodes, RBAC, and network policy.
- Limitations/Trade-offs: You lose control-plane flag access and etcd tuning, and you gain a bill plus provider-specific defaults you must still harden.
- Related Topics: EKS, GKE, AKS specifics, cluster upgrade cadence, Pod Security Standards.
Foundations
Managed Kubernetes splits the cluster into two halves that map cleanly to a shared-responsibility model.
The control plane is the API server, scheduler, controller manager, and etcd. The provider runs, patches, and scales these components.
The data plane is your worker nodes and the pods on them. That half stays yours in almost every dimension that matters day to day.
The mental model is a horizontal line drawn at the Kubernetes API. Below it the cloud operates; above it you operate.
The provider guarantees a healthy, reachable API endpoint with an SLA (typically 99.9% for the endpoint). It does not guarantee that your Deployment is healthy.
This matters because most production incidents live above the line: a bad rollout, an OOMKilled pod, a missing NetworkPolicy, an expired certificate in your own workload.
Mechanics & Interactions
On the control-plane side, the provider runs etcd with encryption at rest, takes its backups, and handles quorum and failover across zones.
You never SSH into the API server, and you cannot pass arbitrary kube-apiserver flags. Configuration is exposed through the provider API instead (for example, enabling an OIDC issuer or audit logging).
Control-plane upgrades are provider-initiated but usually opt-in. You pick the version; the cloud performs the etcd and API rollout with no downtime to the endpoint.
Node upgrades are a different job. The control plane can move to 1.36, but your node pools stay on their prior version until you upgrade them, within the supported skew (nodes may trail the control plane by up to three minors).
On the data-plane side, nodes run containerd as the CRI runtime. Docker Engine is not the in-cluster runtime; you use Docker for building images, not for running pods.
Add-ons blur the line deliberately. Providers offer managed versions of the CNI, CoreDNS, kube-proxy, the CSI drivers, and metrics-server, patched on the provider's cadence.
You still choose whether to use the managed add-on or self-manage it, and you still own its configuration, such as CNI IP allocation or CoreDNS cache tuning.
Autoscaling spans both halves. The Horizontal Pod Autoscaler is yours; node autoscaling (Cluster Autoscaler or Karpenter) provisions the nodes the provider then bills.
Advanced Considerations & Applications
Security is the sharpest edge of the boundary. The provider secures the control plane, but pod-to-pod traffic is wide open until you apply a default-deny NetworkPolicy.
Pod Security Standards are not enforced for you. You enable the restricted profile, run non-root images, and drop capabilities yourself.
Identity is a hybrid. The cloud gives you a federation mechanism (IRSA or EKS Pod Identity, GKE Workload Identity, AKS Microsoft Entra Workload ID), but you must annotate ServiceAccounts and scope IAM roles.
Backups reveal a common gap. Managed etcd is backed up by the provider, but that protects cluster state, not your application's PersistentVolumes or your Namespace YAML.
You still run Velero or an equivalent for workload and PV backups. Losing a cluster and rebuilding from GitOps is a plan you own.
Node images are shared responsibility too. The provider publishes hardened, patched node images, but you decide the upgrade cadence and whether to add Karpenter for faster replacement.
Fully serverless modes shift the line further. EKS Fargate and GKE Autopilot remove node management, so the provider owns node security and right-sizing, but you accept per-pod pricing and reduced DaemonSet and privileged-workload support.
Common Misconceptions
"Managed means the provider keeps my apps up." No. The SLA covers the API endpoint, not your Deployments or their availability.
"I don't need backups because etcd is managed." Etcd backup protects cluster metadata only. Application data on PersistentVolumes and your manifests are still your job.
"Managed clusters are secure by default." The control plane is hardened, but pod security, RBAC, and network policy are opt-in and default-open.
"Upgrades are automatic and I can ignore them." Control-plane upgrades are usually version-pinned and opt-in, and node pools never move until you move them. Falling behind causes forced upgrades.
"Docker runs my pods in the cluster." Nodes run containerd via CRI. Docker is for building and local development only.
FAQs
Who patches the operating system on my worker nodes? The provider publishes patched node images, but you choose when node pools adopt them; serverless modes (Fargate, Autopilot) patch nodes for you.
Can I get root access to the control plane? No. You configure it only through the provider API and cannot pass custom API-server flags or touch etcd directly.
Is the control plane free? No. EKS, GKE Standard, and AKS charge an hourly cluster fee (AKS offers a free tier without a control-plane SLA); nodes and add-ons are billed separately.
Do I still need RBAC if the cloud manages identity? Yes. Cloud IAM authenticates callers, but Kubernetes RBAC authorizes what they can do inside the cluster.
What happens if my node version drifts too far from the control plane? Kubernetes supports a version skew of up to three minors for nodes; drift beyond that is unsupported and blocks control-plane upgrades until you catch up.
Does managed Kubernetes remove my need for an SRE function? No. It removes control-plane toil, but workload reliability, capacity, and incident response remain your team's responsibility.
Related
Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).