The Flat Network Model

Kubernetes enforces a fundamental networking requirement: every pod must be able to communicate directly with every other pod in the cluster, without NAT. This “flat network” model is implemented by a Container Network Interface (CNI) plugin — popular choices include Calico, Flannel, Cilium, and Weave. Each pod gets its own IP address from a cluster-wide CIDR range, and the CNI plugin is responsible for ensuring pods across different nodes can reach each other.

This design has important implications. Because all pods share a flat network space, network policies (covered later) are your primary isolation mechanism — without them, any pod can talk to any other pod by default. This is fine for development but should be hardened for production multi-tenant workloads. The pod IP is ephemeral: when a pod is deleted and recreated, it gets a new IP. This is why you never communicate with pods directly by IP — that’s what Services are for.

Services: ClusterIP, NodePort, LoadBalancer

A Service is a stable network endpoint that abstracts a set of pods. Services use label selectors to determine which pods they route traffic to — when pods are replaced (during a rolling update, for example), the Service automatically routes to the new pods without any configuration change. The kube-proxy component on each node maintains iptables or IPVS rules that implement this routing.

ClusterIP is the default Service type — it creates a virtual IP that’s only reachable from within the cluster. NodePort exposes the service on a static port on every node’s external IP — useful for development and simple setups, but not recommended for production. LoadBalancer provisions a cloud load balancer (an AWS ELB, GCP Load Balancer, etc.) that routes external traffic to the Service. For most production workloads, you don’t use LoadBalancer Services directly for HTTP/HTTPS — you use an Ingress controller instead.

# Service YAML — ClusterIP example for an internal API
apiVersion: v1
kind: Service
metadata:
  name: api-service
  namespace: production
spec:
  selector:
    app: api-server
    tier: backend
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
---
# LoadBalancer Service for a public-facing component
apiVersion: v1
kind: Service
metadata:
  name: frontend-lb
  namespace: production
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  selector:
    app: frontend
  ports:
    - port: 443
      targetPort: 8443
  type: LoadBalancer

Ingress: Your Single Entry Point

An Ingress resource defines HTTP and HTTPS routing rules for external traffic entering the cluster. Instead of provisioning a separate LoadBalancer Service for every application (which creates a separate cloud load balancer and public IP for each), an Ingress controller provides a single entry point that routes traffic based on hostnames and URL paths to different backend Services. This is both more cost-effective and operationally cleaner.

The nginx Ingress controller is the most widely deployed, though cloud providers offer their own (AWS Load Balancer Controller, GKE Ingress). Cert-manager integrates with Ingress to automatically provision and renew TLS certificates from Let’s Encrypt, making TLS termination at the Ingress level straightforward. Combined, nginx Ingress plus cert-manager handles host-based routing and TLS for your entire cluster through a simple Ingress resource annotation.

Network Policies for Pod Isolation

By default, Kubernetes allows all pods to communicate with all other pods. Network Policies let you restrict this by specifying allowed ingress and egress traffic using pod selectors, namespace selectors, and IP blocks. They’re implemented by the CNI plugin (Calico and Cilium have the richest Network Policy support). A good default posture is a “deny all” baseline policy in each namespace, then explicit allow policies for required communication paths.

Network Policies are additive — if multiple policies apply to a pod, all of them are enforced. This makes it safe to layer policies: a namespace-wide deny-all, plus specific allows for your application tiers. Writing and testing Network Policies is notoriously tricky; tools like Cilium’s Network Policy Editor (a visual tool) combined with careful testing in a staging environment before production rollout will save you significant frustration.

# NetworkPolicy — deny all ingress to namespace, then allow specific paths
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-from-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

The post Kubernetes Networking Explained: Pods, Services, and Ingress Controllers appeared first on InfoTech Ninja.