EKS networking with VPC CNI in AWS - Step-by-Step Execution

Process Flow - EKS networking with VPC CNI

Create VPC with subnets

↓

Deploy EKS Cluster

↓

Install VPC CNI Plugin

↓

Assign ENIs and IPs to Pods

↓

Pods get IPs from VPC subnet

↓

Pods communicate using VPC networking

This flow shows how an EKS cluster uses the VPC CNI plugin to assign real VPC IP addresses to pods, enabling native VPC networking.

Execution Sample

AWS

eksctl create cluster --name my-cluster --region us-west-2 --nodes 2
kubectl apply -f aws-vpc-cni.yaml
kubectl get pods -n kube-system
kubectl describe pod <pod-name>

This sequence creates an EKS cluster, installs the VPC CNI plugin, and checks pod networking details.

Process Table

Step	Action	Resource Created/Modified	Result/State Change
1	Create VPC with public and private subnets	VPC, Subnets	VPC ready with subnets for EKS
2	Create EKS cluster with nodes	EKS Cluster, EC2 Nodes	Cluster active, nodes registered
3	Install AWS VPC CNI plugin	DaemonSet aws-node	Pods get ENIs and IPs from VPC
4	Pods start with VPC IP addresses	Pod ENIs	Pods have IPs from VPC subnet range
5	Pods communicate over VPC network	Network traffic	Pod-to-pod traffic uses VPC routing
6	Check pod IP assignment	kubectl describe pod	Pod IP matches VPC subnet IP
7	Cluster scales nodes	New EC2 nodes	New nodes get ENIs, pods get IPs
8	Exit	N/A	All pods use VPC IPs, native networking enabled

💡 Pods have IPs assigned from VPC subnets, enabling native VPC networking; no further steps needed.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
VPC	None	Created with subnets	Same	Same	Same
EKS Cluster	None	Created	Same	Same	Same
Nodes	None	Created	Same	Same	Scaled as needed
VPC CNI Plugin	Not installed	Not installed	Installed as DaemonSet	Running on nodes	Running
Pod IPs	None	None	None	Assigned from VPC subnet	Assigned from VPC subnet

Key Moments - 3 Insights

Why do pods get IP addresses from the VPC subnet instead of a separate range?

Because the VPC CNI plugin assigns ENIs and IPs directly from the VPC subnets, pods use real VPC IPs, as shown in execution_table step 4.

What happens if the VPC CNI plugin is not installed?

Pods will not get VPC IPs and will use Kubernetes default networking, losing native VPC integration, as seen by the absence of step 3 and 4 in execution_table.

How does scaling nodes affect pod IP assignment?

New nodes get ENIs attached and pods on them get IPs from the VPC subnet, maintaining native networking, as shown in step 7.

Visual Quiz - 3 Questions

Look at the execution_table, at which step do pods start receiving IPs from the VPC subnet?

A Step 3

B Step 4

C Step 2

D Step 5

💡 Hint

Check the 'Result/State Change' column for when pods get IPs from VPC subnet.

According to variable_tracker, what is the state of the VPC CNI Plugin after Step 3?

A Not installed

B Running on nodes

C Installed as DaemonSet

D Scaled as needed

💡 Hint

Look at the 'VPC CNI Plugin' row under 'After Step 3' column.

If the cluster scales nodes, what happens to pod IP assignment according to execution_table?

A Pods get IPs from the VPC subnet as before

B Pods lose IPs

C Pods get IPs from a new subnet

D Pods share IPs

💡 Hint

See step 7 in execution_table about scaling nodes and pod IPs.

Concept Snapshot

EKS networking with VPC CNI:
- Pods get real VPC IPs via ENIs
- VPC CNI plugin runs as DaemonSet
- Pods use VPC routing for communication
- Enables native AWS networking features
- Scales with nodes attaching ENIs
- Requires VPC with proper subnets

Full Transcript

This visual execution shows how Amazon EKS uses the VPC CNI plugin to assign real VPC IP addresses to pods. First, a VPC with subnets is created. Then, an EKS cluster with nodes is deployed. The VPC CNI plugin is installed as a DaemonSet on the nodes. This plugin assigns Elastic Network Interfaces (ENIs) and IP addresses from the VPC subnets directly to pods. As a result, pods communicate over the native VPC network. When the cluster scales, new nodes get ENIs and pods on them receive IPs from the same VPC subnet range. This setup enables pods to have native AWS networking capabilities. The execution table and variable tracker detail each step and state change, clarifying common confusions about pod IP assignment and plugin installation.

Practice

1. What is the main purpose of the VPC CNI plugin in Amazon EKS?

easy

A. To assign VPC IP addresses directly to Kubernetes pods

B. To provide a web interface for managing EKS clusters

C. To store container images in Amazon S3

D. To monitor CPU usage of EKS nodes

Solution

1. Step 1: Understand VPC CNI role in EKS

   The VPC CNI plugin allows pods to get IP addresses from the VPC subnet, enabling direct networking.

2. Step 2: Compare options with VPC CNI function

   Options A, B, and D describe unrelated features like UI, storage, and monitoring, not networking.

3. Final Answer:

   To assign VPC IP addresses directly to Kubernetes pods -> Option A

