NetworkTools
Sign In
1VPC Design2Security Groups & NACLs3Virtual Routers4Hybrid Connectivity5Cloud Load Balancing6Cloud DNS & CDN7Container Networking
← Back to Cloud Networking

Learning Objectives

  • Understand container networking models and the pod networking concept
  • Compare CNI plugins and their trade-offs
  • Design service mesh and network policies for Kubernetes

Pod Networking Model

In Kubernetes, every pod gets its own IP address. Containers within a pod share the same network namespace — they communicate via localhost. Pods on different nodes communicate directly using their pod IPs without NAT. This is the flat networking model, and it is implemented by a Container Network Interface (CNI) plugin.

How CNI Works

When a pod is scheduled to a node, the kubelet calls the CNI plugin through a binary interface. The plugin configures the pod's network namespace: it creates a virtual Ethernet pair (veth), attaches one end to the pod and the other to a bridge or other interface on the node, and assigns an IP address from the cluster's pod CIDR range.

Kubernetes Pod Networking with CNI

Node 1Node 2Pod A 10.1.1.5Pod B 10.1.1.6Pod C 10.1.2.8Pod D 10.1.2.9CNI Bridge cbr0CNI Bridge cbr0Service ClusterIP 10.100.0.1

Match each CNI plugin to its networking approach.

Hints
  • Some CNI plugins use overlays, others use direct routing
  • eBPF is a game-changer for performance and observability
  • Cloud-specific CNIs integrate tightly with the provider's networking
Left
matches to
Right
Left
matches to
Right
Left
matches to
Right
Left
matches to
Right
Left
matches to
Right
Left
matches to
Right
Attempts: 0

Network Policies

Kubernetes NetworkPolicies control which pods can communicate with each other. By default, all pods can talk to all other pods. A NetworkPolicy adds isolation — it acts as a pod-level firewall, filtering traffic based on labels, IP blocks, and ports.

NetworkPolicies are implemented by the CNI plugin. If your cluster uses Flannel, NetworkPolicies will not work — Flannel does not support them. Calico and Cilium have full NetworkPolicy support, including advanced features like DNS-based policies and cluster-wide egress controls.

Service Mesh

A service mesh (e.g., Istio, Linkerd) adds application-level networking on top of Kubernetes. Each pod gets a sidecar proxy that handles inter-service communication with mTLS encryption, traffic splitting, and observability. The mesh operates at Layer 7 and can implement advanced routing patterns like canary releases and circuit breaking.

Container-to-Cloud Connectivity

Pods often need to reach cloud services like databases or queues. The recommended approach is to use VPC endpoints (AWS PrivateLink) or Service Directory — this keeps traffic within the cloud network and avoids NAT gateways.

Which CNI plugin would you choose for a multi-cloud Kubernetes deployment requiring network policies and no overlay overhead?

What happens to pod-to-pod traffic when no NetworkPolicy is applied?

Key Takeaways

  • Every pod gets a unique IP — containers within a pod share localhost
  • CNI plugins implement the flat networking model each with different trade-offs
  • Calico for direct routing + NetworkPolicies, Flannel for simplicity, Cilium for eBPF performance
  • NetworkPolicies provide pod-level firewall rules — choose a CNI that supports them
  • Service meshes add L7 traffic management, mTLS, and observability to container networking
PreviousCloud DNS & CDN