Why Kubernetes Networking Is Different

Networking in Kubernetes can feel intimidating at first because it abstracts away traditional IP address management. Every pod gets its own IP address, and containers within a pod share a network namespace. Understanding the layers of Kubernetes networking unlocks the ability to design scalable, reliable applications.

The Four Networking Problems Kubernetes Solves

  1. Container-to-container communication: Containers in the same pod communicate via localhost.
  2. Pod-to-pod communication: All pods can reach each other without NAT, via the flat cluster network.
  3. Pod-to-service communication: Services provide stable DNS names and virtual IPs for pod groups.
  4. External-to-service communication: Ingress and LoadBalancer services expose workloads to the internet.

Kubernetes Services: The Foundation

A Service is an abstraction that gives a stable endpoint to a dynamic set of pods (selected by labels). There are four Service types:

  • ClusterIP (default): Accessible only within the cluster. Used for internal microservice communication.
  • NodePort: Exposes the service on each node's IP at a static port. Useful for development and testing.
  • LoadBalancer: Provisions a cloud load balancer (e.g., AWS NLB, GCP Load Balancer) and assigns an external IP.
  • ExternalName: Maps a service to an external DNS name, useful for integrating external services.

Example: Creating a ClusterIP Service

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

Ingress: HTTP Routing at the Edge

While Services handle TCP/UDP routing, Ingress provides HTTP and HTTPS routing with host-based and path-based rules. An Ingress controller (like NGINX, Traefik, or AWS ALB Controller) watches Ingress resources and configures the actual load balancer.

Example: Path-Based Ingress Rule

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

DNS in Kubernetes

Kubernetes runs an internal DNS server (CoreDNS by default). Every Service gets a DNS record in the format service-name.namespace.svc.cluster.local. Pods can reference services simply by name within the same namespace, or by fully qualified name across namespaces.

Network Policies: Controlling Traffic Flow

By default, all pods can communicate with all other pods. Network Policies let you enforce firewall-like rules at the pod level. A policy can restrict which pods can send or receive traffic, providing micro-segmentation within the cluster.

Key Takeaways

  • Use ClusterIP for internal service communication
  • Use Ingress for HTTP/S traffic routing from outside the cluster
  • Use LoadBalancer for non-HTTP external traffic
  • Implement Network Policies to enforce least-privilege communication
  • Understand CoreDNS for service discovery patterns

Kubernetes networking has many layers, but once you understand Services and Ingress, the rest of the model becomes much clearer. Start with ClusterIP and Ingress for most web applications and layer in network policies as you harden your environment.