How to create a container probe
How to create a container probe
What are the basics of creating a container probe and how the process changes depending on the container probe used.
Let's see the demo. As of now, we don't have any pods running. I already have a file named liveness.yaml. It's a simple pod nginx with an nginx image. In the yaml file, I have a TCP socket. Hence, firstly there will be a TCP probe check on port 8080. It should ideally fail. Let's save the file and run the pod using the
kubectl apply -f liveness.yaml command. After the pod is created, we will verify it through the
kubectl get pods command. The pod is running. Now, we will describe the pod using the command
kubectl describe pod nginx.
Creating a TCP liveness probe
In the events, you can already see the liveness has failed because its connection has been refused. Now, what we'll do is we'll go back to the yaml file, and we will change the TCP port to 80 because we know that 80 is there for this particular container, and it's open. We will delete the pod first by applying the
kubectl delete -f liveness.yaml. Then we'll apply the pod again through the
kubectl apply -f liveness.yaml command. After applying, we can verify the pods with
kubectl get pods. Now it should be running. After that, we will use
kubectl describe pod to describe. In the container section, we can see that the liveness has passed because these are default values. So we can just describe the pod repeatedly, and it should not fail.
Creating a HTTP liveness probe
Next, let's go to the other one. Let's change the tcpSocket to the httpGet in the yaml file. After that, we have to specify the path. The path will be a slash in this case. Then we have to specify the port, which will be 80. Again, we will delete the existing pod with the
kubectl delete -f liveness.yaml command. Once it gets deleted, we'll use the
kubectl apply -f liveness.yaml command to run the pod with the new additions. While using
kubectl get pods, we will get the running status. Now, we can describe the pod using
kubectl describe pod nginx, and we can see in the events section that the container has started successfully. Let's describe a few more times to ensure that the liveness is not failing. What we can do to create a fail scenario is have a separate path, which does not exist. If we delete the existing pod and rerun the pod with the newly added fail scenario, we will see that the liveness probe has failed because that particular path does not exist.
Creating an exec liveness probe
The last one is the exec one. Let's try that as well. In the yaml file, instead of httpGet, we type exec, and then we have the command. Nginx serves from the HTML file; hence, we will always have the cat command on the file just to check if the file exists. It serves this particular usr/share/nginx/html/index.html file; if it's not there, then the liveness should fail.
First, let's create a good scenario. We must delete the existing pod and run the pod again with the new additions. After that, use
kubectl get pods, and you will get the running status. Now, we describe the pod. In the events, we can see that it has successfully started. It also looks like the liveness is passing because it's serving the traffic.
Now, we'll create a failure scenario. We will use the
kubectl exec -it nginx sh command. After entering the pod, we will remove the usr/share/nginx/html/index.html through the
rm usr/share/nginx/html/index.html command, and we'll exit the container. Let's describe the pod again. Now, you will see that the liveness probe has failed. It will fail three times, and then it will restart the container. You will be able to see that after every 10 seconds, it checks again.
If you go above, you can see that we have the failure threshold as three. After three times, it will kill the pod, and then it will restart the pod. You can now see that it has successfully started the pod. That's how the probe works in Kubernetes, and it's very important to define them, the readiness, and startup liveness based on the requirement. Also, it is very important to have the values correct of initialdelaySeconds, the failureThresholds, and the successThreshold. That's it for this lecture, thank you for watching.