Readiness, liveness and startup

Opening your lesson

Readiness decides whether a Pod should receive Service traffic. Liveness asks whether a container needs a restart. Startup probes protect slow initialization before the other probes begin their normal checks. These roles overlap in appearance but have different consequences when they fail. Choose the endpoint and port the application exposes, then set timing that matches its behavior. An aggressive liveness check can turn a slow boot into repeated restarts. The tasks configure each probe explicitly and include a wrong path that can't report health. Inspect the declared probe and observed status separately before deciding that the workload is ready for traffic.

printf '%s' 'apiVersion: "apps/v1"
kind: "Deployment"
metadata:
  name: "cobalt-195"
spec:
  replicas: 2
  selector:
    matchLabels:
      app: "cobalt-195"
  template:
    metadata:
      labels:
        app: "cobalt-195"
    spec:
      containers:
        - name: "cobalt-195"
          image: "nginx:1.27"
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: "/health"
              port: 80
            initialDelaySeconds: 2
            periodSeconds: 5
' > 'workload.yaml'
kubectl apply -f workload.yaml

A probe checks a specific path and port. Choosing the wrong probe or endpoint changes readiness or restart behavior.

Choose your character

Your Work Gym account