Lesson 02 — CNI Plugins

Learning Objectives

By the end of this lesson, you will be able to:

Understand what a Container Network Interface (CNI) plugin is
Learn why Kubernetes requires a CNI plugin
Understand how CNI plugins work
Explore the Amazon VPC CNI plugin
Compare Calico, Cilium, Flannel and Weave Net
Learn enterprise CNI deployment models
Understand CNI security considerations
Apply networking best practices

Why This Matters

Kubernetes schedules Pods, but it does not provide networking by itself.

When a new Pod starts, Kubernetes must answer several networking questions:

How does the Pod get an IP address?
How does it communicate with other Pods?
How does it communicate across worker nodes?
How does it reach AWS services?
How can traffic be secured?

These tasks are performed by a Container Network Interface (CNI) plugin.

Without a CNI plugin:

Pods cannot communicate.
Services will not function.
DNS will fail.
Network Policies cannot be enforced.
Kubernetes clusters become unusable.

Every Kubernetes cluster requires a CNI plugin.

What is a CNI Plugin?

A Container Network Interface (CNI) plugin is software responsible for configuring networking for Pods.

It performs tasks such as:

Assigning IP addresses
Configuring virtual interfaces
Connecting Pods to the network
Routing traffic
Enforcing network policies
Integrating with cloud networking

Think of the CNI as the networking engine of Kubernetes.

Kubernetes Networking Without a CNI

Pod Created

↓

No IP Address

↓

No Routing

↓

No Communication

↓

Application Failure

Without a CNI plugin, Pods cannot communicate with each other or the outside world.

Kubernetes Networking With a CNI

Pod Created

↓

CNI Plugin

↓

Assign IP Address

↓

Configure Network Interface

↓

Update Routing

↓

Pod Ready

The CNI plugin automatically prepares the Pod for communication.

CNI Workflow

When Kubernetes creates a Pod:

kubectl apply

↓

Scheduler

↓

Worker Node

↓

Container Runtime

↓

CNI Plugin

↓

Network Interface

↓

Pod Receives IP

↓

Application Starts

Networking is configured before the Pod begins serving traffic.

Responsibilities of a CNI Plugin

A CNI plugin is responsible for:

Pod IP allocation
Network interface creation
Route configuration
Cross-node networking
Service connectivity
DNS connectivity
Network Policy enforcement (depending on the plugin)
Cloud networking integration

These capabilities ensure workloads can communicate securely and reliably.

Popular Kubernetes CNI Plugins

CNI Plugin	Primary Use Case
Amazon VPC CNI	Amazon EKS
Calico	Security and Network Policies
Cilium	eBPF-based networking and security
Flannel	Simple overlay networking
Weave Net	Easy-to-deploy networking
Antrea	Open vSwitch-based networking

Each plugin has different strengths depending on the environment.

Amazon VPC CNI

Amazon EKS uses the Amazon VPC CNI by default.

Architecture:

Amazon VPC

↓

Elastic Network Interface (ENI)

↓

Worker Node

↓

Pod IP Address

Unlike overlay networks, Pods receive real IP addresses from the VPC subnet.

Amazon VPC CNI Features

The Amazon VPC CNI provides:

Native AWS networking
VPC IP addresses for Pods
High performance
Low latency
Security Group integration
Direct communication with AWS services
Native routing

This makes it the preferred choice for Amazon EKS.

Amazon VPC CNI Architecture

Amazon VPC

↓

Subnet

↓

Elastic Network Interface

↓

Worker Node

↓

Pod 1

Pod 2

Pod 3

Each Pod receives a routable IP address from the VPC.

Calico

Calico is one of the most popular enterprise CNI solutions.

Key capabilities include:

Layer 3 networking
Network Policies
Global Network Policies
BGP routing
IP-in-IP encapsulation
VXLAN support
Security enforcement

Calico is widely adopted in enterprise Kubernetes environments.

Calico Architecture

Pods

↓

Calico

↓

Policy Engine

↓

Routing

↓

Cluster Network

Calico is particularly well known for its powerful network policy capabilities.

Cilium

Cilium is a modern CNI built on eBPF (Extended Berkeley Packet Filter).

Capabilities include:

High-performance networking
Layer 7 visibility
Identity-based security
Service Mesh integration
Network Policies
Observability
Load balancing

Cilium is increasingly popular in cloud-native enterprise environments.

Cilium Architecture

Pods

↓

eBPF

↓

Kernel Networking

↓

AWS Network

By operating within the Linux kernel, Cilium provides excellent performance and deep visibility into network traffic.

Flannel

Flannel is a lightweight overlay networking solution.

Features include:

Simple deployment
VXLAN networking
Basic routing
Minimal configuration

Flannel is commonly used in:

Learning environments
Development clusters
Small production deployments

It does not provide advanced security features such as Network Policy enforcement.

Weave Net

Weave Net simplifies Kubernetes networking.

Features include:

Automatic peer discovery
Overlay networking
Encrypted traffic
Easy deployment

Weave Net is often chosen for environments where operational simplicity is a priority.

CNI Comparison

