Kubernetes liveness, readiness, and startup probes are like health check mechanisms for your applications running in containers, ensuring they’re operating smoothly. Here’s a simple explanation of each using an analogy of running a business.

𝗟𝗶𝘃𝗲𝗻𝗲𝘀𝘀 𝗣𝗿𝗼𝗯𝗲 (𝗜𝘀 𝘁𝗵𝗲 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝘀𝘁𝗶𝗹𝗹 𝗮𝗹𝗶𝘃𝗲?)

𝗔𝗻𝗮𝗹𝗼𝗴𝘆: Imagine you’re running a coffee shop. The liveness probe is like checking whether your coffee machine is still functioning throughout the day. If the machine breaks down and stops making coffee, you need to either fix it or replace it, otherwise, customers won’t get coffee.

𝗜𝗻 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀: The liveness probe ensures that your application is still alive and not stuck or crashed. If it fails, Kubernetes restarts the container automatically. For example, if a container goes into a deadlock, the liveness probe detects this and restarts the container to fix the issue.

𝗪𝗵𝗲𝗻 𝘁𝗼 𝘂𝘀𝗲: If your application can sometimes get into an unrecoverable state, like a crash or deadlock, this probe can automatically fix it by restarting the container.

𝗥𝗲𝗮𝗱𝗶𝗻𝗲𝘀𝘀 𝗣𝗿𝗼𝗯𝗲 (𝗜𝘀 𝘁𝗵𝗲 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝗿𝗲𝗮𝗱𝘆 𝘁𝗼 𝘀𝗲𝗿𝘃𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀?)

𝗔𝗻𝗮𝗹𝗼𝗴𝘆: In the coffee shop, the readiness probe checks if your coffee machine is ready to serve customers. For example, after turning on the machine, it might take a few minutes to warm up before it can make coffee. If the machine isn’t ready yet, customers shouldn’t be directed to it.

𝗜𝗻 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀: The readiness probe checks if the container is ready to handle traffic. It might take time for your app to fully initialize or connect to dependencies (like a database). Kubernetes won’t send any traffic to your app until the readiness probe passes.

𝗪𝗵𝗲𝗻 𝘁𝗼 𝘂𝘀𝗲: Use it when your application needs some time to initialize before being able to serve requests (e.g., loading configuration, warming up cache).

𝗦𝘁𝗮𝗿𝘁𝘂𝗽 𝗣𝗿𝗼𝗯𝗲 (𝗜𝘀 𝘁𝗵𝗲 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝘂𝗽 𝗮𝗻𝗱 𝗿𝘂𝗻𝗻𝗶𝗻𝗴 𝗮𝘁 𝘀𝘁𝗮𝗿𝘁𝘂𝗽?)

𝗔𝗻𝗮𝗹𝗼𝗴𝘆: When you first open the coffee shop in the morning, the startup probe is like checking if everything (coffee machine, lights, etc.) is set up and ready for business. Until this initial setup is complete, no customers can come in.

𝗜𝗻 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲s: The startup probe checks if your container’s application has started successfully. It’s especially useful for apps that have slow startup times. Until the startup probe passes, Kubernetes won’t send any other probes (liveness or readiness), ensuring that the app doesn’t get prematurely killed or sent traffic before it’s ready.

𝗪𝗵𝗲𝗻 𝘁𝗼 𝘂𝘀𝗲: Ideal for apps that have a long initialization process. This prevents Kubernetes from misjudging slow-starting apps as unhealthy.

Example in Node.js API

Here's how to set up liveness, readiness, and startup probes for a Node.js API in Kubernetes

Suppose you have a simple Node.js API with an endpoint /health for health checks.

// server.js
const express = require("express");
const app = express();
const PORT = process.env.PORT || 3000;

let isReady = false; // Used to simulate readiness

app.get("/health", (req, res) => {
  res.status(200).send("API is alive");
});

