Exploring Container Probes in Kubernetes
Civo Academy - Exploring Container Probes in Kubernetes
Description
Begin to understand the different container probes within Kubernetes including readiness probe, liveness probe, and startup probe.
Transcription
What are container probes?
In this lecture, we'll be studying container probes. Now, whenever a port is created and a container process starts, the Kubernetes service will send the traffic to that port, even if it's not ready to handle that. Then the port is running, and if you have an overload of the traffic and a deadlock situation where your port actually is not live, but the process is running so, Kubernetes will think it's fine and keep sending the traffic, and your port will not respond the way it should. To handle these kinds of scenarios, in Kubernetes, there are container probes that can be defined.
What is a readiness probe?
A readiness probe is mostly used to check the dependencies of the port up there and if the port is ready. If the port is not ready, then the service will not send the traffic to that particular port unless the port is in a ready state.
What is a liveness probe?
A liveness probe will check whether your port is alive in a deadlock situation. If it's not, it will restart, and, again, if the check that you have defined in the probe is successful, your port will start serving the traffic properly.
What is a startup probe?
Then comes the startup probe. This is a new type of probe from the Kubernetes 1.16 version onwards. It's a special kind of liveness probe. It halts the execution of other probes, and first, the startup probe is executed. Unless and until it completes or succeeds, a liveness probe will continue the execution.
What are probe checks?
As you can see, there are different types that we can have for the probe check. One is HTTP, where you just check the httpGet response is okay or 200 to 399 some ranges there, and it is then a success; else, it's a failure. Then you have a TCP socket, which is just a port check. If the port check passes, it's a success. Else, it's a failure. Then you have a command check. If you have a custom command that you want to run and have a custom result, and if it's zero, then it's a success; if it's not, then it's a failure. You can have a different customized command to check whether your container is healthy or not.
Other important fields
Some of the very important fields include initialDelaySeconds, which determines how much time it will delay before any probe starts. Then, periodSeconds determines how much time should be there between one probe check to another probe check. Next comes timeoutSeconds which determines the number of seconds Kubernetes will wait for the response. After that comes the successThreshold which gives the number of times we want the probe to be successful before marking it as successful. Lastly, we have failureThreshold, which tells the number of times we want the probe to have failed before we restart it.