Managed Kubernetes: EKS, AKS & GKE

You don't want to babysit a control plane

You learned Kubernetes. You can write a Deployment, expose a Service, scale a pod. Then someone says "ship it to the cloud" and reality lands: now you need an API server that never goes down, an etcd cluster you have to back up, a scheduler, a controller manager, and certificates that rotate before they expire. That is the control plane, the brain of Kubernetes, and running it yourself is a full-time job nobody asked for.

Managed Kubernetes hands that brain to your cloud provider. Amazon EKS, Azure AKS, and Google GKE all run the control plane for you, keep it patched, and back it up. You bring the worker nodes and the workloads. This article is the mental model: what "managed" really covers, who owns what, how nodes and networking fit together, how autoscaling works, and the one decision that matters most, managed Kubernetes versus serverless containers.

One sentence, then a picture in your head

Managed Kubernetes means the cloud runs and guarantees the control plane; you run the worker nodes and everything you deploy on them.

The split is the entire point, so make it concrete before we touch any YAML.

The picture: control plane, node pool, traffic, autoscaler

Here is a managed cluster end to end. The grey box on the left is what the provider runs and you never SSH into. Everything to its right is yours.

1. 1

   Create the cluster

   One CLI command provisions a managed control plane. The provider stands up the API server, etcd, and schedulers across availability zones, you get a kubeconfig back.

2. 2

   Add a node pool

   You declare a group of worker VMs (size, count, autoscaling range). These are the machines your pods actually run on, and the only compute you pay per-hour for.

3. 3

   Deploy your workload

   `kubectl apply` a Deployment. The control plane's scheduler places your pods onto nodes that have room.

4. 4

   Expose it

   A Service gives pods a stable address; an Ingress wires a cloud load balancer to it so the internet can reach your app over HTTPS.

5. 5

   Let it scale

   The Horizontal Pod Autoscaler adds replicas under load; the cluster autoscaler adds nodes when replicas have nowhere to fit.

What a managed control plane actually gives you

When people say "managed," they mean the control plane specifically. You stop owning a long list of undifferentiated, high-stakes chores:

• High availability, the API server and etcd run replicated across zones, so a single machine failure doesn't take your cluster's brain offline.
• Patching and upgrades, security patches for the control plane land automatically; you trigger Kubernetes version upgrades with a click or a flag instead of a weekend.
• etcd backups, the cluster's entire state store is backed up by the provider, so you're not the person who lost the database that holds every object.
• Certificate rotation, the internal TLS certs that let components talk to each other rotate before they expire, which is a classic self-managed outage.
• A managed endpoint, you get a single API URL and a kubeconfig; you never SSH into a master node, because there are no master nodes you can touch.

Node groups and pools: your half of the deal

The worker side is yours. A node group (EKS) or node pool (AKS, GKE) is a set of identical VMs with a min and max count. You'll usually run more than one pool: a general pool for normal services, plus a special pool for GPU jobs, spot instances, or memory-heavy workloads. Pods land on the right pool using labels, taints, and tolerations.

Because nodes are just VMs, you pay for them whether or not pods are running on them. That single fact drives most Kubernetes cost decisions, and it's the seam where serverless containers compete.

Cluster networking and ingress

Inside the cluster every pod gets its own IP and can reach every other pod, that's the flat pod network. A Service gives a changing set of pods one stable virtual address so callers don't chase moving IPs. To reach the outside world you go one level up: an Ingress maps hostnames and paths to Services and provisions a real cloud load balancer (an ALB on AWS, an Application Gateway on Azure, a Cloud Load Balancer on GCP) with TLS termination.

The mental shortcut: Service = stable address inside the cluster; Ingress = the front door from the internet. Most apps need both.

Autoscaling: pods first, then nodes

Managed Kubernetes scales at two layers, and they work as a team. The Horizontal Pod Autoscaler (HPA) watches a metric like CPU and changes the *replica count* of a Deployment. The cluster autoscaler watches for pods that can't be scheduled because no node has room, and adds *nodes* to the pool (and removes them when they sit idle).

1. Traffic rises, CPU per pod climbs past the target.
2. HPA bumps replicas from 3 to 8.
3. Three of the new pods are "Pending", no node has room.
4. Cluster autoscaler sees Pending pods and adds a node.
5. Pods schedule, traffic is served; when load drops both scale back down.

EKS vs AKS vs GKE

