A readiness check tells Kubernetes whether an application instance can receive traffic. During startup, an application may still be alive while initialization is incomplete, so Kubernetes keeps it running but routes no requests to it until readiness becomes available. section 18.3.2 section 18.3.3
Readiness differs from related health signals:
- Readiness indicates whether the application is prepared to handle traffic. section 18.3.3
- Liveness indicates whether the application should continue running; Kubernetes can restart a pod when liveness is down. section 18.3.3
- The Actuator health endpoint can expose liveness and readiness as health groups, which are distinct from dependency health alone. section 18.3.3
Enable and route readiness checks
Enable the probes in application.yml with management.health.probes.enabled: true. Kubernetes can then query /actuator/health/readiness on the application container. A readiness result of UP permits traffic; a result of DOWN keeps traffic away while the application remains running. section 18.3.3
apiVersion: apps/v1
kind: Deployment
metadata:
name: taco-cloud-deploy
labels:
app: taco-cloud
spec:
replicas: 3
selector:
matchLabels:
app: taco-cloud
template:
metadata:
labels:
app: taco-cloud
spec:
containers:
- name: taco-cloud-container
image: tacocloud/tacocloud:latest
livenessProbe:
initialDelaySeconds: 2
periodSeconds: 5
httpGet:
path: /actuator/health/liveness
port: 8080
readinessProbe:
initialDelaySeconds: 2
periodSeconds: 5
httpGet:
path: /actuator/health/readiness
port: 8080
Use the Deployment listing to inspect the readinessProbe settings, polling interval, startup delay, endpoint path, and container port. section 18.3.3
