Interactive · Amazon EKS · Pod lifecycle

How a Pod gets created on EKS — one canvas, 35 steps

From kubectl apply to a Pod serving traffic. The topology below never changes — click through and watch each step light the exact component and call that fires, and where it happens.

Everything happens in one of three places. Read the colour of each step: control plane AWS-managed, off your infrastructure · worker node local processes on the node (one node shown) · AWS API a real AWS service call, off-cluster. The active hop glows; everything else dims so you always see the one thing that just happened.

EKS Pod-creation topology held fixed across 35 steps A client (kubectl) at top-left; the AWS-managed EKS control plane across the top (kube-apiserver hub, aws-iam-authenticator, RBAC, admission webhooks, etcd, kube-scheduler, and cluster controllers); a tall AWS APIs column on the right edge (STS, EC2, ECR, ELB), off-cluster; and one worker node across the bottom (kubelet, containerd/runc, VPC CNI with aws-node/ipamd, ebs-csi-node, kube-proxy, and the Pod sandbox with pause, init, app and sidecar containers). Each step lights the active component and the call it makes. kubectlapply / RS ctrl Pod objectthe live record as it is builtlives in:apiserver memory (in-flight)metadata.namecheckout-api-7f9cmetadata.namespacecheckoutspec.containerscheckout-api:v2 (app)env AWS_ROLE_ARN…:role/checkout-sa (IRSA)+ istio sidecarenvoy + init container injectedpersisted→ etcd · status: Pendingspec.nodeNameip-10-0-2-91.ec2.internalvolumesvol-0a3f1b (EBS) mountedstatus.podIP10.0.3.47 (VPC IP)initContainersmigrate: exit 0status.phaseRunningconditionsReady = trueEndpointSlice10.0.3.47:8080 added EKS control plane · AWS-managed1Submit PodReady ≠ serving traffic yet — the next steps make it reachable Worker node · your VPC (one node shown) AWS APIs · off-cluster API Server & State Admission Pipeline Scheduling & Controllers Node Runtime & Agents Pod Networking & Storage Pods / Containers Authentication & Authorization Mutating Webhooks Validating Admission Scheduler Controllers · Deployments kubelet · Node Agent Container Runtime (CRI) Pod Networking · VPC CNI + kube-proxy Storage · CSI node watch PVC GetCallerIdentity watch CreateVolume CNI ADD PullImage RegisterTargets kube-apiserverthe front door etcddesired state aws-iam-authauthN webhookaws-authARN → group RBAC authorizerauthZ Pod Identity / IRSAmutate pod Istio injectoryour namespace PodSecuritybuilt-in validate Validating webhooksOPA / Kyverno kube-schedulerfilter · score EBS CSICreateVolume EndpointsEndpointSlice CoreDNSservice DNS ALB ctrlregister STSidentity EC2volume ECRpull ELBtargets kubeletvolume mgr · probes PLEGcrash watch containerdCRI plugin runcnamespaces aws-cniveth · routes aws-node · ipamdIP pool ebs-csi-nodestage / publish kube-proxyiptables / ipvs pausenetns init containerexit 0 app containercheckout-api envoy sidecaristio

Every step, in order

The same sequence as the walk-through above — click any step to jump the diagram to it. Termination is intentionally a separate flow.

control-plane hop node-local hop AWS API call Dashed box = external / your-namespace (not AWS-managed control plane)

Sequence models a checkout-api scale-up on EKS with VPC-CNI, IRSA/Pod-Identity, an Istio sidecar, an EBS PVC (WaitForFirstConsumer), and an IP-target-mode ALB. Component names and calls are the real ones; exact ordering can shift with your admission stack, CNI, and CSI driver. Confirm against your cluster with kubectl get events, kubectl describe pod, and the kubelet / containerd logs on the node. One worker node is drawn to keep the canvas readable — the flow is identical whichever node the scheduler binds to.