Healthy microservices with Cellery

Cellery bestows a code-first approach to deploy, manage, and scale microservices. This article will overlook the aspects of defining health checks for microservices(components).

Cellery uses Kubernetes probes underneath for health checking. Thus Cellery supports two types of probes.

1. Liveness Probe

Many applications running for long periods eventually transition to broken states, and cannot recover except by being restarted. Liveness probes are used to detect and remedy such situations.

2. Readiness Probe

The readiness probes are used to know when a component is ready to start accepting traffic. A Cell is considered ready when all of its components are ready. When a Cell is not ready, it is removed from Service load balancers.

Both probes support 3 types of health checks.

1. Socket based health check (TCP Socket)
2. HTTP based health check (HTTP GET)
3. Command based (Exec)

All the probes have the following common properties.

• initialDelaySeconds:The waiting period before the first health check action. The default value is 0s;
• periodSeconds:The gap between the two health checks. The default value is 10s;
• timeoutSeconds:Number of seconds after which the probe times out. Defaults to 1s;
• failureThreshold: When a cell starts and the check fails, it will try failureThreshold time before giving up. Defaults to 3s;
• successThreshold: Minimum consecutive successes for the health check to be considered successful after having failed. Defaults to 1.

The examples below will use the following cell to demonstrate probes.

employee cell

1. Socket based health check (TCP Socket)

The health check can be defined as a TCP socket connection. The following sample shows how to define a socket-based readiness probe for a cell component.

A readiness probe for employee component is added in employee port (8080). The employee component will be checked after 30 seconds whether the port is accessible. Until that the cell will be in the not ready state. At the runtime failureThreshold is increased to 5. The final generated yaml would like below.

2. HTTP based health check

The liveness health check can be defined as an HTTP GET request connection. The following sample shows how.

The initialDelaySeconds field denotes that the first probe should be performed after 30 seconds. An HTTP GET request is sent to the server that is running in the component and listening on port 8080. If the employee service's /details the path returns a success code, the component is considered healthy. If it returns a failure code, the component will be killed and restarted. Any code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure.

The corresponding yaml is as below with the default values.

3. Command based (Exec)

These probes allow defining a command to be executed to check the liveness/readiness. The following are the syntax for defining a command based probe for cells.

In the above sample, the echo 0 > /dev/tcp/127.0.0.1/8080 command is executed after 30 seconds after the component is active.

The generated yaml will be as follows.

Conclusion

Cellery provides a code-based approach to define healthy microservices. For more samples and features visit Cellery samples repo.