Health check probes fail because they cannot connect to the container on the specified port. The container may not be listening on that port, initialDelaySeconds is too low, or the container isn't starting properly. Fix by increasing initialDelaySeconds, verifying the port is correct, or checking why the application failed to start.
Fixes getsockopt: connection refused
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 60 # Increased
periodSeconds: 10
failureThreshold: 3livenessProbe:httpGet:path: /healthport: 8080initialDelaySeconds: 60 # IncreasedperiodSeconds: 10failureThreshold: 3getsockopt: connection refused
When Kubernetes runs a health probe (liveness, readiness, or startup), it attempts to connect to a container on a specified port and path. If the connection fails with "connection refused," it means either: (1) the container isn't listening on that port, (2) the container hasn't started yet, or (3) the port is blocked. The probe runs at regular intervals; repeated failures trigger container restarts (liveness) or remove the pod from service (readiness).
Default (0) is usually too low. Allow time for startup:
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 60 # Increased
periodSeconds: 10
failureThreshold: 3Check what port the application listens on:
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> | grep -i "listen\|port"Ensure the probe port matches the application's actual listening port.
Exec into the container and verify:
kubectl exec -it <pod-name> -n <namespace> -- netstat -tulpn | grep LISTEN
# Or
kubectl exec -it <pod-name> -n <namespace> -- ss -tulpnLook for the port the probe is checking.
Containers listening only on 127.0.0.1 reject external probe connections. Configure application to listen on 0.0.0.0:port or use localhost if probe connects locally.
View full logs to find startup errors:
kubectl logs <pod-name> -n <namespace> --tail=100
kubectl logs <pod-name> -n <namespace> --previous # Previous restartUse startup probes to give slow-starting applications extended startup time. Ensure probe path returns 2xx/3xx status. Verify network policies don't block probe traffic. For custom ports, ensure they're exposed in the container spec. TCP probes are simpler if HTTP endpoint unavailable—they just verify port is listening.