Over the past year containerizing applications has become an extremely popular practice to quickly develop, ship and deploy applications. With the help of containerization tools like Docker, the desired container environment can be described in a declarative manner.
With Kubernetes, containerized applications can be deployed, scaled when needed, and further managed. Kubernetes has self-healing powers for containers — but only works to it’s fully potential when it’s set up right.
In this article, we are going to implement health checks and corresponding probes so that Kubernetes is able to define whether a containerized application is healthy and can act accordingly.
_The implementation examples on the application side are implemented with .NET Core. The theory and implementations can be as well applied to Java/Spring Boot applications. Spring Boot offers the _Actuator module_ to implement comparable functionality that is stated further into this article._
What are Kubernetes probes?
To understand what a probe in Kubernetes context is, it is smart to take a step back and look into what the definition of the word:
verb (used with object), probed, prob·ing.
1. to search into or examine thoroughly; question closely:to probe one’s conscience.
2. to examine or explore with a probe.
verb (used without object), probed, prob·ing.
3. to examine or explore with or as if with a probe.
noun
4. the act of probing.
_Definition by _Dictionary
With the help of the definition above, Kubernetes probes can be defined as an instrument to examine the state of a container. Kubernetes uses this probe functionality to determine if a container and thus the pod is unhealthy and if so, Kubernetes will use its self-healing power. Kubernetes will try to schedule replacement pods to get back to the desired amount of instances(replicas) of pods to get to a healthy state again.
Kubernetes uses probes during a rolling update to determine if the newly deployed pod is up. Only after reporting the new pod up, the old pod will be removed.
Kubernetes has three types of probes that can be declared:
- Liveness Probe: used to determine how alive the container is, regardless of dependencies. This probe is used to check whether the application that runs in the container, is not in an unresponsive state. An application could get into a deadlock state without being able to give any responses back.
- Readiness Probe: used to determine whether the container is ready to accept traffic. The container can enter a non-ready state when external dependencies are failing. For example: when connection to a database has not been successful, the container is determined as alive, but is not ready to accept traffic until the connection has been restored. Non-ready containers won’t be connected to load balancers by Kubernetes.
- Startup Probe: used to determine if the container started up. When configured, liveness and readiness probes are disabled until proper startup. This is to avoid slow-starting containers being killed before properly started up. This probe is available since K8S version 1.16 and in Alpha state.
#kubernetes #dotnet #software-development #cloud #resilience
