Managed Control Plane
Managed Control Plane
EKS runs the Kubernetes control plane — API server and etcd — as AWS-managed, per-hour infrastructure across three AZs; you run the data plane as managed node groups, self-managed nodes, or Fargate profiles. The default CNI is the VPC CNI, which gives every pod a real ENI IP from your subnet — great for pod-level security groups and network policy, demanding on IP capacity: a /24 fills fast once pods scale, so plan subnets with headroom (AWS requires at least eight free IPs per subnet).
Core add-ons (CoreDNS, kube-proxy, VPC CNI) are managed separately from cluster version, and the AWS CLI writes your kubeconfig via aws eks update-kubeconfig with IAM-authenticated access.
Identity and Access
Identity and Access
Kubernetes RBAC alone does not grant AWS API access. The modern pattern is IRSA (IAM Roles for Service Accounts): create an OIDC provider for the cluster's issuer, write an IAM trust policy scoped to one Kubernetes service account, and the pod's SDK picks up credentials via a projected token — no long-lived keys, no over-broad node role.
Node access itself flows through the aws-auth mechanism (now via the aws-auth ConfigMap or EKS access entries — access entries are the current API), mapping Kubernetes groups to IAM principals. Principle of least privilege here means: separate node groups for different trust levels, access entries per team, and cluster administrator access reserved for break-glass identities.
Pitfalls and Interview Focus
Pitfalls and Interview Focus
Networking failures cluster around security groups: the control plane and worker SGs must allow traffic between them (commonly 443 for API paths), and Pods reaching other AWS services depend on node SG egress plus subnet routing. Upgrades are sequential — EKS supports one minor version at a time, and control plane must lead supported node versions.
Fargate profiles cannot run DaemonSets, which surprises teams moving node-level agents (log shippers, security sidecars) — they simply have no home there. And CPU-bound work does not belong on the shared node's kubelet: use worker bottlenecks or dedicated node groups.
Interview: explain VPC CNI's IP-per-pod model, then IRSA's trust scoping — together they show you understand EKS beyond kubectl.
Quiz
1. How does the VPC CNI assign pod addresses?
2. What does IRSA provide?
3. Can EKS skip a minor version during upgrade?
Flashcards
Question
EKS responsibility split
Click to reveal answer
Answer
AWS runs API server/etcd; you run nodes, add-ons, workloads, and networking config.
Question
VPC CNI implication
Click to reveal answer
Answer
Pods get real subnet IPs — plan for IP exhaustion and SG-per-pod.
Question
IRSA
Click to reveal answer
Answer
OIDC-backed IAM role per service account — least-privilege AWS access from pods.
Question
Upgrade rule
Click to reveal answer
Answer
One minor version at a time; control plane first, then nodes.
Question
Fargate limitation
Click to reveal answer
Answer
No DaemonSets on Fargate — node-level agents need profiles or managed nodes.
Revision Notes
Key Takeaways
- 1. EKS = managed control plane + your data plane, glued by CNI and IAM
- 2. IRSA over node roles keeps pod credentials scoped
- 3. IP capacity and security groups cause most EKS networking incidents
Interview Tips
- • Explain pod networking end-to-end: ENI assignment, route tables, and security groups
- • Show least privilege with access entries + IRSA instead of "we use node roles"
Cheat Sheet
EKS: AWS-managed API/etcd, you own nodes+CNI. VPC CNI → real pod IPs (watch subnet headroom, ≥8 free IPs). IRSA via OIDC for AWS perms. Upgrades: one minor at a time, CP first. Fargate: no DaemonSets.