Kubernetes on Cloud (EKS/AKS/GKE) Cheat Sheet
Compares AWS EKS, Azure AKS, and Google GKE managed Kubernetes offerings and shows cluster creation commands for each.
Managed Kubernetes Comparison
How the three major managed Kubernetes services differ.
- EKS (AWS)- Control plane fee applies; integrates with IAM, VPC CNI, and Fargate for serverless pods
- AKS (Azure)- Free control plane; deep integration with Azure AD and Azure Monitor
- GKE (Google Cloud)- Offers Autopilot mode for fully managed node operations; strong native K8s alignment (Google originated K8s)
- Node Group / Node Pool- A set of worker nodes with the same configuration, managed as a unit
- Cluster Autoscaler- Adds/removes nodes based on pending unschedulable pods and node utilization
Create an EKS Cluster (eksctl)
Fastest path to a working EKS cluster with a managed node group.
eksctl create cluster \ --name my-cluster \ --region us-east-1 \ --nodegroup-name standard-workers \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 5 \ --managed
Create an AKS Cluster (Azure CLI)
Provision a resource group and AKS cluster.
az group create --name myResourceGroup --location eastusaz aks create \ --resource-group myResourceGroup \ --name myAKSCluster \ --node-count 3 \ --enable-managed-identity \ --generate-ssh-keysaz aks get-credentials --resource-group myResourceGroup --name myAKSCluster
Create a GKE Cluster (gcloud)
Provision a standard GKE cluster.
gcloud container clusters create my-cluster \ --zone us-central1-a \ --num-nodes 3 \ --machine-type e2-mediumgcloud container clusters get-credentials my-cluster --zone us-central1-a
EKS IAM Roles for Service Accounts (IRSA)
Grant a pod fine-grained AWS permissions without static credentials by federating an IAM role to a Kubernetes ServiceAccount via the cluster's OIDC provider.
eksctl utils associate-iam-oidc-provider \ --cluster my-cluster --approveeksctl create iamserviceaccount \ --cluster my-cluster \ --namespace default \ --name s3-reader \ --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \ --approve# Reference in a pod spec:# spec.serviceAccountName: s3-reader# The pod gets short-lived STS credentials injected automatically,# scoped to exactly that IAM policy.
AKS Workload Identity Federation
AKS's equivalent of IRSA — binds a Kubernetes ServiceAccount to an Azure AD (Entra ID) application via federated credentials, avoiding secrets entirely.
az identity create -g myResourceGroup -n my-identityaz identity federated-credential create \ --name my-fed-cred \ --identity-name my-identity \ --resource-group myResourceGroup \ --issuer $(az aks show -g myResourceGroup -n myAKSCluster \ --query "oidcIssuerProfile.issuerUrl" -o tsv) \ --subject system:serviceaccount:default:my-sa \ --audience api://AzureADTokenExchange# Enable on the cluster: az aks update -g myResourceGroup -n myAKSCluster \# --enable-oidc-issuer --enable-workload-identity
GKE Workload Identity (Autopilot default)
Binds a Kubernetes ServiceAccount to a Google Cloud IAM service account so pods authenticate to GCP APIs without a downloaded key file.
gcloud iam service-accounts create gsa-readergcloud iam service-accounts add-iam-policy-binding \ gsa-reader@PROJECT_ID.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[default/ksa-reader]"kubectl annotate serviceaccount ksa-reader \ iam.gke.io/gcp-service-account=gsa-reader@PROJECT_ID.iam.gserviceaccount.com
Karpenter NodePool (EKS Autoscaling Alternative)
Karpenter provisions right-sized nodes directly against the cloud API in seconds, replacing the slower Cluster Autoscaler + fixed node group model on EKS.
apiVersion: karpenter.sh/v1kind: NodePoolmetadata: name: defaultspec: template: spec: requirements: - key: karpenter.k8s.aws/instance-category operator: In values: ["c", "m", "r"] - key: karpenter.sh/capacity-type operator: In values: ["spot", "on-demand"] nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default limits: cpu: 1000 disruption: consolidationPolicy: WhenEmptyOrUnderutilized consolidateAfter: 30s
CNI & Networking Model Differences
Each managed offering wires pod networking to the cloud VPC/VNet differently, which matters for IP planning and security policy.
- EKS default CNI- amazon-vpc-cni assigns each pod a real VPC IP from ENI secondary addresses, so pod density is limited by instance ENI/IP capacity, not just CPU/memory
- EKS prefix delegation- Enabling ENI_ENABLE_PREFIX_DELEGATION lets each ENI claim /28 IP prefixes, raising max pods per node without larger instances
- AKS network modes- 'kubenet' NATs pod traffic and conserves VNet IPs; 'Azure CNI Overlay' gives pods IPs from a private CIDR not routable in the VNet, avoiding IP exhaustion at scale
- GKE VPC-native clusters- Uses alias IP ranges so pod and service CIDRs are first-class VPC routes, enabling direct VPC peering and Cloud NAT without extra hops
- GKE Dataplane V2- eBPF-based (Cilium) dataplane replacing kube-proxy/iptables, giving built-in NetworkPolicy enforcement and better observability
- Cross-cluster consideration- Only GKE's default CNI is eBPF-native; EKS/AKS need Cilium or Calico installed separately for eBPF dataplane and L7 NetworkPolicy
Pin your cluster's Kubernetes minor version explicitly and upgrade it deliberately — managed services auto-upgrade on a forced schedule (e.g. EKS deprecates old versions), and an untracked forced upgrade can break deprecated API usage in your manifests.
