Managed Kubernetes: EKS, AKS, GKE

Table of Contents#

1. Why Managed Kubernetes Exists
2. The Shared Responsibility Model, Applied to Kubernetes
3. What "Managed" Actually Covers, and What It Doesn't
4. Amazon EKS — Architecture
5. EKS Compute Options: EC2 Node Groups vs Fargate
6. EKS Identity: IRSA
7. EKS Networking: The VPC CNI
8. Azure AKS — Architecture
9. AKS Identity: Azure AD Workload Identity
10. Google GKE — Architecture
11. GKE's Big Differentiator: Autopilot vs Standard
12. GKE Release Channels
13. The Three, Side by Side
14. Node Upgrades — A Genuinely Important Operational Reality
15. Choosing Between Them
16. Common Mistakes
17. Worked Practice Problems
18. Summary and What's Next

---

Why Managed Kubernetes Exists#

Parts 1-4 of this series covered Kubernetes's architecture in full — the control plane, etcd, the scheduler, networking, storage. Running all of that yourself, correctly, at high availability, is genuinely hard, ongoing operational work: keeping etcd healthy and backed up (Part 4), patching and upgrading the API server and control plane components, scaling the control plane itself under load. Managed Kubernetes services exist specifically to take that operational burden off your team — directly connecting to the toil discussion from the SRE Fundamentals series: running your own control plane is exactly the kind of repeatable, undifferentiated operational work most organizations would rather not own.

Diagram

---

The Shared Responsibility Model, Applied to Kubernetes#

This directly reuses the shared responsibility model from the DevSecOps series, now made concrete for Kubernetes specifically — genuinely one of the most commonly tested "do you actually understand managed Kubernetes" interview questions.

Diagram

The single most important, frequently-tested nuance worth stating explicitly: "managed" almost always means the CONTROL PLANE, not the WORKER NODES, and definitely not your workloads. Depending on the specific compute option chosen (covered per-provider below), you may still be fully responsible for patching, securing, and scaling the actual machines your pods run on — a genuinely common point of confusion for candidates who assume "managed Kubernetes" means "nothing to operate."

---

What "Managed" Actually Covers, and What It Doesn't#

Diagram

---

Amazon EKS — Architecture#

EKS (Elastic Kubernetes Service) runs the control plane across multiple AWS Availability Zones automatically, with AWS managing etcd and the API server's high availability entirely behind the scenes.

Diagram

Copy
# Create an EKS cluster (using eksctl, the most common CLI tool)
eksctl create cluster --name my-cluster --region us-east-1 --nodes 3

# Point kubectl at it
aws eks update-kubeconfig --name my-cluster --region us-east-1

# Now standard kubectl works exactly as covered in Parts 1-4
kubectl get nodes

Why eksctl is worth knowing by name specifically: it's the de facto standard CLI for creating and managing EKS clusters (originally a community tool, now closely associated with AWS itself), abstracting away a genuinely large amount of underlying CloudFormation/VPC/IAM setup that would otherwise need to be configured by hand.

---

EKS Compute Options: EC2 Node Groups vs Fargate#

A genuinely important, concrete architectural decision specific to EKS.

Diagram

Why this choice matters, worth stating explicitly, and directly connecting back to the resource-management discussion in Part 2: Fargate genuinely eliminates the "worker node OS patching" responsibility entirely — but it comes with real architectural constraints (DaemonSets, for instance, from Part 2, fundamentally don't fit Fargate's per-pod-isolated model) and a real cost premium. A strong interview answer weighs this explicitly, not just picks one as "obviously better."

---

EKS Identity: IRSA#

Already referenced in the DevSecOps series (Part 4) as the standard AWS workload-identity pattern — here's its full context specifically within EKS.

Diagram

IRSA (IAM Roles for Service Accounts) is exactly the workload-identity mechanism referenced in the DevSecOps series' secrets management tutorial — worth restating here as the concrete EKS-specific implementation: it lets a pod assume a real, scoped AWS IAM role, automatically, with zero long-lived AWS credentials ever stored in the cluster — directly eliminating the exact class of leak risk covered in that earlier tutorial.

Copy
apiVersion: v1
kind: ServiceAccount
metadata:
  name: checkout-service
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/checkout-s3-access

---

EKS Networking: The VPC CNI#

A genuinely distinctive, EKS-specific architectural detail worth knowing, directly extending the CNI discussion from Part 3.

Diagram

Why this is worth knowing specifically, as a genuinely important practical implication: because pods get real VPC IPs, they're directly visible to (and limited by) your VPC's own IP address capacity — a genuinely common, real operational issue at scale is running out of available VPC IP addresses for pods, something teams using an overlay-network CNI (like Calico in overlay mode) wouldn't hit in the same way. This is a real, EKS-specific capacity planning consideration (directly connecting to the Capacity Planning & Performance series) worth being aware of.

