Kubernetes Networking Cheat Sheet
Core Kubernetes networking concepts including Services, DNS, NetworkPolicies, and Ingress for controlling pod-to-pod traffic.
3 PagesAdvancedFeb 10, 2026
Service Types
How Kubernetes Services expose sets of pods.
- ClusterIP- Default type, exposes the service on an internal-only cluster IP
- NodePort- Exposes the service on a static port on every node's IP
- LoadBalancer- Provisions an external cloud load balancer (requires cloud provider integration)
- ExternalName- Maps a service to an external DNS name via a CNAME, no proxying involved
Service Manifest
Expose a Deployment's pods internally on port 80.
yaml
apiVersion: v1kind: Servicemetadata: name: web-svcspec: selector: app: web ports: - protocol: TCP port: 80 targetPort: 8080 type: ClusterIP
NetworkPolicy - Deny by Default
Restrict ingress traffic to only pods labeled 'role: frontend'.
yaml
apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: allow-frontend-onlyspec: podSelector: matchLabels: app: api policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080
Ingress Resource
Route external HTTP traffic to a service based on host/path.
yaml
apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: web-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /spec: ingressClassName: nginx rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: web-svc port: number: 80
Cluster DNS
How service discovery works via CoreDNS.
- Service FQDN- `<service>.<namespace>.svc.cluster.local` resolves to the ClusterIP
- Pod DNS- `<pod-ip-dashed>.<namespace>.pod.cluster.local`, rarely used directly
- CoreDNS- Default cluster DNS server, runs as a Deployment in kube-system
- Headless service- `clusterIP: None`, DNS returns individual pod IPs directly, used for StatefulSets
Cilium L7-Aware NetworkPolicy
Restrict traffic by HTTP method/path, not just L3/L4, using a CNI that supports L7 enforcement.
yaml
apiVersion: cilium.io/v2kind: CiliumNetworkPolicymetadata: name: api-http-rulesspec: endpointSelector: matchLabels: app: api ingress: - fromEndpoints: - matchLabels: role: frontend toPorts: - ports: - port: "8080" protocol: TCP rules: http: - method: "GET" path: "/api/v1/.*" - method: "POST" path: "/api/v1/orders"
Inspecting kube-proxy / Dataplane Mode
Confirm whether traffic is routed via iptables, IPVS, or an eBPF dataplane (e.g. Cilium replacing kube-proxy).
bash
# Check kube-proxy mode from its ConfigMapkubectl -n kube-system get configmap kube-proxy -o yaml | grep mode# List IPVS virtual servers if in IPVS modeipvsadm -Ln# Confirm Cilium is running kube-proxy-free (eBPF replacement)cilium status --verbose | grep KubeProxyReplacement# Trace a packet's path through Cilium's eBPF datapathcilium monitor --type drop
Gateway API HTTPRoute
The successor to Ingress — more expressive routing with weighted backends and header matching.
yaml
apiVersion: gateway.networking.k8s.io/v1kind: HTTPRoutemetadata: name: web-routespec: parentRefs: - name: shared-gateway hostnames: - "app.example.com" rules: - matches: - path: type: PathPrefix value: /canary headers: - name: x-canary value: "true" backendRefs: - name: web-svc-canary port: 80 weight: 20 - backendRefs: - name: web-svc port: 80 weight: 100
Service Mesh Networking Concepts
Terms that appear once a mesh (Istio/Linkerd) sits on top of raw Kubernetes networking.
- Sidecar proxy- Envoy/Linkerd-proxy injected into each pod intercepts all in/out traffic transparently via iptables redirect
- mTLS by default- Mesh automatically encrypts and authenticates pod-to-pod traffic without app code changes
- DestinationRule / traffic policy- Configures load-balancing algorithm, connection pool limits, and outlier detection per service
- VirtualService- Istio CRD for fine-grained routing (retries, timeouts, fault injection) beyond what Ingress/HTTPRoute offer
- East-west vs north-south traffic- Mesh primarily governs east-west (pod-to-pod); Ingress/Gateway API governs north-south (external-to-cluster)
- mTLS STRICT mode- PeerAuthentication policy that rejects any plaintext traffic between meshed pods
Debugging CoreDNS Resolution Failures
Common diagnostic commands when pod-to-service DNS lookups fail or are slow.
bash
# Run a throwaway debug pod with dig/nslookupkubectl run dnsdebug --rm -it --image=nicolaka/netshoot -- bash# Inside the pod, test resolution and timingdig web-svc.default.svc.cluster.local +short# Check CoreDNS pod health and recent errorskubectl -n kube-system logs -l k8s-app=kube-dns --tail=100 | grep -i error# Inspect the CoreDNS Corefile for ndots/upstream settingskubectl -n kube-system get configmap coredns -o yaml# High ndots (default 5) causes 5 failed lookups before an external FQDN# resolves — set dnsConfig.options ndots lower for chatty external callers
Pro Tip
NetworkPolicies are additive and namespace-scoped with no CNI enforcing them by default — verify your CNI plugin (Calico, Cilium, etc.) actually supports NetworkPolicy, otherwise the manifests apply silently but do nothing.
Was this cheat sheet helpful?
Explore Topics
#KubernetesNetworking#KubernetesNetworkingCheatSheet#DevOps#Advanced#ServiceTypes#ServiceManifest#NetworkPolicyDenyByDefault#IngressResource#Networking#Kubernetes#CheatSheet#SkillVeris
