Network anti-patterns — the most common mistakes

Network anti-patterns are the most common mistakes when configuring Kubernetes networking. This lesson walks the anti-patterns, the fixes, and the operational discipline.

Anti-pattern 1: Default-allow NetworkPolicy

flowchart LR
    A[Cluster without NetworkPolicy] --> B[Every Pod talks to every Pod]
    B --> C[Production talks to dev]
    B --> D[Backend talks to frontend's DB]
    A --> E[No isolation]

The intent is “get things working first”; the result is no isolation.

The fix: default-deny NetworkPolicy in every namespace, with explicit allow rules.

Anti-pattern 2: Cilium without Hubble

# Anti-pattern
helm install cilium cilium/cilium --version 1.16.0 \
  # No Hubble enabled

The intent is “minimal install”; the result is no L7 visibility or flow logs.

The fix: enable Hubble from the start. Hubble is the observability layer for Cilium.

Anti-pattern 3: Single CNI choice without testing

# Anti-pattern: install CNI without testing alternative
kubectl apply -f https://docs.cilium.io/install

The intent is “use the popular one”; the result is no fallback if the CNI has a bug or incompatibility.

The fix: test multiple CNIs in staging; have a documented migration path.

Anti-pattern 4: No BGP on bare metal

flowchart LR
    A[Bare metal cluster] --> B[LoadBalancer Service]
    B --> C{Cloud provider?}
    C -->|No| D[No external IP]
    D --> E[Users can't reach]
    A --> F[Need BGP]
    F --> G[MetalLB or Cilium BGP]

The intent is “use NodePort”; the result is poor performance and operational complexity.

The fix: install MetalLB or Cilium BGP for LoadBalancer Service advertisement.

Anti-pattern 5: No IPv6 planning

# Anti-pattern: install kubeadm with IPv4-only
kubeadm init --pod-network-cidr=10.244.0.0/16

The intent is “IPv6 not needed yet”; the result is a later migration when IPv6 becomes a requirement.

The fix: install with dual-stack from the start, even if the workloads are IPv4-only. Migration to dual-stack after the fact is harder.

Anti-pattern 6: Custom CNI scripts

# Anti-pattern
#!/bin/bash
# Custom CNI configuration script
ip link add ...
ip addr add ...
iptables -A ...

The intent is “exactly what we need”; the result is a debugging nightmare when things break.

The fix: use a supported CNI (Cilium, Calico). Custom CNI scripts are unsupported and undebuggable.

Anti-pattern 7: No NetworkPolicy documentation

# Anti-pattern: NetworkPolicy exists but is not documented
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ???
spec:
  podSelector: {}

The intent is “the rules are obvious”; the result is rules that rot because no one understands them.

The fix: document every NetworkPolicy in the runbook. Each policy should have a name that describes its purpose, comments in the YAML, and a runbook entry.

Quiz

The operational discipline

Network anti-patterns in production rest on five non-negotiable elements:

• Default-deny NetworkPolicy. Every namespace starts with deny-all + explicit allow.
• Cilium with Hubble enabled. Observability is the primary benefit.
• Test CNI alternatives. Have a documented migration path.
• BGP for bare metal. MetalLB or Cilium BGP.
• Document every NetworkPolicy. In the runbook.

Networking is production infrastructure. The discipline is to choose the CNI deliberately, enable observability, and document every policy.