coderain guide

Introduction to Kubernetes Networking: How It Works

Kubernetes (K8s) has revolutionized how we deploy and manage containerized applications, enabling scalability, resilience, and portability. At the heart of this orchestration lies **networking**—the invisible backbone that connects pods, services, and external users. Unlike traditional networking, Kubernetes networking must handle dynamic, ephemeral containers, ensuring seamless communication across clusters, nodes, and external systems. Whether you’re running a small microservices app or a large enterprise system, understanding Kubernetes networking is critical to building reliable, secure, and high-performance applications. This blog demystifies Kubernetes networking, breaking down its core concepts, components, and workflows.

Table of Contents

  1. Understanding the Kubernetes Networking Model
  2. Key Networking Components
  3. How Pods Communicate
  4. Deep Dive: Services Explained
  5. Ingress: Beyond Services
  6. Network Policies: Microsegmentation in Action
  7. CNI Plugins: Choosing the Right Tool
  8. Advanced Concepts: DNS, Load Balancing, and Namespaces
  9. Conclusion
  10. References

1. Understanding the Kubernetes Networking Model

Kubernetes networking is designed around a set of core principles to address the dynamic nature of containers. The official Kubernetes networking model defines four key requirements:

  • Pod-to-Pod Communication: All pods in the cluster must communicate with each other without network address translation (NAT).
  • Node-to-Pod Communication: Nodes must communicate with pods, and pods must communicate with nodes.
  • Pod IP Stability: Each pod gets a unique, stable IP address. Containers within a pod share this IP.
  • Container-to-Container Communication: Containers in the same pod share a network namespace, enabling communication via localhost.

These rules eliminate the need for port mapping between containers in a pod and ensure pods can be treated as “virtual machines” with their own network identities.

2. Key Networking Components

Pods: The Fundamental Units

A pod is the smallest deployable unit in Kubernetes, consisting of one or more containers. Crucially, all containers in a pod share the same network namespace, meaning they share:

  • A single IP address.
  • Port space (containers in a pod cannot bind to the same port).
  • Loopback interface (localhost).

Pods are ephemeral—they are created, destroyed, and rescheduled frequently. This dynamism means their IP addresses are not permanent, which is why higher-level abstractions like Services are needed.

Example: Two containers in a pod (a web app and a sidecar logging container) communicate via localhost:5000 (web app) and localhost:5001 (sidecar).

Services: Stable Endpoints for Pods

A Service is a Kubernetes resource that provides a stable network endpoint for a set of pods. It abstracts the dynamic pod IPs, enabling reliable communication. Services use selectors to target pods with specific labels (e.g., app: backend).

How Services Work:

  • Endpoints: A Service automatically tracks pods matching its selector and maintains an Endpoints object (a list of pod IPs and ports).
  • kube-proxy: A daemon running on every node that manages network rules (via iptables, IPVS, or userspace mode) to forward traffic from the Service IP to the underlying pods.

Ingress: Routing External Traffic

While Services expose pods internally or via static node ports, Ingress handles external HTTP/HTTPS traffic with advanced routing (e.g., host-based or path-based routing). It acts as a “reverse proxy” for the cluster.

  • Ingress Resource: A YAML manifest defining routing rules (e.g., example.com/api → backend-service, example.com/web → frontend-service).
  • Ingress Controller: A pod (e.g., NGINX, Traefik, HAProxy) that implements the Ingress rules. Without a controller, Ingress resources are inactive.

Network Policies: Securing Traffic Flow

Network Policies enforce granular traffic rules (allow/deny) between pods, enabling microsegmentation. They use pod labels, namespace labels, CIDR blocks, and ports to define rules.

  • Default Behavior: Without Network Policies, all pods accept traffic from any source.
  • Policy Types: Ingress (incoming traffic), Egress (outgoing traffic), or both.

CNI Plugins: Implementing the Network

Kubernetes itself does not manage network infrastructure. Instead, it uses the Container Network Interface (CNI)—a standard for integrating network plugins. CNI plugins handle:

  • Assigning IP addresses to pods.
  • Setting up network routes between pods (on the same or different nodes).

Popular CNI plugins:

  • Flannel: Simple overlay network (uses VXLAN).
  • Calico: High-performance, supports Network Policies (uses BGP for routing).
  • Weave Net: Easy setup, built-in encryption.
  • Cilium: eBPF-based, optimized for Kubernetes.

3. How Pods Communicate

Same-Node Pod Communication

Pods on the same node communicate via a bridge network (e.g., cni0). The CNI plugin creates a virtual bridge on the node, and each pod connects to this bridge via a veth pair (a virtual Ethernet interface).

Flow:

  1. Pod A (IP: 10.244.1.2) sends a packet to Pod B (IP: 10.244.1.3).
  2. The packet travels from Pod A’s network namespace to the bridge (cni0).
  3. The bridge forwards the packet to Pod B’s veth interface.

Cross-Node Pod Communication

