Skip to content

Latest commit

 

History

History
197 lines (140 loc) · 6.2 KB

README.adoc

File metadata and controls

197 lines (140 loc) · 6.2 KB
Raw

Health Probe

We are using a Minikube installation to run the examples. For details, please refer to the installation instructions.

Here we are reusing our random-generator, which also includes support for health checks.

To apply a Deployment with liveness and readiness check enabled, use

kubectl apply -f https://k8spatterns.io/HealthProbe/deployment.yml

This deployment introduces an artificial pause of 20 seconds before the application becomes ready.

kubectl get pods -w
NAME                                READY   STATUS        RESTARTS   AGE
random-generator-5856b5f774-54h6b   0/1     Running       0          5s
random-generator-5856b5f774-54h6b   1/1     Running       0          38s

Liveness Probes

The example application exposes two endpoints with which you can manually switch the state of the readiness and liveness checks. For simplicity reasons, we haven’t installed a Service or Ingress (but of course, you are free to do so!)

Instead, we are using a simple port-forwarding directly to the Pod to trigger the toggles:

kubectl port-forward deployment/random-generator 8080:8080 2>&1 &

Now you can switch on/off the readiness/liveness checks and see how the cluster manages your pods:

Check the liveness probe by querying the actuator:

curl -s http://localhost:8080/actuator/health | jq .

Toggle liveness check to off:

curl -s http://localhost:8080/toggle-live

Recheck the liveness probe:

curl -s http://localhost:8080/actuator/health | jq .

Watch the pods and wait a bit. What happens after 2-3 mins?

kubectl get pods -w

Readiness Probes

Let’s now check the readiness probes. For this first flip, the readiness state to false:

curl -s http://localhost:8080/toggle-ready

Watch the pods for 1-2 mins:

kubectl get pods -w

Toggle readiness back on:

curl -s http://localhost:8080/toggle-ready

Watch the pods again:

kubectl get pods -w

Startup Probes

In this example, we will introduce a startup probe to our application. Startup probes are helpful when an application takes significant time to start and become ready. With a startup probe, you can give your application enough time to create and become ready without affecting the liveness and readiness probes.

To update the deployment with the startup probe enabled, use the following command:

kubectl apply -f https://k8spatterns.io/HealthProbe/startup-deployment.yml

This deployment introduces an artificial startup delay of 60 seconds before the application becomes ready. It configures a startup probe that kicks in after 20 seconds after the container has been created and then checks every 10 seconds.

Using

kubectl get pods -w

You should see an output that indicates that the Pod gets ready roughly 60 seconds after the old Pods from the original deployment have been terminated.

NAME                                READY   STATUS              RESTARTS   AGE
random-generator-7c569546cf-wh2tp   0/1     ContainerCreating   0          1s
random-generator-7c569546cf-wh2tp   0/1     Running             0          8s
random-generator-7c569546cf-wh2tp   1/1     Running             0          71s

Readiness Gates

Readiness gates provide an additional check that must be satisfied before a pod is considered ready.

To demonstrate the usage of readiness gates, let’s modify the existing deployment with a readiness gate that includes the following:

kubectl apply -f https://k8spatterns.io/HealthProbe/readiness-gate-deployment.yml

The custom readiness gate k8spatterns.io/RandomReady is added to the pod spec. This readiness gate must be satisfied in addition to the existing readiness probe for the Pod to be considered ready.

To check the status of the readiness gates use

kubectl get pod -o wide

which gives you an output like

NAME                               READY   STATUS    RESTARTS   AGE   IP            NODE       NOMINATED NODE   READINESS GATES
random-generator-bf8cb84b4-n98l7   1/1     Running   0          9s    10.244.0.11   minikube   <none>           0/1

You can see, that wile all containers ready, the overall Pod is not because of a failing readiness gate becaue nobody added the condition k8spatterns.io/ready with a value True to the Pod’s status.

Let’s do this now. We are using kubectl here, but this would usually be done with a controller that monitors the Pod and its dependencies.

First, find out the Pod’s name and store it in a variable:

pod=$(kubectl get pods -l app=random-generator -o name)

Then let’s patch the Pod’s status and add the readiness condition:

kubectl patch $pod --type='json' --subresource=status \
 -p='[{"op": "add",
       "path": "/status/conditions/-",
       "value": {"type": "k8spatterns.io/RandomReady", "status": "True"}}]'

Finally, let’s check again if the Pod gets ready with the readiness gate fulfilled:

kubectl get pod -o wide

That concludes our demo for the Health Probe pattern. Don’t forget to stop the two background processes when done with this example (executing fg followed by a CTRL-C)