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. EKS control plane · AWS-managed AWS APIs · off-cluster Worker node · your VPC (one node shown) Admission controllers · Deployments VPC CNI · aws-node Pod · sandbox POST GetCallerIdentity watch CreateVolume PullImage RegisterTargets kubectl/ RS controller kube-apiserverthe front door etcddesired state aws-iam-authauthN webhook RBAC authorizerauthZ PodSecuritybuilt-in validate Pod Identitymutating webhook Istio injectoryour namespace ValidatingOPA / Kyverno kube-schedulerfilter · score · bind EBS CSI ctrlCreateVolume Endpoint ctrlEndpointSlice CoreDNSservice DNS ALB controllerRegisterTargets STSCallerIdentity EC2CreateVolume ECRimage pull ELB / ALBtarget group kubeletvolume mgr+ probes PLEG containerdCRI plugin runccontainers aws-cniveth · routes aws-nodeIP pool ebs-csi-nodestage/publish kube-proxyiptables/ipvs pause init app sidecar

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.