All three run the same upstream Kubernetes, your YAML is portable. They differ in defaults, networking model, and how much they automate. The short version: GKE is the most hands-off, EKS is the most flexible and AWS-native, AKS is the friendliest if you live in Azure.

Ship a workload to a managed cluster

Here's the full loop on EKS, create a cluster with a node pool, deploy an app, expose it, and add autoscaling. The cluster commands differ per provider (az aks create, gcloud container clusters create), but everything after kubectl is identical across all three.

# 1. Create a managed cluster with one autoscaling node pool (AWS / eksctl)
eksctl create cluster \
  --name shop \
  --region eu-west-1 \
  --nodegroup-name general \
  --node-type t3.medium \
  --nodes 3 --nodes-min 3 --nodes-max 10 --managed

# 2. Point kubectl at it (eksctl writes your kubeconfig automatically)
kubectl get nodes        # you should see 3 Ready nodes

# 3. Deploy + expose the app
kubectl apply -f app.yaml

# 4. Watch the load balancer get an external address
kubectl get ingress shop -w

The workload itself, a Deployment with resource requests, a Service, and an HPA, is plain Kubernetes and runs unchanged on any of the three:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels: { app: shop }
  template:
    metadata:
      labels: { app: shop }
    spec:
      containers:
        - name: shop
          image: ghcr.io/acme/shop:1.4.0
          ports: [{ containerPort: 8080 }]
          resources:
            requests: { cpu: 250m, memory: 256Mi }  # HPA needs this
            limits:   { cpu: 500m, memory: 512Mi }
---
apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector: { app: shop }
  ports: [{ port: 80, targetPort: 8080 }]
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: shop
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: shop
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 70 }

Verify it the same way everywhere: kubectl get hpa shop shows current vs target CPU and the live replica count, and kubectl get pods -w lets you watch new replicas appear under load. Practice these commands in the free kubectl lab before you point them at a real cluster.

What the provider manages vs what you own

This table is the line you must internalize. Anything on the right is your responsibility, the provider will not save you from a bad Deployment, an open Service, or a runaway bill.

Common mistakes that cost hours (or money)

1. No resource requests. Without them the scheduler packs nodes blindly, the HPA can't compute usage, and the cluster autoscaler can't tell when you're out of room. Set requests on every workload.
2. Expecting the cluster autoscaler to scale pods. It only adds *nodes*. If your Deployment is stuck at 3 replicas under load, you needed an HPA, not more nodes.
3. Leaving node pools oversized. Nodes bill by the hour whether idle or not. Set a sane min, enable the autoscaler, and you stop paying for empty VMs.
4. Exposing everything with a LoadBalancer Service. Each one provisions a separate cloud load balancer (and bill). Use one Ingress to fan out to many Services instead.
5. Ignoring the version treadmill. Managed control planes only support a few recent Kubernetes versions; skip upgrades too long and you're forced into a rushed multi-version jump.
6. Assuming managed means secure. The provider isolates the control plane; your RBAC, secrets, and public Services are entirely on you.

Managed Kubernetes vs serverless containers

The biggest decision isn't EKS vs GKE, it's whether you need Kubernetes at all. If you just want to run a container and forget it, serverless containers (AWS Fargate, Google Cloud Run, Azure Container Apps) give you no nodes to manage, no autoscaler to tune, and scale-to-zero billing. You give up the rich Kubernetes ecosystem, operators, service meshes, fine-grained scheduling, that you may never need.

• Reach for managed Kubernetes when you run many interdependent services, need custom networking or a service mesh, rely on the operator/Helm ecosystem, or want one portable platform across clouds.
• Reach for serverless containers when you have a handful of stateless services, want zero infrastructure to babysit, have spiky or low traffic (scale to zero), and don't need Kubernetes-specific tooling.

Full breakdown in Serverless Containers: Fargate & Cloud Run. A common, healthy pattern: start serverless, graduate to managed Kubernetes only when complexity actually demands it.

Takeaways

Where to go next

You can now reason about a managed cluster end to end. Next, get hands-on and see how these pieces behave under real load and real failure.

• Practice the commands from this article in the free kubectl lab, no cluster or credit card needed.
• Step back to fundamentals with Docker vs Kubernetes: when to use each.
• Decide if you even need a cluster: Serverless Containers: Fargate & Cloud Run.
• Take a cluster to production-grade with Kubernetes in Production.
• Put it all on a roadmap with the Cloud Engineer career path.