Description
A readinessProbe checks whether a container is ready to handle requests. Without one, Service traffic may arrive while the application is still initializing.
Configure an appropriate readiness probe so unready Pods are excluded from ordinary Service traffic during updates or restarts. Readiness failure does not mean the container is restarted or direct Pod access is blocked.
Potential impact
- Requests sent to an unready container can fail.
- Deployments can experience more transient errors or failed responses.
- It becomes harder to distinguish initialization from actual service readiness.
Remediation
- Set
readinessProbefor service containers that handle requests. - Choose a suitable HTTP, TCP, command or other supported check. Decide whether a successful TCP connection actually demonstrates readiness to process application requests.
- Adjust intervals and delays to startup behavior, and test actual Service traffic during deployments and failures.
Examples
These are existing TCP-check examples. Choose an available image and configure the service to listen on port 8080. The delays and check intervals are illustrative.
Before
yaml
apiVersion: v1
kind: Pod
metadata:
name: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
livenessProbe:
tcpSocket:
port: 8080
After
yaml
apiVersion: v1
kind: Pod
metadata:
name: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
Explanation:
- Before: Only a liveness probe is configured. Without a separate readiness criterion, the Pod may become a Service target before initialization finishes.
- After: A successful TCP connection is the readiness criterion. Unready Pods are excluded from the ordinary Service path, but this is not a security control that blocks direct access.