Multiple parts of an application running in multiple containers are hard to manage. A big reason is that there are many moving parts of that application that all need to work for an application to function. If a small part breaks, the system has to detect, route it and fix it. All this needs to be done automatically.
Kubernetes provides us Health Checks to let a system know if the app is working or not. It should also make sure that if the app is not working, the requests should be routed and also the system should bring the application back to a healthy state.
Kubernetes provides us with 3 types of probes
Liveness Probe
Readiness Probe
Startup probe
Liveness probe : This indicates whether the container is running or not. This means to check if the application is up and running inside the container. If this probe fails, the kubelet will kill the pod as defined by its restart policy. If the pod is not defined with the liveness probe, the default is success.
Imagine a case where the application running inside the container has a deadlock. The app is hung at this moment but since the process is running, the requests are sent to this pod. This is where liveness probe comes into picture. K8s will hit the application as a part of liveness probe and based on the response the requests are sent. If the liveness probe fails the pod is restarted based on the restart policy that we define.the liveness probe looks as below,
[root@manja17-I13330 kubenetes-config]# cat liveness-pod.yml
apiVersion: v1
kind: Pod
metadata:
name: testing-service
spec:
containers:
- name: test-ser
image: docker.io/jagadesh1982/testing-service
ports:
- containerPort: 9876
livenessProbe:
initialDelaySeconds: 2
periodSeconds: 5
httpGet:
path: /info
port: 9876
Readiness Probe : This probe indicates if the container is ready to accept the request are not. This probe is designed to let kubernetes know whether the app is ready to serve the traffic or not. If the readiness probe fails, the endpoint controller removes the pods IP address from the endpoint of all services that match the pod. Kubernetes makes sure the readiness probe passes before allowing a service to send traffic to the pod. The default state of the readiness probe before the initial delay is Failure. If the container does not specify any readiness probe, the default statue is Success. A simple readiness probe looks as below,
[root@manja17-I13330 kubenetes-config]# cat readiness-pod.yml
apiVersion: v1
kind: Pod
metadata:
name: testing-service
spec:
containers:
- name: test-ser
image: docker.io/jagadesh1982/testing-service
ports:
- containerPort: 9876
readinessProbe:
initialDelaySeconds: 1
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
exec:
command:
- cat
- /etc/nginx/nginx.conf
Startup probe : This indicates whether the application in the container is started or not. If the Startup probe is defined , all other probes are disabled until the startup probe is successful. If the probe fails, the kubelet will kill the container based on the restart policy. Consider legacy applications where they require some time to startup which means the boot time is more or it may be a case where the first time initialization is more. In these cases setting up the live probe can be hard based on the time. This is where startup probe helps. A simple startup probe looks as below,
[root@manja17-I13330 kubenetes-config]# cat startup-pod.yml
apiVersion: v1
kind: Pod
metadata:
name: testing-service
spec:
containers:
- name: test-ser
image: docker.io/jagadesh1982/testing-service
ports:
- containerPort: 9876
startupProbe:
httpGet:
path: /info
port: 9876
failureThreshold: 30
periodSeconds: 10
In the above code, the startup time is with failureThreshold * periodSeconds which means in the above case it is 30 * 10 = 300ms.
Hope this helps in understanding the Probes available in kubernetes.
No comments :
Post a Comment