Understanding CNI and Pod-to-Pod Communication
Container Networking Interface (CNI) is a specification that defines how container runtimes configure network interfaces. CNI plugins in Kubernetes assign IP addresses to pods and establish connectivity across multiple nodes.
How CNI Works
When you create a pod, the kubelet calls the CNI plugin to attach it to the cluster network. This process creates network namespaces, configures virtual network interfaces, and sets up routing rules. Each pod receives a unique IP address from the cluster's address space, managed by the plugin's IP Address Management (IPAM) component.
The CNI plugin ensures all pods can communicate with each other, regardless of which node they run on. This flat network model simplifies service discovery and load balancing.
Network Mechanisms
Different CNI implementations achieve connectivity through different approaches:
- Overlay networks that encapsulate traffic between nodes
- Layer 3 routing without encapsulation
- Virtual network interfaces connecting containers across hosts
Understanding these mechanisms helps you troubleshoot connectivity issues and choose appropriate plugins.
CKA Exam Expectations
The exam expects you to understand basic CNI architecture, how plugins integrate with kubelet, and the fundamental principle: all pods should reach all other pods without NAT translation.
Popular CNI Plugins and Their Characteristics
Each CNI plugin offers different performance and security features. The main options include:
Flannel
Flannel is simple and widely used. It creates an overlay network using VXLAN or UDP encapsulation. Flannel automatically manages IP subnetting and maintains a flat network across all nodes. However, it has network overhead from encapsulation and does not support Network Policies.
Calico
Calico provides networking and network policy enforcement. It uses BGP for routing without encapsulation, which offers better performance. Calico excels at implementing fine-grained security policies and is preferred in security-conscious environments.
Weave and Cilium
Weave creates a virtual network by connecting containers across hosts. It supports encryption and seamless container mobility using gossip protocol for mesh networking. Cilium is a modern, eBPF-based plugin providing advanced security policies and network observability.
Cloud-Native Options
AWS CNI integrates with Elastic Network Interfaces (ENIs) and security groups for AWS environments. Each plugin has different performance characteristics, security capabilities, and operational complexity.
For the CKA exam, understand which plugins support Network Policies (Calico and Cilium do; Flannel does not) and how to verify plugin health using kubectl describe nodes.
Network Policies and Traffic Control
Network Policies provide microsegmentation by controlling traffic flow between pods. They define ingress and egress rules, allowing you to deny traffic by default and explicitly permit required connections.
How Network Policies Work
A Network Policy uses label selectors to target pods and specifies allowed traffic sources or destinations. For example, a frontend pod might accept ingress only from ingress controller pods on port 80. Backend pods accept traffic only from frontend pods on port 5432.
Network Policies operate at layer 3 and 4, working with IP addresses and ports rather than application-level protocols.
Important Constraints
- Network Policies are namespaced resources, so policies only apply within their namespace unless using cross-namespace selectors
- Not all CNI plugins support them (Flannel does not; Calico and Cilium do)
- Default-deny policies are a security best practice
Implementation Steps
- Label your pods appropriately during deployment
- Create a default-deny policy blocking all ingress traffic
- Write specific allow policies for required communication patterns
- Test using kubectl exec for pod-to-pod connectivity
The CKA exam may ask you to create Network Policies from scratch or debug why certain traffic is blocked. Practice writing and applying policies in a test environment.
Service Networking and DNS Resolution
Services provide stable endpoints for pod communication, abstracting away the ephemeral nature of individual pods. When you create a Service, Kubernetes assigns a stable cluster IP and a DNS name in the format: servicename.namespace.svc.cluster.local.
How Services Route Traffic
The kube-proxy component on each node watches Service changes and updates routing rules using iptables, IPVS, or userspace proxying modes. When a pod queries a service by name, CoreDNS resolves it to the service's cluster IP. The cluster IP then routes traffic to selected backend pods based on endpoint records.
Service Types
- ClusterIP: Accessible only within the cluster
- NodePort: Exposes a port on every node
- LoadBalancer: Integrates with external load balancers
- ExternalName: DNS-based service discovery for external services
CKA Exam Requirements
You must understand kube-proxy modes, how to debug service endpoints using kubectl get endpoints, and how to verify DNS resolution using nslookup from within pods. Common issues include services with no endpoints (pods not matching selectors), incorrect port configurations, and DNS resolution failures. Services operate at a higher abstraction level than CNI.
Ingress Controllers and External Traffic Management
Ingress resources define HTTP and HTTPS routes to services within a cluster, enabling external traffic management at the application layer. An Ingress Controller (like NGINX, Traefik, or Istio) watches Ingress resources and configures itself accordingly.
Key Differences from Services
Unlike Services which operate at layer 3-4, Ingress Controllers provide layer 7 (application) routing. This allows host-based and path-based routing to different backend services. A basic Ingress resource specifies host rules and HTTP paths, each pointing to a backend service.
For example, an Ingress might route www.example.com/api to an api-service and www.example.com/web to a web-service. The Ingress Controller handles TLS termination, making HTTPS encryption transparent to backend services.
Setup Requirements
- Deploy an Ingress Controller (not included in default Kubernetes installations)
- Create Ingress resources with appropriate rules
- Configure DNS and external load balancers to direct traffic to the controller
Exam Expectations
The CKA exam typically includes basic Ingress creation and troubleshooting. Understand the relationship between Ingress, Services, and CNI: CNI manages pod-to-pod networking, Services provide stable endpoints, and Ingress Controllers provide external access and application-level routing.