---

Azure AKS — Architecture#

AKS (Azure Kubernetes Service) follows the same fundamental managed-control-plane model, with a few Azure-specific distinctions worth knowing.

Copy
# Create an AKS cluster
az aks create --resource-group my-rg --name my-cluster --node-count 3 --generate-ssh-keys

# Point kubectl at it
az aks get-credentials --resource-group my-rg --name my-cluster

kubectl get nodes

Diagram

Why AKS's historical control-plane pricing is worth knowing as a concrete, citable fact: it's a genuinely real, practical cost differentiator often raised in "which managed Kubernetes should we use" discussions — always worth verifying current pricing directly, since cloud pricing models change, but knowing this distinction exists as a real consideration (not just "they're all basically the same") is a strong, specific interview signal.

---

AKS Identity: Azure AD Workload Identity#

The Azure-specific equivalent of EKS's IRSA — the same underlying pattern (OIDC federation, no long-lived credentials), different provider-specific name and implementation.

Copy
apiVersion: v1
kind: ServiceAccount
metadata:
  name: checkout-service
  annotations:
    azure.workload.identity/client-id: <managed-identity-client-id>

A strong, senior-level interview line, tying EKS and AKS identity together: "IRSA on EKS and Azure AD Workload Identity on AKS solve the exact same problem, the exact same way — OIDC federation between the Kubernetes ServiceAccount and the cloud provider's own IAM system, eliminating long-lived credentials entirely. The mechanism generalizes; only the provider-specific configuration differs."

---

Google GKE — Architecture#

