highIntermediateSymptom-first#pods#hostport#networking#ports

Pod container binds host port — address already in use

Pod in CrashLoopBackOff with bind: address already in use

Likely source:availabilityconfiguration

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Pod in CrashLoopBackOff with bind: address already in use
  • Events show Failed to create pod sandbox due to bind port
  • Application starts but exits immediately with EADDRINUSE

hostPort should almost never be used in production. Use a Service of type NodePort or LoadBalancer instead. hostPort limits scheduling to one pod per node for that port.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Crash logs

    kubectl logs <pod> -n <namespace> --previous

  • hostPort usage

    kubectl get pod <pod> -n <namespace> -o jsonpath='{.spec.containers[*].hostPort}'

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • hostPort is set and two pods are scheduled on the same node
  • Crash logs show EADDRINUSE

Confirm before fixing

kubectl get pods -n <namespace> -o wide | grep <node>
READ

List pods on the conflicting node

Fix

kubectl patch deployment/<deploy> -n <namespace> --type merge -p '{"spec":{"template":{"spec":{"containers":[{"name":"<c>","ports":[{"containerPort":8080}]}}}}}'
CHANGE

Remove hostPort and use a Service to expose the port instead

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
kubectl logs <pod> -n <namespace> --previous
READ

Confirm EADDRINUSE

2
kubectl get pod <pod> -n <namespace> -o jsonpath='{.spec.containers[*].hostPort}'
READ

Check hostPort usage

3
kubectl get pods -n <namespace> -o wide | grep <node>
READ

Find the conflicting pod on the same node

4
kubectl patch deployment/<deploy> -n <namespace> --type merge -p '{"spec":{"template":{"spec":{"containers":[{"name":"<c>","ports":[{"containerPort":8080}]}}}}}'
CHANGE

Remove hostPort; expose via Service instead

Prevention

  • Avoid hostPort in manifests; use containerPort + Service.
  • If hostPort is absolutely necessary, set topology spread constraints to avoid co-location.
  • Run a lint check (e.g., kubeval/kube-linter) that flags hostPort usage.
  • Document the specific use case for hostPort and require explicit approval.

Related runbooks

Same stack, same failure family — worth a skim.

CrashLoopBackOff — container keeps crashing and restartingcritical

kubectl get pods shows CrashLoopBackOff status

KubernetesFoundation4 causes
Open runbook
Address already in use — port binding conflicthigh

bind: Address already in use error on application startup

LinuxFoundation3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.