In case there was any question about this feature, I am writing about it specifically to state that this is not an optional feature — this is a MUST IMPLEMENT feature. Okay fine, everything is optional, but if you want your Kubernetes Cluster running the way you intend then you better implement a Readiness Probe. Best of all this is a fairly easy feature to add into your code. For a Readiness Probe we need to add code into both our Pod YAML file and also our application code that is running in our Docker Container.

Ready!

Why Do We Add A Readiness Probe?

Now that we have Pods that Autoscale when necessary our Cluster is going to add Pods when it sees fit. Once a Pod is added the Cluster needs information from the Pod that the Pod is ready to start having traffic routed to the Pod. Now if your Microservice requires a configuration lookup or some other process to complete prior to being ready then you need to let Kubernetes know when it should start routing requests to the Pod. If you skip the Readiness Probe AND your Pod immediately gets traffic routed to it AND your Pod is determined to be unhealthy THEN Kubernetes will continually restart your Pod. This is awful news. Instead we can do something simple and add in a Readiness Probe.

If you haven’t gone through or even read the first part of this series you might be lost, have questions where the code is, or what was done previously. Remember this assumes you’re using GCP and GKE. I will always provide the code and how to test the code is working as intended.

Service Code

For my example the code is simple… overly simple. It basically doesn’t do anything accept start returning 200 responses. I’m sure you can think of ways to call other services and set a state prior to responding with 200 response.

app.use('/readiness', function (req, res, next) {

res.status(200).json({ ready: true });

});

From the application code I’ve provided previously.

Do I Have To Use HTTP Requests?

No. In the Pod Definition you could either use HTTP Requests (probably the simplest option) or you could also set a TCP Probe or even run a Command Scripts to validate your Pod is running. You have lots of options, I just like the easiest one.

Pod Definition

The changes to the Pod definition are super minor and only take a moment to complete. We just need to state where and how to test for our Pod’s readiness. I’ve added notes in the code to show all the possible places you can customize your probe.

# the readiness probe details

readinessProbe:

httpGet: # make an HTTP request

port: 8080 # port to use

path: /readiness # endpoint to hit

scheme: HTTP # or HTTPS

initialDelaySeconds: 3 # how long to wait before checking

periodSeconds: 3 # how long to wait between checks

successThreshold: 1 # how many successes to hit before accepting

failureThreshold: 1 # how many failures to accept before failing

timeoutSeconds: 1 # how long to wait for a response

From the Pod/Deployment definition I’ve provided previously.

Next Steps

In my first post I promised that some of these finer points may be short. This was one I already knew would be short but important. If you are just getting into Kubernetes and haven’t seen Readiness Probes yet or maybe this is a feature you didn’t think important, it is important and necessary. Add this to your default checklist prior to releasing — even if it isn’t the sexiest feature Kubernetes provides.