7.1 Kubernetes Networking, Services & Ingress

7.1 Kubernetes Networking, Services & Ingress

Quick Answer: Kubernetes enforces a flat, IP-per-Pod networking model where every Pod gets a unique IP address and can communicate with all other Pods without Network Address Translation (NAT). Container Network Interface (CNI) plugins like Calico, Cilium, and Flannel implement this network fabric. Services provide stable Layer 4 virtual IPs across ephemeral Pods (ClusterIP, NodePort, LoadBalancer, ExternalName), while Ingress resources deliver Layer 7 HTTP routing and TLS termination. NetworkPolicies apply granular, Zero Trust firewall rules using Pod and Namespace selectors.

Networking in Kubernetes is fundamentally designed to support microservice architectures by treating containers as first-class network entities. Unlike traditional container platforms that rely on port mapping and host-level NAT, Kubernetes establishes strict networking invariants that ensure seamless inter-pod communication while abstracting underlying infrastructure complexities.

---

The Kubernetes Pod-to-Pod Networking Model

The core philosophy of Kubernetes networking is built around the IP-per-Pod model. Every Pod in a cluster receives its own unique IP address from a dedicated Pod CIDR block assigned to its host node. This design eliminates the need to manage container-to-host port mappings.

Kubernetes imposes three mandatory networking requirements on every cluster implementation:

1. Pod-to-Pod Communication: All Pods can communicate with every other Pod on any node without using Network Address Translation (NAT).
2. Node-to-Pod Communication: All agents on a host node (such as the kubelet and kube-proxy) can communicate with all Pods running on that same node.
3. Self-Identification: The IP address that a Pod sees as its own IP is identical to the IP address that every other Pod and node sees it as.

This flat network topology greatly simplifies application port allocation, service discovery, and container migration across nodes. However, Kubernetes does not provide a default built-in implementation for this network topology; instead, it delegates network provisioning to CNI plugins.

---

Container Network Interface (CNI) Plugins

The Container Network Interface (CNI) is a CNCF project that defines a standardized specification and set of libraries for configuring network interfaces in Linux containers. When a container runtime (such as containerd or CRI-O) creates a Pod sandbox, it invokes the configured CNI plugin to attach network interfaces, allocate IP addresses via IPAM (IP Address Management), and set up routing tables.

Different CNI plugins utilize distinct underlying technologies to establish flat Pod networks and enforce network security:

Overlay Networks vs. BGP Routing

• Overlay Networks (e.g., VXLAN): Encapsulate Pod network packets inside standard UDP packets to cross underlying host networks. Easy to configure across cloud providers but incurs a slight CPU/packet overhead due to encapsulation.
• BGP Routed Networks: Route Pod IP traffic directly over the physical network fabric using Border Gateway Protocol (BGP). Eliminates encapsulation overhead for bare-metal and high-throughput environments.

---

Kubernetes Service Types (Layer 4 Abstractions)

Because Pods are ephemeral objects with dynamic IP addresses that change upon restart or rescheduling, applications cannot rely on static Pod IPs for communication. A Service is an abstract Kubernetes API resource that defines a logical set of Pods (selected via spec.selector) and a stable policy by which to access them (via a Virtual IP and DNS name).

kube-proxy runs on every node and updates host iptables or IPVS rules to load-balance traffic sent to a Service's Virtual IP across healthy backing Pod endpoints.

Kubernetes offers four primary Service types:

Service Manifest Example

apiVersion: v1
kind: Service
metadata:
  name: payment-service
  namespace: finance
spec:
  type: ClusterIP
  selector:
    app: payment-api
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 8080

---

Ingress Controllers & Ingress Resources (Layer 7 Routing)

While a LoadBalancer Service operates at Layer 4 (TCP/UDP), creating a separate cloud load balancer for every microservice can quickly become expensive and unmanageable. An Ingress resource manages external HTTP and HTTPS traffic to services within a cluster at Layer 7 (Application Layer).

It is crucial to distinguish between an Ingress Resource and an Ingress Controller:

• Ingress Resource: A YAML manifest defining HTTP routing rules, hostnames, path prefixes, and TLS configurations.
• Ingress Controller: A daemon (such as NGINX Ingress Controller, Traefik, or Contour) that watches the Kubernetes API server for Ingress resources and dynamically configures reverse proxy software to enforce those rules.

Ingress Manifest Example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls-cert
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /billing
            pathType: Prefix
            backend:
              service:
                name: billing-service
                port:
                  number: 80

---

NetworkPolicies & Zero Trust Micro-Segmentation

By default, Kubernetes network traffic is unrestricted: any Pod in any namespace can send network packets to any other Pod. To establish a Zero Trust security posture, operators deploy NetworkPolicies.

A NetworkPolicy specifies how groups of Pods are allowed to communicate with each other and with other network endpoints. NetworkPolicies use podSelector, namespaceSelector, and ipBlock rules to filter traffic based on:

• Ingress: Incoming connections to target Pods.
• Egress: Outgoing connections originating from target Pods.

Crucial Exam Distinction: NetworkPolicy objects are native Kubernetes API resources, but Kubernetes itself does not enforce them. A CNI plugin with policy enforcement capabilities (such as Calico or Cilium) must be installed. If a cluster uses a basic CNI like Flannel without policy support, NetworkPolicy manifests will be silently ignored by the network data plane.

Default-Deny Isolation Strategy

A cloud-native security best practice is to enforce an explicit Default Deny policy across all namespaces, blocking ingress and egress unless a later rule explicitly permits it. Because NetworkPolicy contains allow rules only — the API has no deny rule — default-deny is the mechanism that makes segmentation possible at all. Section 7.3 covers the isolation semantics, selector logic, the DNS egress trap, and the Gateway API in full.

---

Key Takeaways

• Flat Networking: Every Pod receives a unique IP; Pod-to-Pod traffic traverses the network without NAT.
• CNIs: Plugins like Calico (BGP/VXLAN), Cilium (eBPF), and Flannel (VXLAN overlay) configure container interfaces and policy enforcement.
• Services (L4): Provide stable Virtual IPs and DNS aliases across dynamic Pods via ClusterIP, NodePort, LoadBalancer, and ExternalName.
• Ingress (L7): Manages HTTP/HTTPS host- and path-based routing and centralizes TLS termination using an Ingress Controller.
• NetworkPolicies: Enforce declarative firewall rules based on labels and CIDRs, requiring a policy-aware CNI plugin for enforcement.