A network engineer is troubleshooting a Kubernetes deployment where pods are failing to start with the error 'CrashLoopBackOff'. The pod log shows 'bind: address already in use'. The deployment runs multiple replicas of a container that listens on port 8080. What is the most likely cause?
hostPort reserves the port on the host node, so only one pod per node can use it. With multiple replicas, subsequent pods fail with address in use.
Why this answer
The 'bind: address already in use' error indicates that the container's process cannot bind to port 8080 because it is already occupied. When `hostPort: 8080` is specified in the pod spec, Kubernetes instructs the container runtime to map the container port to the same port on the node's network namespace. If multiple replicas of the deployment are scheduled on the same node, each pod attempts to bind to port 8080 on the host, causing a conflict and the CrashLoopBackOff state.
This is a common misconfiguration when using hostPort without ensuring that replicas are spread across different nodes.
Exam trap
Cisco often tests the distinction between hostPort (which binds to the node's IP) and containerPort (which is informational), leading candidates to overlook that hostPort causes direct port conflicts on the same node.
How to eliminate wrong answers
Option A is wrong because port 8080 is not a privileged port (privileged ports are below 1024), and the error message 'address already in use' is unrelated to capabilities. Option C is wrong because a NodePort service allocates a port on every node's IP (typically in the range 30000-32767), and the error occurs at the pod level, not at the service level; a NodePort conflict would manifest differently, such as service creation failure. Option D is wrong because multiple containers in the same pod share the same network namespace and cannot bind to the same container port without explicit port mapping, but the error is about the host port conflict, not inter-container conflict within a single pod.