GKE (Google Kubernetes Engine) deserves particular attention for one specific reason worth stating explicitly: Google originally created Kubernetes itself (open-sourcing it in 2014, based on internal experience running Borg, Google's own internal cluster scheduler) — GKE is often considered the most mature, most "native" managed Kubernetes offering as a direct result.

Copy
# Create a GKE cluster
gcloud container clusters create my-cluster --num-nodes 3

# Point kubectl at it
gcloud container clusters get-credentials my-cluster

kubectl get nodes

---

GKE's Big Differentiator: Autopilot vs Standard#

The single most distinctive, most commonly-tested GKE-specific architectural choice — genuinely worth understanding deeply.

Diagram

Why Autopilot is such a strong, specific thing to know about, worth stating explicitly: it directly extends the "managed vs. self-managed" spectrum from the very start of this Part one step further than EKS/AKS's standard node-group model — Autopilot removes node-level operational responsibility (patching, right-sizing, capacity planning at the node level) almost entirely, billing you for actual pod resource consumption instead of provisioned node capacity. The real tradeoff, worth naming: Autopilot enforces certain security/configuration best practices automatically (which can be a genuine feature) but also removes some low-level customization flexibility that Standard mode (or EKS/AKS) still allows.

---

GKE Release Channels#

A genuinely practical, GKE-specific feature worth knowing — directly connects to the version-upgrade discussion later in this Part.

Diagram

Why this is worth knowing as a concrete, GKE-specific concept: it directly formalizes the "how aggressively should we adopt new Kubernetes versions" decision as an explicit, named choice — rather than every team having to independently decide and manage their own upgrade cadence, GKE offers pre-defined, curated tracks matching different real risk tolerances.

---

The Three, Side by Side#

Diagram

---

Node Upgrades — A Genuinely Important Operational Reality#

Regardless of provider, worker node upgrades remain a real, non-trivial operational concern — directly connecting to the rolling-update and PodDisruptionBudget concepts from Part 2.

Diagram

Why this matters, worth stating explicitly, and directly tying back to Part 2's Deployment discussion: this "cordon and drain" node upgrade pattern relies on the exact same graceful-shutdown and readiness-probe mechanics from Parts 1-2 — a pod that doesn't handle SIGTERM properly (Linux & Networking Fundamentals series, Part 1) can be abruptly disrupted during what's supposed to be a graceful node upgrade, regardless of how automated the managed provider's upgrade tooling is. A managed control plane doesn't remove the need for your workloads to be genuinely resilient to disruption — it just automates the mechanical process around it.

---

Choosing Between Them#

Diagram

A strong, senior-level closing interview line: "In practice, the core Kubernetes API and workload behavior — everything from Parts 1-4 of this series — is genuinely consistent across all three providers, since they all run real, upstream Kubernetes. The meaningful differences are at the edges: identity/IAM integration, compute options, networking model, and pricing — I'd choose based on existing cloud investment and the SPECIFIC operational tradeoffs (like Autopilot's node-abstraction) that matter most for the workload in question, not because one is broadly 'better' at running Kubernetes itself."

---

Common Mistakes#

---

Worked Practice Problems#

Problem 1: A team chooses EKS Fargate specifically to eliminate node management, then discovers their monitoring stack requires a DaemonSet (a log-shipping agent that must run on every node). What went wrong, and what would you recommend?

Answer: Fargate's fully-serverless, per-pod-isolated model fundamentally doesn't support DaemonSets — there's no persistent, shared "node" in the traditional sense for a DaemonSet to run one copy per. This is exactly the kind of workload-compatibility check that should happen before committing to a serverless compute option, not after. Recommendation: either use EC2 managed node groups instead (accepting the node-management responsibility Fargate was meant to eliminate) for workloads that genuinely need DaemonSets, or restructure the log-shipping approach to use a sidecar container per pod instead of a cluster-wide DaemonSet (a real, common alternative pattern specifically for Fargate-based architectures), or run a hybrid cluster with both Fargate profiles for stateless app workloads and a small EC2 node group specifically for DaemonSet-requiring infrastructure.

Problem 2: An engineer stores a long-lived AWS access key as a Kubernetes Secret so their application can call S3, on an EKS cluster. What's the concrete, better alternative, and why?

Answer: Use IRSA instead — annotate the pod's ServiceAccount with the target IAM role's ARN, and EKS's built-in OIDC provider handles the credential exchange automatically, giving the pod short-lived, automatically-rotating AWS credentials with nothing long-lived ever stored in the cluster at all. This directly eliminates the exact class of risk covered in the DevSecOps series' secrets management tutorial — a leaked Kubernetes Secret containing a static AWS key remains valid indefinitely until someone notices and manually rotates it, while IRSA-issued credentials are short-lived by design and never need to be stored anywhere for an attacker to steal in the first place.

Problem 3: A company wants to minimize both cloud vendor lock-in and node-level operational burden, but is deciding between a single-cloud fully-serverless option (like GKE Autopilot) and standard node-group-based Kubernetes across multiple clouds. What tradeoff would you highlight?

Answer: Fully-serverless options like GKE Autopilot minimize node-level operational burden very effectively, but they're also the LEAST portable choice — Autopilot's specific automation and constraints are Google-specific, and moving that exact operational model to another cloud isn't a like-for-like migration. Standard node-group-based Kubernetes (EC2 node groups on EKS, VM Scale Sets on AKS, standard node pools on GKE) keeps more operational burden on the team, but since the actual workload-facing Kubernetes API surface is genuinely consistent across all three providers' standard modes, workloads themselves remain highly portable — the real tradeoff is operational-burden reduction versus multi-cloud portability, and a team can't fully maximize both simultaneously with today's provider offerings.

---

Summary and What's Next#

• Managed Kubernetes exists to remove the genuine operational toil of running your own control plane (etcd, API server HA, upgrades) — directly connecting to the toil-elimination principle from the SRE Fundamentals series.
• The shared responsibility model applies directly: the control plane is (almost) always managed, but worker nodes, RBAC, workload security, and application reliability remain your responsibility, to varying degrees depending on the specific compute option chosen.
• EKS offers EC2 node groups (more control) or Fargate (fully serverless, but with real workload constraints like no DaemonSets) and uses IRSA for workload identity, with real VPC IPs assigned to pods by default.
• AKS follows the same fundamental model, with Azure AD Workload Identity as its equivalent identity mechanism, and has historically differentiated on control-plane pricing.
• GKE, built by Kubernetes's original creator, offers Autopilot — the most fully "serverless" of the three providers' default offerings, billing per-pod rather than per-node — plus named Release Channels for explicit version-adoption risk tolerance.
• All three providers' identity mechanisms (IRSA, Azure AD Workload Identity, GKE Workload Identity) solve the exact same problem the same way: OIDC federation eliminating long-lived cloud credentials entirely, directly closing the exact risk covered in the DevSecOps series.
• Node upgrades still depend on your workloads handling graceful disruption properly (SIGTERM, readiness probes) — a managed control plane automates the mechanical upgrade process, but doesn't remove your responsibility for genuinely resilient pods.
• The right provider choice depends on existing cloud investment and specific operational tradeoffs (like node-abstraction level), not a universal "best" — the core Kubernetes behavior from Parts 1-4 is consistent across all three.

Continue to Part 6 (06-onprem-and-cluster-provisioning.md) to cover the other side of this spectrum — running Kubernetes yourself, on-premise or self-managed in the cloud, and the modern tools that make that genuinely practical.