What "managed" actually means
The provider runs and patches the control plane — the API server, etcd, the scheduler — and guarantees its availability. You're still responsible for worker nodes (unless you use a fully serverless mode like Fargate or GKE Autopilot), everything that runs on the cluster, and most of its network and security configuration.
The big three, briefly
- EKS (AWS) — deep integration with IAM (via IRSA, mapping Kubernetes service accounts to IAM roles), VPC networking, and EBS/EFS storage. Node groups can be managed, self-managed, or Fargate (no nodes to manage at all).
- GKE (Google Cloud) — generally the most "batteries-included" of the three; Autopilot mode removes node management entirely and bills per Pod resource request instead of per node.
- AKS (Azure) — tight integration with Azure AD for auth and Azure networking (including direct integration with Azure CNI for Pod IPs drawn straight from the VNet).
Creating a cluster
# EKS, via eksctl
eksctl create cluster --name docktionary --region us-east-1 \
--nodegroup-name workers --node-type t3.medium --nodes 3
# GKE
gcloud container clusters create docktionary \
--zone us-central1-a --num-nodes 3 --machine-type e2-medium
# AKS
az aks create --resource-group docktionary-rg --name docktionary \
--node-count 3 --node-vm-size Standard_D2s_v3 --generate-ssh-keysFine for a one-off or a quick test cluster -- anything meant to stick around is better off as Terraform (or another IaC tool) checked into the same repo as everything else, so recreating the cluster is a known, repeatable command instead of remembering which flags you used last time. The Terraform builder generates a starting point for any of the three.
Pointing kubectl at it
aws eks update-kubeconfig --name docktionary --region us-east-1
gcloud container clusters get-credentials docktionary --zone us-central1-a
az aks get-credentials --resource-group docktionary-rg --name docktionary
kubectl get nodes # same kubectl, any of the three, once kubeconfig is setThis is the payoff of Kubernetes being a standard: the manifests from every other page on this site apply unchanged, regardless of which provider's control plane is on the other end of that kubeconfig.
Node pools / node groups
Real clusters usually run more than one pool of nodes — a general-purpose pool for most workloads, maybe a memory-optimized or GPU pool for specific ones, each with its own machine type, scaling range, and taints so only the right Pods land on it.
# Taint the GPU pool so only Pods that explicitly tolerate it get scheduled there
spec:
template:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
nodeSelector:
cloud.google.com/gke-nodepool: gpu-pool