Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

In this lesson, we’ll explore how pods communicate inside a Kubernetes cluster. We’ll cover key patterns and tools—from the basic network model to advanced service meshes—so you can design reliable, secure, and scalable applications.
The image outlines lesson objectives, focusing on pod-to-pod communication and exploring communication patterns and techniques.

​
Table of Contents

​
Recap: Kubernetes Network Model

Kubernetes enforces a flat, IP-per-pod network. The core principles are:
  1. Unique Pod IP
    Every Pod receives its own IP address.
  2. Local Node Traffic
    Pods on the same node communicate via localhost or the CNI bridge.
  3. Cluster-wide Reachability
    Pods on different nodes talk without NAT, thanks to the CNI (we’re using Cilium).
We use Cilium with eBPF for high-performance routing, policy enforcement, and load balancing—no IP masquerading required.
The image illustrates the Kubernetes Network Model, showing pods with unique IP addresses within nodes. It highlights the concept of assigning a unique IP to each pod.

​
Pod-to-Pod Communication on the Same Node

When pods share a node, each pod’s network interface pairs with a veth endpoint on the CNI bridge. All traffic stays local:
  • Low latency, no encapsulation
  • Direct IP routing on the bridge interface
The image illustrates a network diagram showing pod-to-pod communication on the same node, using virtual Ethernet interfaces and a CNI (Container Network Interface) bridge.

​
Pod-to-Pod Communication Across Nodes

For inter-node traffic, Cilium injects eBPF programs into the kernel to handle routing, encapsulation (if overlay is used), and policy. Traffic flows like this:
  1. Pod → veth → Cilium eBPF hook
  2. Encapsulation (if enabled)
  3. Underlay network → remote node
  4. Decapsulation → destination pod
This approach eliminates the need for traditional overlay networks and improves performance.
The image illustrates a network diagram showing pod-to-pod communication across nodes, with components like eth0, veth0, and CNI labeled.

​
Network Policies

Network Policies control traffic at the IP and port level (TCP/UDP). You can specify which pods, namespaces, or external CIDRs are allowed or denied.
FeatureDescriptionExample
PodSelectorSelect pods by labelpodSelector: matchLabels: app: frontend
NamespaceSelectorScope policy to namespacesnamespaceSelector: matchLabels: team:ops
IPBlockAllow/Deny external CIDR rangesipBlock: cidr: 172.16.0.0/16
PolicyTypesIngress, Egress, or bothpolicyTypes: ["Ingress","Egress"]
The image illustrates network policies, showing how communication between pods is managed, with some connections allowed and others blocked. It highlights the management of communication between entities like other pods, namespaces, and IP addresses.

​
Services & DNS

Kubernetes Services provide stable endpoints and built-in DNS discovery. Each Service gets a DNS A record, so clients always hit the right IP:
  • ClusterIP: Internal load-balancer
  • NodePort: Exposes port on each node
  • LoadBalancer: External cloud LB
Service TypeScopeExample Command
ClusterIPInternalkubectl expose pod nginx --port=80 --target-port=80
NodePortExternalkubectl create service nodeport nginx --port=80
LoadBalancerCloud LBskubectl apply -f loadbalancer-service.yaml
Pods also get a DNS entry of the form: 
pod-ip-address.namespace.pod.cluster.local
# e.g. 10-244-1-3.default.pod.cluster.local
Pod DNS records change on restart or rescheduling. Always prefer Service DNS names (my-service.default.svc.cluster.local) for stable discovery.
The image illustrates the role of services in Kubernetes, showing how they facilitate service discovery and DNS management, and define pod access with a stable endpoint.

​
Service Mesh

A Service Mesh (e.g., Istio, Linkerd) injects sidecar proxies into each pod. These proxies manage:
  • Traffic routing and retries
  • Mutual TLS (mTLS) encryption
  • Circuit breaking and observability
No application code changes are needed—network features are handled transparently.
The image illustrates a service mesh concept with two pods, each having a sidecar proxy, and highlights features like lightweight proxies, sidecar operation, and traffic interception.
In this lesson, we reviewed Kubernetes’ pod-to-pod connectivity patterns, network policies, Service DNS, and the power of a Service Mesh. Next, try applying these concepts in your own cluster!

​
References

Watch Video