app.get("/readiness", (req, res) => {
  if (isReady) {
    res.status(200).send("API is ready");
  } else {
    res.status(503).send("API is not ready");
  }
});

// Simulate delayed readiness
setTimeout(() => {
  isReady = true;
}, 10000); // API becomes ready after 10 seconds

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

This API has

/health: Returns 200 OK to indicate the API is alive.
/readiness: Returns 503 Service Unavailable until the API is fully ready, then returns 200 OK after 10 seconds.

Kubernetes Probes

Liveness Probe: Checks if the app is alive by hitting /health. If this probe fails, Kubernetes restarts the container.
Readiness Probe: Checks if the app is ready to handle traffic by hitting /readiness. Only after the app is fully initialized does this probe return a 200 OK, allowing Kubernetes to route traffic to it.
Startup Probe: For apps with a slow start, the startup probe waits until the app is completely initialized before allowing other probes to execute.

Here’s how you can define these probes in your Kubernetes deployment YAML file

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodejs-api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nodejs-api
  template:
    metadata:
      labels:
        app: nodejs-api
    spec:
      containers:
      - name: nodejs-api
        image: node:14
        command: ["node", "server.js"]
        ports:
        - containerPort: 3000
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /readiness
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5
        startupProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 20

Explanation of Each Probe Configuration

Liveness Probe:
- Path: /health
- initialDelaySeconds: Waits 5 seconds before the first check.
- periodSeconds: Checks every 10 seconds to see if the app is alive. If it fails, Kubernetes restarts the container.
Readiness Probe:
- Path: /readiness
- initialDelaySeconds: Waits 5 seconds before the first check.
- periodSeconds: Checks every 5 seconds to see if the app is ready to serve traffic. Traffic isn’t sent until this probe passes.
Startup Probe:
- Path: /health
- initialDelaySeconds: Waits 5 seconds before the first check.
- periodSeconds: Checks every 5 seconds during startup.
- failureThreshold: Allows up to 20 checks (100 seconds) to ensure the app has fully initialized before liveness or readiness probes start, preventing premature restarts.

This setup helps Kubernetes manage your Node.js API’s health effectively, restarting it if it crashes, waiting until it’s ready before routing traffic, and allowing time for complete startup if initialization is slow.

Which probes failled restart the container?

Liveness Probe: If the liveness probe fails, Kubernetes restarts the container. This probe checks if the application is still "alive" (not in a crashed or deadlocked state). If it detects an issue, it considers the container unhealthy and restarts it to try to resolve the issue.
Readiness Probe: A readiness probe failure does not restart the container. Instead, it marks the container as "unready," meaning Kubernetes will stop routing traffic to it until the probe passes again. This is useful if the application temporarily cannot serve requests (e.g., during maintenance or reconfiguration).
Startup Probe: If the startup probe fails, it also triggers a container restart. The startup probe is intended for applications that need extra time to initialize. It prevents the liveness and readiness probes from prematurely failing until the app has fully started up.

So, only the liveness and startup probes trigger a restart (Also depending on the Restart Policy default to Always ) when they fail. The readiness probe only affects traffic routing.

Execution of of a probes

In Kubernetes, probes are checked in a specific sequence based on the presence of a startup probe

Startup Probe (if configured): This probe is checked first. When a startup probe is defined, Kubernetes will wait until it passes successfully before starting to run the liveness and readiness probes. This avoids premature restarts or traffic routing failures for applications with slow initialization. While the startup probe is running, the liveness and readiness probes are disabled.
Liveness and Readiness Probes (after Startup Probe passes):
- Liveness Probe: Checks if the container is still healthy and able to function.
- Readiness Probe: Determines if the container is ready to serve traffic.

Once the startup probe passes (or if it isn’t defined), the liveness and readiness probes begin their checks according to their configured intervals.

Priority Summary

Startup Probe has the highest priority. Until it succeeds, the liveness and readiness probes are ignored.
Liveness and Readiness Probes then run independently of each other on their own schedules once the startup probe has passed.