For pods on different nodes, the CNI plugin uses an overlay network (e.g., VXLAN, Geneve) or underlay network (direct L2/L3 connectivity) to route traffic.

Example with Flannel (Overlay):

  1. Pod A (Node 1, IP: 10.244.1.2) sends a packet to Pod C (Node 2, IP: 10.244.2.3).
  2. The CNI plugin on Node 1 encapsulates the packet with Node 2’s IP as the destination.
  3. The packet is sent over the physical network to Node 2.
  4. Node 2 decapsulates the packet and forwards it to Pod C via its bridge.

4. Deep Dive: Services Explained

Service Types

Kubernetes offers four Service types to expose pods:

1. ClusterIP (Default)

  • Exposes the Service on an internal cluster IP.
  • Accessible only within the cluster (pods, nodes).
  • Use case: Internal communication between microservices.

Example:

apiVersion: v1  
kind: Service  
metadata:  
  name: backend-service  
spec:  
  selector:  
    app: backend  
  ports:  
    - protocol: TCP  
      port: 80  
      targetPort: 8080  
  type: ClusterIP

2. NodePort

  • Exposes the Service on a static port (30000-32767) on every node.
  • Accessible externally via node-ip:node-port.
  • Use case: Testing or small-scale external access.

3. LoadBalancer

  • Integrates with cloud providers (AWS, GCP, Azure) to provision an external load balancer.
  • Assigns a public IP to the Service.
  • Use case: Production-grade external access.

4. ExternalName

  • Maps the Service to an external DNS name (e.g., mysql.example.com).
  • No selector or pods required; returns a CNAME record.

Service Discovery with DNS

Kubernetes uses CoreDNS (or legacy kube-dns) to enable DNS-based service discovery. Every Service and pod gets a DNS name:

  • Service DNS: <service-name>.<namespace>.svc.cluster.local (e.g., backend-service.default.svc.cluster.local).
  • Pod DNS: <pod-ip-with-hyphens>.<namespace>.pod.cluster.local (e.g., 10-244-1-2.default.pod.cluster.local).

5. Ingress: Beyond Services

Ingress Controllers

Ingress controllers are critical for Ingress to work. Popular options:

  • NGINX Ingress Controller: Widely used, supports TLS, rate limiting, and rewrite rules.
  • Traefik: Cloud-native, auto-configures with Kubernetes resources.
  • AWS ALB Ingress Controller: Integrates with AWS Application Load Balancers.

TLS Termination and Routing Rules

Ingress can terminate TLS (SSL/TLS encryption) using secrets stored in Kubernetes. Example Ingress manifest with TLS:

apiVersion: networking.k8s.io/v1  
kind: Ingress  
metadata:  
  name: example-ingress  
spec:  
  tls:  
    - hosts:  
        - example.com  
      secretName: example-tls-secret  
  rules:  
    - host: example.com  
      http:  
        paths:  
          - path: /api  
            pathType: Prefix  
            backend:  
              service:  
                name: backend-service  
                port:  
                  number: 80  
          - path: /web  
            pathType: Prefix  
            backend:  
              service:  
                name: frontend-service  
                port:  
                  number: 80

6. Network Policies: Microsegmentation in Action

Network Policies let you define fine-grained rules. Example: Allow ingress to payment-service only from frontend-service on port 5000.

apiVersion: networking.k8s.io/v1  
kind: NetworkPolicy  
metadata:  
  name: payment-policy  
spec:  
  podSelector:  
    matchLabels:  
      app: payment-service  
  policyTypes:  
    - Ingress  
  ingress:  
    - from:  
        - podSelector:  
            matchLabels:  
              app: frontend-service  
      ports:  
        - protocol: TCP  
          port: 5000

7. CNI Plugins: Choosing the Right Tool

PluginUse CaseFeatures
FlannelSimple clusters, low overheadOverlay network, easy setup
CalicoEnterprise, network policiesBGP routing, encryption, policies
Weave NetSmall to medium clustersEncryption, multi-cloud support
CiliumHigh performance, eBPF-basedL7/HTTP-aware policies, observability

8. Advanced Concepts: DNS, Load Balancing, and Namespaces

  • DNS Resolution: CoreDNS resolves Service names to ClusterIPs, enabling pod-to-service communication via DNS.
  • Load Balancing: Services distribute traffic across pods using round-robin (default) or session affinity (ClientIP).
  • Namespaces: Isolate resources, but Network Policies are required to enforce network isolation between namespaces.

9. Conclusion

Kubernetes networking is a complex but vital layer that enables seamless communication between dynamic containers. From Pods (the network endpoints) to Services (stable abstractions), Ingress (external routing), Network Policies (security), and CNI Plugins (network implementation), each component plays a unique role.

By mastering these concepts, you can design resilient, secure, and scalable Kubernetes deployments. Start with the basics (Pods, Services), experiment with Ingress controllers, and gradually add Network Policies for security.

10. References