Readiness probes

The purpose of readiness probes

Applications in Kubernetes are often hosted in such a way that multiple duplicate instances of an application exist side-by-side simultaneously. Such a duplicate instance is called a replica. Readiness probes allow an application replica to temporarily mark itself as unable to serve requests in a Kubernetes cluster. A liveness probe can pass while a readiness probe fails - meaning that in general, the application is up, but is still waiting for something to happen so that it can serve requests (e.g. waiting for some secondary, dependent service to become online, like Redis cache).

The /readyz endpoint of your application is queried automatically by Alokai Cloud every few seconds to check whether requests should be routed to the queried application replica. One such case - where traffic will should stop directed to a replica - is if an application instance is being killed (if it receives a SIGTERM signal).

You can read more about Kubernetes readiness probes in the official documentation.

Built-in middleware readiness probes

As of version 5.0.0 of the @vue-storefront/middleware package, you can launch the middleware locally and send a GET request to the http://localhost:4000/readyz endpoint. The response will contain either a success message or a list of errors describing why the readiness probe failed.

To add custom readiness probes to the built-in @vue-storefront/middleware readiness probe feature, pass them to the readinessProbes property when calling createServer.

const customReadinessProbe = async () => {
  const dependentServiceRunning = await axios.get(
    "http://someservice:3000/healthz"
  );
  if (dependentServiceRunning.status !== 200) {
    throw new Error(
      "Service that the middleware depends on is offline. The middleware is temporarily not ready to accept connections."
    );
  }
};
const app = await createServer(config, {
  readinessProbes: [customReadinessProbe],
});

In order for custom readiness probes to be implemented correctly, they need to do two things:

1. they must all be async or return a promise (the return value is not checked, it's expected to be void/undefined)
2. they must all throw an exception when you want a readiness probe to fail

Implementation of readiness probes in your own application

Readiness probes are more difficult to implement than liveness probes. In liveness probes, a simple stateless REST endpoint handler was sufficient. Readiness probes, on the other hand, need to monitor the signals that the application process received. In addition to that, you can write your own readiness conditions, such as checking if an external service that your application depends on is online.

If your application uses Node's http module to serve HTTP requests, you can use the @godaddy/terminus NPM package to implement readiness checks.