EKS networking with VPC CNI in AWS - Commands & Configuration

Introduction

When you run Kubernetes on AWS using EKS, your pods need to talk to each other and the internet. The VPC CNI plugin helps by assigning real AWS network addresses to pods, so they connect smoothly inside your cloud network.

When you want your Kubernetes pods to have direct IP addresses in your AWS VPC for better network performance.

When you need your pods to communicate with AWS services securely without extra network translation.

When you want to control pod networking using AWS VPC features like security groups and routing.

When you want to scale your Kubernetes cluster and keep pod networking consistent and reliable.

When you want to avoid complex overlay networks and use native AWS networking for your pods.

Config File - aws-auth-cm.yaml

aws-auth-cm.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::123456789012:role/EKSNodeRole
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
  mapAccounts: |

This ConfigMap allows your EKS worker nodes to join the cluster and use the VPC CNI plugin. The mapRoles section maps the IAM role of your nodes to Kubernetes system groups, enabling networking and pod management.

Commands

This command installs the AWS VPC CNI plugin into your EKS cluster, enabling pods to get IP addresses from your VPC.

Terminal

kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.13.3/config/v1.13/aws-k8s-cni.yaml

Expected Output

configmap/aws-node created

serviceaccount/aws-node created

clusterrole.rbac.authorization.k8s.io/aws-node created

clusterrolebinding.rbac.authorization.k8s.io/aws-node created

daemonset.apps/aws-node created

This command checks that the aws-node pods, which run the VPC CNI plugin, are running correctly in the kube-system namespace.

Terminal

kubectl get pods -n kube-system -l k8s-app=aws-node

Expected Output

NAME                      READY   STATUS    RESTARTS   AGE

aws-node-abcde             1/1     Running   0          2m

aws-node-fghij             1/1     Running   0          2m

→

-n kube-system - Specifies the namespace where the aws-node pods run

→

-l k8s-app=aws-node - Filters pods by label to show only aws-node pods

This command shows detailed information about the aws-node daemonset to verify its configuration and status.

Terminal

kubectl describe daemonset aws-node -n kube-system

Expected Output

Name:           aws-node

Namespace:      kube-system

Selector:       k8s-app=aws-node

Labels:         k8s-app=aws-node

Annotations:    <none>

Desired Number of Nodes Scheduled: 2

Current Number of Nodes Scheduled: 2

Number of Nodes Misscheduled: 0

Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed

Pod Template:

  Labels:  k8s-app=aws-node

  Containers:

   aws-node:

    Image: 602401143452.dkr.ecr.us-east-1.amazonaws.com/amazon-k8s-cni:v1.13.3

    Ports:  <none>

    Environment Variables:

      AWS_VPC_K8S_CNI_LOGLEVEL:  DEBUG

      AWS_VPC_K8S_CNI_CONFIGURE_RPFILTER:  true

    Mounts:  <none>

→

-n kube-system - Shows the daemonset in the kube-system namespace

Key Concept

If you remember nothing else from this pattern, remember: the VPC CNI plugin lets your Kubernetes pods get real AWS VPC IP addresses for fast and secure networking.

Common Mistakes

Not applying the aws-auth ConfigMap with correct IAM roles before installing the VPC CNI plugin

Without proper IAM role mapping, worker nodes cannot join the cluster or manage pod networking, causing failures.

Create and apply the aws-auth ConfigMap with the correct IAM role ARN for your worker nodes before installing the VPC CNI plugin.

Using an outdated version of the aws-k8s-cni.yaml manifest

Older versions may lack important fixes or features, leading to networking issues or incompatibility with your EKS version.

Always use the latest stable version of the aws-k8s-cni.yaml manifest from the official AWS GitHub repository.

Not verifying that aws-node pods are running after installation

If the aws-node pods are not running, pod networking will fail and your cluster will not function properly.

Run kubectl get pods -n kube-system -l k8s-app=aws-node to confirm the plugin pods are running and healthy.

Summary

Apply the aws-auth ConfigMap to map IAM roles for your EKS worker nodes.

Install the AWS VPC CNI plugin using the official aws-k8s-cni.yaml manifest.

Verify the aws-node pods are running in the kube-system namespace to ensure pod networking is active.

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