Kubernetes Networking Basics

Kubernetes networking can feel complex at first, but understanding how Pods, Services, DNS, and CNI plugins interact is essential for operating any Kubernetes cluster—whether it's on-premises or cloud-based.

1. Pod Networking (CNI)

Kubernetes does not ship with a built-in networking layer. Instead, it relies on CNI (Container Network Interface) plugins like:

  • Calico
  • Flannel
  • Weave Net
  • Cilium

These plugins handle:

  • Assigning IP addresses to Pods
  • Routing traffic between nodes
  • Network Policy enforcement

Example: install Calico (common in kubeadm clusters):

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
2. Service Networking

Pods are ephemeral, so Kubernetes exposes applications through Services. The main service types are:

  • ClusterIP – internal access only
  • NodePort – exposes a port on every node
  • LoadBalancer – external access (requires an external LB)

Create a Service:

kubectl expose deployment nginx --port=80 --type=ClusterIP
3. kube-proxy

kube-proxy runs on each node and ensures that service traffic is routed properly using:

  • iptables (default)
  • IPVS (faster at high scale)
4. DNS with CoreDNS

Every Kubernetes cluster includes CoreDNS, which allows resolving service names like:

nginx.default.svc.cluster.local

Test DNS resolution:

kubectl exec -it <pod-name> -- nslookup kubernetes.default
5. Network Policies

Network Policies let you control which Pods can communicate. They work like firewall rules inside the cluster.

Example: only allow Pods with label app=frontend to access the backend service:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Only CNIs that support policies (Calico, Cilium) will enforce these rules.

This overview gives you a strong foundation to understand how communication works inside any Kubernetes cluster—from pod routing to service discovery and internal DNS.