Skip to content
docktionary

Clusters & cloud

Managed Kubernetes

EKS, GKE, and AKS all do the same core job: run the control plane so you don't have to. Where they differ is worth knowing before you pick one.

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

terminal
# 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-keys

Pointing kubectl at it

terminal
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 set

This 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.

gpu-nodepool-taint-example.yaml
# 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