Kubernetes Readiness & Liveliness Probes -Best Practices

Distributed system can be hard to manage a big reason that they are many moving parts all need to work in-order to a system to be function.
For part breaks the system has detected route around it & fix it. This all need to be done automatically.

What is health checks?

Health check are simple way to you system works with the application works or not. If your instance of your application not working so other services should not access it or send requests to it.
Instead your request to be sent to a another instance of the application which is working or retried. The system should bring your application to healthy state by default kubernetes try to send traffic to a pod.
When all the containers inside that pod starts & restart the container when they crash.
All this defalut behaviour can be good enough when you starting out. you can make your deployments more roboust by creating custom health check.
Thankfully kubernetes makes it straight forward.

Types of health checks.

There are 2 types of health checks

1. Readiness Probs :- They are designed to kubernetes know when application is ready to server the request. Kubernetes will make sure that the probe passes before allowing a service to send traffic to pod in deployment. If is start to fail kubernetes will stop sending traffic to the pods until the prob passes again.
2. Liveness Prob :- This is designed for lets kubernetes knows they are alive or not. if application is alive then kubernetes leaves it alone. if application is dead kubernetes will remove the pod & start new pod.

If application takes minute to warm-up & start then service won’t work until it’s running even though the process already started. If you have multiple copies of application here your application should not receive full copy of application ready to serve the request. But as process is started inside container kubernetes will try to send traffic to pod.
By using readiness prob kubernetes will wait until the application is ready to serve the request.

If application dead inside pod but kubernetes try to send the traffic to pod. by using liveness porb kubernetes will detect the app is no longer to serve the request & restart the offending pod by default.

There are 3 types of Probs:

1. HTTP:-

Kubernetes will ping a path will get response 200 or 300 range it will mark it as healthy otherwise unhealthy.

specs:
   containers:
   - name: liveness
     livenessProb:
    httpGet:
      path: /healthz
      port: 80

2. Command:-

Here kubernetes will run a command inside a container if command return with exit code=0 then it marked as healthy otherwise unhealthy. This is useful when you don’t want to run HTTP probs to check healthy or not just you can run command inside container & check it is healthy or not.

specs:
   containers:
   - name: liveness
     livenessProb:
     exec: 
     commond: 
     - command

3. TCP:-

Here kubernetes will try to establish the tcp connection to the define port. if connection established then pod is healthy if not then it’s not healthy.

specs:
   containers:
   - name: liveness
     livenessProb:
       tcpSocket:
         port: 80

Here GRPC & FTP service are main services for this prob.

Configuring Probs:-

1. initialDealySeconds:
2. periodSeconds:
3. timeoutSeconds:
4. successThreshold:
5. failureThreshold:

Very important setting you have to setup while Liveness porb is “initialDealySeconds”