Container Networking: KCSA practice questions

Container networking explains how traffic reaches pods, and it is the foundation that network security controls later restrict. The Kubernetes network model gives each pod its own unique cluster-wide IP address. Containers in the same pod share a network namespace and talk over localhost, and all pods can reach all other pods, on the same node or on different nodes, directly and without NAT. Kubernetes defines this model but does not implement it: on Linux the container runtime uses the Container Network Interface to call a pod network implementation, usually called a CNI plugin.

That default openness is the security point. Unless something restricts it, any compromised pod can open connections to every other pod. NetworkPolicy is the built-in API for controlling traffic between pods or between pods and the outside world at layer 3 or 4, but it is enforced by the network implementation; if the plugin does not support it, the API still exists and the policies simply have no effect.

Pods are ephemeral, so their addresses are not a stable target. A Service gives a set of pods, usually chosen by a label selector, a stable way to be reached, and the control plane keeps the Service's EndpointSlices in step as matching pods come and go. There are four Service types. ClusterIP, the default when no type is given, exposes the Service on a cluster-internal IP that is reachable only from inside the cluster. NodePort also allocates a cluster IP and additionally opens a static port on every node, taken from the range set by --service-node-port-range, 30000-32767 by default. LoadBalancer exposes the Service through an external load balancer that you or a cloud provider integration must supply. ExternalName maps the Service to an external hostname by returning a DNS CNAME record, with no proxying at all. A headless Service, created by setting clusterIP to None, gets no cluster IP and no load balancing from the platform.

kubectl expose builds a Service from an existing pod, Deployment, ReplicaSet, replication controller or Service, reusing that resource's selector; its --type flag defaults to ClusterIP, so kubectl expose deployment nginx --port=80 --target-port=8000 creates an internal Service. For debugging, kubectl port-forward <pod> 28015:27017 forwards a local port to a port in the pod. The documentation notes that authorization for it is enforced by the API server and that port forwarding can give direct network access to a workload, bypassing network-level controls, so it is a permission worth restricting.

HTTP routing from outside is the job of Ingress. An Ingress maps hostnames and URL paths to backend Services and can terminate TLS, but it does not expose arbitrary ports or protocols, and creating the resource alone has no effect: an Ingress controller must be running to implement it, with ingressClassName selecting which one. The Kubernetes project now recommends Gateway API over Ingress; the Ingress API is frozen but still generally available and not scheduled for removal.