Feature	Amazon VPC CNI	Calico	Cilium	Flannel	Weave Net
Amazon EKS Support	✅	✅	✅	✅	✅
Native VPC Networking	✅	❌	❌	❌	❌
Network Policies	Limited*	✅	✅	❌	Basic
eBPF Support	❌	Partial	✅	❌	❌
High Performance	✅	✅	✅	Moderate	Moderate
Enterprise Security	Good	Excellent	Excellent	Basic	Good

*Amazon VPC CNI supports Kubernetes Network Policies when used with the Amazon VPC CNI Network Policy feature, though many organisations still combine it with solutions such as Calico or Cilium for advanced policy management.

Choosing the Right CNI

Selection depends on business requirements.

Requirement	Recommended CNI
Amazon EKS	Amazon VPC CNI
Advanced Network Policies	Calico
High-performance Security	Cilium
Learning Kubernetes	Flannel
Simple Networking	Weave Net

Enterprise organisations often prioritise security, scalability and observability when selecting a CNI.

Enterprise Networking Architecture

Internet

↓

AWS WAF

↓

Application Load Balancer

↓

Amazon EKS

↓

Amazon VPC CNI

↓

Pods

↓

AWS Services

The CNI integrates Kubernetes networking with the AWS infrastructure.

Enterprise Example

A multinational retailer operates several production Amazon EKS clusters.

Networking architecture:

Amazon VPC

↓

Amazon VPC CNI

↓

Worker Nodes

↓

Frontend Pods

↓

API Pods

↓

Payment Pods

↓

Amazon RDS

↓

Amazon S3

Security controls include:

Security Groups
Network Policies
AWS WAF
AWS Shield
Amazon GuardDuty
AWS CloudTrail

This architecture delivers secure and scalable networking for business-critical applications.

Common CNI Security Risks

Cloud Security Engineers frequently identify:

Missing Network Policies
IP address exhaustion
Overlapping CIDR ranges
Misconfigured routing
Unrestricted Pod communication
Excessive Security Group permissions
CNI version vulnerabilities
Incorrect subnet configuration
Insecure overlay networking
Lack of network monitoring

These issues can lead to outages, performance problems and security incidents.

Enterprise Monitoring

Security and platform teams should monitor:

CNI health
Pod IP allocation
IP exhaustion
Routing failures
Network latency
Packet loss
Security Group changes
Network Policy violations
Cross-node communication
Plugin version updates

Continuous monitoring ensures that networking remains healthy and secure.

Best Practices

As a Kubernetes Security Engineer:

Use the Amazon VPC CNI for Amazon EKS unless there is a specific requirement for an alternative.
Keep CNI plugins updated to the latest supported version.
Plan VPC and subnet CIDR ranges carefully to avoid IP exhaustion.
Monitor CNI health and networking metrics continuously.
Implement Network Policies to restrict Pod communication.
Integrate CNI networking with AWS Security Groups where appropriate.
Regularly review routing and subnet configurations.
Test networking after cluster upgrades.
Avoid unnecessary overlay networking in Amazon EKS.
Design networking for scalability, resilience and security.

Selecting the right CNI plugin is fundamental to building a secure, high-performing Kubernetes platform.

Real-World Scenario

A company deploys a large Amazon EKS cluster with insufficient subnet capacity.

As the number of Pods increases, the Amazon VPC CNI cannot allocate additional IP addresses.

Symptoms include:

Pods stuck in the Pending state
Failed application deployments
Service outages
Scaling failures

The platform team resolves the issue by:

Expanding VPC subnet CIDR ranges
Implementing secondary CIDR blocks
Monitoring IP utilisation
Updating CNI configuration

The cluster can now scale reliably while maintaining secure networking.

Key Takeaways

After completing this lesson, you should understand:

What a Container Network Interface (CNI) plugin is
Why Kubernetes requires a CNI plugin
How Pods receive IP addresses
The responsibilities of a CNI plugin
The features of Amazon VPC CNI
The capabilities of Calico, Cilium, Flannel and Weave Net
Enterprise CNI deployment models
Common networking risks and best practices

CNI plugins provide the networking foundation for Kubernetes. Every Pod, Service, Network Policy and cloud integration depends on a correctly configured CNI. Understanding how these plugins work is essential before implementing advanced networking security controls.

Knowledge Check

Question 1

What is the primary purpose of a CNI plugin?

A. Schedule Pods
B. Provide networking for Kubernetes Pods
C. Store Kubernetes Secrets
D. Manage Deployments

Answer: B

Question 2

Which CNI plugin is used by default in Amazon EKS?

A. Calico
B. Flannel
C. Amazon VPC CNI
D. Weave Net

Answer: C

Question 3

Which CNI plugin is best known for using eBPF to provide high-performance networking and security?

A. Flannel
B. Calico
C. Cilium
D. Weave Net

Answer: C

Question 4

Which CNI plugin is commonly recognised for its advanced Network Policy capabilities?

A. Calico
B. Flannel
C. Docker Bridge
D. Host Networking

Answer: A

Question 5

What is one common networking issue that can occur when using the Amazon VPC CNI?

A. Kubernetes Secrets corruption
B. IP address exhaustion within VPC subnets
C. etcd data loss
D. API Server certificate expiration

Answer: B

What’s Next?

In the next lesson, you will learn about Network Policies, exploring how Kubernetes implements micro-segmentation, Zero Trust networking and fine-grained traffic control to restrict communication between Pods and Namespaces.

➡️ Next Lesson: Lesson 03 — Network Policies