4. Quick Check:

   VPC CNI assigns IPs to pods = C [OK]

Hint: VPC CNI = pod IPs from VPC subnet [OK]

Common Mistakes:

• Confusing VPC CNI with monitoring tools
• Thinking VPC CNI manages container images
• Assuming VPC CNI provides UI features

2. Which command correctly enables the AWS VPC CNI plugin on an existing EKS cluster named my-cluster using eksctl?

easy

A. eksctl create cluster --name my-cluster --enable-vpc-cni

B. eksctl utils update-cni --cluster my-cluster

C. aws eks enable-cni --cluster-name my-cluster

D. kubectl apply -f vpc-cni.yaml

Solution

1. Step 1: Identify eksctl command to update CNI

   The correct eksctl command to update or enable the VPC CNI plugin on an existing cluster is eksctl utils update-cni --cluster my-cluster.

2. Step 2: Eliminate incorrect commands

   eksctl create cluster --name my-cluster --enable-vpc-cni creates a new cluster, not update CNI. aws eks enable-cni --cluster-name my-cluster is invalid AWS CLI syntax. kubectl apply -f vpc-cni.yaml applies a manifest but does not enable CNI via eksctl.

3. Final Answer:

   eksctl utils update-cni --cluster my-cluster -> Option B

4. Quick Check:

   eksctl update-cni command = A [OK]

Hint: Use eksctl utils update-cni for existing clusters [OK]

Common Mistakes:

• Using create cluster instead of update-cni
• Trying invalid AWS CLI commands
• Applying manifests without eksctl update

3. Given the following pod spec snippet using AWS VPC CNI, what IP address range will the pod likely receive?

{
  "metadata": {"name": "mypod"},
  "spec": {
    "containers": [{"name": "app", "image": "nginx"}],
    "nodeSelector": {"eks.amazonaws.com/nodegroup": "group1"}
  }
}

Assuming the VPC subnet CIDR is 10.0.0.0/16 and the node group subnet is 10.0.1.0/24.

medium

A. An IP from 10.0.1.0/24 subnet

B. An IP from 192.168.0.0/16 subnet

C. An IP from 172.16.0.0/12 subnet

D. An IP from 127.0.0.1 loopback

Solution

1. Step 1: Understand VPC CNI IP assignment

   VPC CNI assigns pod IPs from the subnet of the node where the pod runs. Here, node group subnet is 10.0.1.0/24.

2. Step 2: Match pod IP range with node subnet

   Since the pod runs on a node in 10.0.1.0/24 subnet, pod IP will be from that subnet, not from unrelated ranges.

3. Final Answer:

   An IP from 10.0.1.0/24 subnet -> Option A

4. Quick Check:

   Pod IP = node subnet CIDR = B [OK]

Hint: Pod IPs come from node subnet CIDR [OK]

Common Mistakes:

• Assuming pod IPs come from unrelated subnets
• Confusing pod IP with loopback or private ranges
• Ignoring node group subnet CIDR

4. You deployed the VPC CNI plugin but pods fail to get IP addresses and remain in Pending state. What is the most likely cause?

medium

A. The EKS cluster control plane is stopped

B. The pod image is missing from the container registry

C. The VPC subnet has no available IP addresses left

D. The Kubernetes API server is overloaded

Solution

1. Step 1: Identify reason pods stay Pending with VPC CNI

   If pods cannot get IPs, a common cause is no free IPs in the VPC subnet used by nodes.

2. Step 2: Exclude unrelated causes

   Pod image missing causes image pull errors, not IP issues. Control plane stopped or API overload cause cluster-wide failures, not just IP assignment.

3. Final Answer:

   The VPC subnet has no available IP addresses left -> Option C

4. Quick Check:

   Pods Pending due to no IPs = A [OK]

Hint: No free IPs in subnet causes pod Pending [OK]

Common Mistakes:

• Blaming image pull errors for IP assignment issues
• Assuming control plane is stopped without checking
• Ignoring subnet IP exhaustion

5. You want to optimize your EKS cluster networking to support thousands of pods per node using the VPC CNI plugin. Which configuration change should you apply?

hard

A. Reduce the pod security policies to allow more pods

B. Increase the node instance type to the largest available

C. Disable the VPC CNI plugin and use Calico instead

D. Enable the 'WARM_IP_TARGET' setting to pre-allocate more IP addresses per node

Solution

1. Step 1: Understand how to scale pod IPs with VPC CNI

   The VPC CNI plugin uses environment variables like 'WARM_IP_TARGET' to keep extra IPs ready per node, allowing more pods to launch quickly.

2. Step 2: Evaluate other options

   Increasing instance size helps but does not directly increase IPs. Disabling VPC CNI changes networking model. Pod security policies do not affect IP allocation.

3. Final Answer:

   Enable the 'WARM_IP_TARGET' setting to pre-allocate more IP addresses per node -> Option D

4. Quick Check:

   WARM_IP_TARGET pre-allocates IPs = D [OK]

Hint: Use WARM_IP_TARGET to pre-allocate pod IPs [OK]

Common Mistakes:

• Thinking instance size alone increases IPs
• Confusing network plugins instead of tuning VPC CNI
• Misunderstanding pod security policies impact