Alright, let’s get you a cluster. You could build one from scratch on a set of VMs, manually configuring kubeadm, etcd, and the control plane components. It’s a fantastic way to learn what makes Kubernetes tick, and I highly recommend doing it once. In a VM. On a rainy Sunday. With a therapist on speed dial.

For the other 364 days of the year, you’ll want a managed Kubernetes service. The big three cloud providers—Amazon, Google, and Microsoft—offer them: EKS, GKE, and AKS. Their core promise is the same: they handle the tedious, critical, and frankly terrifying job of managing the control plane (the API server, scheduler, controller manager, etc.) for you. You get a compliant, highly available Kubernetes API endpoint, and you just worry about your worker nodes and workloads. It’s the difference between building a car engine from a pile of parts and just turning the key. You still have to drive (and pay for gas), but it starts every time.

The Quick-Start Commands You’ll Actually Use

Each provider has their own CLI magic to get things rolling. The goal here is to get you to a kubectl context as fast as possible. I’ll assume you have the respective provider’s CLI (aws, gcloud, az) installed and authenticated.

For GKE (Google Kubernetes Engine): Google built Kubernetes, so GKE often feels the most native. It’s generally the fastest to provision.

gcloud container clusters create my-witty-cluster \
  --region us-central1 \
  --num-nodes 3 \
  --machine-type e2-medium

Boom. Wait a few minutes. It automatically configures your kubectl context. You’re done. See why people like this?

For EKS (Amazon Elastic Kubernetes Service): AWS had to make it… AWS-y. It’s more modular, which means more steps. You’ll need the eksctl CLI. It’s an absolute lifesaver and non-negotiable for sane EKS usage.

# First, create a basic cluster config file
cat > cluster-config.yaml <<EOF
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-verbose-cluster
  region: us-west-2
nodeGroups:
  - name: ng-1
    instanceType: t3.medium
    desiredCapacity: 3
EOF

# Now let eksctl do the heavy lifting
eksctl create cluster -f cluster-config.yaml

This takes a solid 10-15 minutes. Go make a coffee. AWS is provisioning a CloudFormation stack, VPCs, security groups, and a whole host of other resources that you’ll be billed for. The integration with IAM is powerful but also the source of 90% of “why won’t my pod do anything?!” problems.

For AKS (Azure Kubernetes Service): Azure’s offering is straightforward and integrates seamlessly with their other services, like Active Directory.

az group create --name myResourceGroup --location eastus

az aks create \
  --resource-group myResourceGroup \
  --name my-direct-cluster \
  --node-count 3 \
  --node-vm-size Standard_B2s

# This command is crucial: it gets the credentials for kubectl
az aks get-credentials --resource-group myResourceGroup --name my-direct-cluster

Note the last step! Unlike GKE, AKS won’t automatically modify your kubeconfig; you have to explicitly ask it to.

The First Thing You Must Check: Your StorageClass

This is the most common “it works on my laptop” pitfall. Out of the box, your new shiny cluster might not have a default storage provisioner for dynamic Persistent Volumes. Your stateful workloads will sit there pending forever, waiting for storage that will never come.

Check what’s available:

kubectl get storageclass

If you see a StorageClass marked as (default), you’re probably golden. If you see nothing, or no default, you need to fix it. For GKE, the standard-rwo is usually already there. For EKS, you often need to install the EBS CSI driver. For AKS, you might need to confirm the azure-disk driver is installed. Don’t worry about this just yet; just know that if your PVCs are stuck in Pending, this is the first place to look. It’s the cluster’s equivalent of “is it plugged in?”

The Reality of Networking and Security

Here’s where the providers’ personalities really shine. By default, they all lock things down pretty tightly, which is good. But “good” also means “my services can’t talk to each other.”

  • GKE loves its VPC-native clusters, meaning pods get IPs from your VPC network. It’s elegant but can quickly exhaust your IP range if you’re not careful.
  • EKS uses the CNI plugin that assigns each pod an IP from your VPC subnet. It’s powerful and granular but, again, watch your IP addresses. You’ll be configuring IAM roles for service accounts (IRSA) for any pod that needs to touch an AWS API, which is both brilliant and a bit of a headache.
  • AKS has its own CNI and integrates deeply with Azure Network Policies and Application Security Groups.

The takeaway? The default cluster network policies will likely prevent any cross-namespace or external traffic. You’ll need to understand NetworkPolicy objects to explicitly allow the traffic you want. It’s not a flaw; it’s a feature. A slightly annoying, “why can’t frontend talk to backend?!” feature.

The Golden Rule: It’s Just Kubernetes

This is the most important part. Once you’re set up, 95% of your interaction will be through kubectl and YAML manifests. A Deployment is a Deployment, whether it’s on EKS, GKE, or AKS. The API is the same. The brilliance of managed services is that they handle the undifferentiated heavy lifting of the control plane, giving you a perfect, standard Kubernetes endpoint to target. Your brilliance, and your headaches, will now almost exclusively come from what you deploy onto it.