Q: What is the main difference between readiness and liveness probes? Does a readiness or liveness probe cause a pod to restart? Explain the behavior.

Purpose: Detects when an application is stuck in an unrecoverable state (e.g. fatal deadlock, corrupted JVM memory) where a container restart is the ONLY remediation. - **Failure Action**: Kubelet kills the container and initiates a restart according to the Pod's `restartPolicy: Always`. The pod restart count increments.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
  failureThreshold: 3

Purpose: Detects whether the application is currently capable of handling client requests (e.g. warming up caches, loading datasets into memory, temporary downstream DB latency). - **Failure Action**: Kubelet marks `Ready: False`. The Kubernetes Endpoints controller removes the Pod IP from all Service endpoints. Traffic is diverted to other healthy pods. **The container is NOT restarted.**

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 2

A classic production disaster occurs when engineers configure liveness probes to check external dependencies (database connectivity). If the database becomes slow, all pods fail their liveness probes simultaneously, kubelet restarts all containers, and the entire cluster enters a death spiral of restarts.

Use `startupProbe` for legacy or JVM applications that take minutes to initialize. Startup probes disable liveness and readiness checks until the application has fully started, preventing kubelet from prematurely killing slow-booting pods.