Moving from a laptop cluster to production. Compare self-managed against managed Kubernetes — EKS, AKS, and GKE — connect kubectl to a real cloud cluster, and know what the provider runs for you.
Why: a Kubernetes cluster has two halves — the control plane (the API server, scheduler, and the etcd database that is its brain) and the worker nodes that run your pods. Running the control plane yourself means patching, backing up etcd, and handling upgrades and high availability. A managed service runs that half for you, so you focus on workloads. For almost everyone, managed is the right default.
CONTROL PLANE (api-server, scheduler, etcd) WORKER NODES (your pods)
──────────────────────────────────────────── ───────────────────────
self-managed: you run & upgrade all of it · you run & upgrade
managed (EKS/AKS/GKE): the cloud runs it · you (or the cloud) runWhy: the big clouds each offer managed Kubernetes — Amazon EKS, Azure AKS, and Google GKE (GKE is the oldest and most automated, since Google originated Kubernetes). They differ in defaults and integrations but speak the same Kubernetes API: the manifests from every previous lesson apply unchanged. You provision the cluster with the cloud's own CLI, then use plain kubectl.
Amazon EKS ─ tightest IAM / VPC integration; provision via eksctl or Terraform
Azure AKS ─ deep Azure AD & DevOps integration
Google GKE ─ most automated (Autopilot runs nodes for you too)Why: each provider's CLI both creates the cluster and writes the connection details into your kubeconfig — the file kubectl reads to know which cluster and credentials to use. After "update-kubeconfig" (or the equivalent), kubectl points at the cloud cluster and every command works exactly as it did locally.
Amazon EKS — point kubectl at the cluster
aws eks update-kubeconfig --name prod --region eu-west-1Azure AKS
az aks get-credentials --resource-group rg --name prodGoogle GKE
gcloud container clusters get-credentials prod --region eu-west-1Why: once you have a local cluster and one or more cloud clusters, your kubeconfig holds several "contexts" — each a cluster + user + namespace. Listing and switching contexts is how you avoid the classic mistake of running a command against prod when you meant dev. Check which context you are in before anything destructive.
Which clusters do I have, and which am I pointed at?
kubectl config get-contextsSwitch to another cluster
kubectl config use-context prodSet a default namespace for the current context
kubectl config set-context --current --namespace=stagingNote: a managed cluster runs and upgrades the control plane, but the shared-responsibility line means plenty is still yours. You choose when to upgrade node pools, set requests and limits, configure RBAC and NetworkPolicies, manage Secrets properly, and watch cost. Managed Kubernetes removes the control-plane toil — not the need to operate your workloads well, which is everything in the previous lessons.
THE PROVIDER HANDLES YOU STILL OWN
────────────────────── ─────────────────────────────
control-plane uptime node-pool sizing & upgrades
etcd backups & HA requests / limits / quotas
api-server patching RBAC, NetworkPolicy, Secrets
optional node management app health, rollouts, cost