CKAD exam Preparation Notes - Readiness Probes, Liveness Probe and Logging - Part 4
In the last part, we have covered the Resource Requirements, Service Accounts, Taints and Tolerations, Node Affinity, Multi-Container Pods, and Init-Containers. This part will cover Readiness Probes, Liveness Probe, and basic Logging in Kubernetes.
Readiness Probe
There are some scenarios where the application requires additional data or configuration to load during the startup process.
During this time, the applications seem to be up and running but not ready to serve the requests.
In such cases, we don’t want to send the requests to the application container until it’s ready to serve the traffic.
Kubernetes provides ReadinessProbe to detect and mitigate this situation. A container reporting that they are not ready does not receive the traffic through Kubernetes services.
Types of Readiness Probe
HTTP Probe: For an HTTP probe, kubelet sends an HTTP request to a specified port and path to perform the check.
Command/Exec: The command probe will run a command inside the container. The container is marked as healthy if the command returns the exit code 0.
TCP Probe: For the TCP probe, kubelet tried to establish a TCP connection on the specified port. If it can establish a connection, the container is considered healthy; if it can’t, it is considered unhealthy.
gRPC: Check the gRPC health check for the application that supports gRPC. This new type of probe came with Kubernetes v1.23 and is currently out of the CKAD exam scope.
There are five configurable fields to precisely control the behavior of the probe.
initialDelaySeconds
: The probe will start running after initialDelaySeconds after the container start.periodSeconds
: How often (in seconds) to perform the probe. Default to 10 seconds. The minimum value is 1.timeoutSeconds
: Duration of probe timeout. Defaults to 1 second. The minimum value is 1.successThreshold
: Number of times probe should be successful to mark container health/ready. The default and minimum are 1.failureThreshold
: Number of times the probe should fail to mark the container unhealthy/not ready. The default is 3, and the minimum is 1.
Configuring Readiness Probe
HTTP Probe
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
resources: {}
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 3
periodSeconds: 3
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
Command/Exec Probe
readinessProbe:
exec:
command:
- ls
- /etc/nginx/nginx.conf
initialDelaySeconds: 3
periodSeconds: 3
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
TCP Probe
readinessProbe:
tcpSocket:
host:
port: 80
initialDelaySeconds: 1
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
Liveness Probe
Sometimes applications crash after running for a longer period due to race conditions, deadlocks, or corrupted caches and cannot recover except by being restarted.
Liveness allows us to monitor scenarios where we can distinguish between healthy and unhealthy containers.
If a container fails the liveness probe, that particular container will be restarted, not the pod.
All the **probe types ** and fields I mentioned for the ReadinessProbe also apply to the LivenessProbe.
Configuring Liveness Probe
HTTP Probe
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
resources: {}
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 3
periodSeconds: 3
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
Command/Exec Probe
livenessProbe:
exec:
command:
- ls
- /etc/nginx/nginx.conf
initialDelaySeconds: 3
periodSeconds: 3
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
TPC Probe
livenessProbe:
tcpSocket:
host:
port: 80
initialDelaySeconds: 1
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
Logging
Checking the Kubernetes pods and container logs can be done using the following command.
kubectl logs <pod-name> <container-name>
In the exam, you can expect questions like exporting the logs of a pod or container to a file in the specified path. Something similar to this:
kubectl logs nginx-pod > /logs/nginx-logs.txt
Practice Question
Create a pod with command
sleep 3600
, imagebusybox
, and exec readinessProbe that runs the commandecho I'm ready
Create a pod with
nginx
image and TCP livenessProbe onport: 80
andpath: /
.
That’s all for this part, and In the next part, we will cover topics like Labels, Selectors and Annotations, Jobs and CronJobs, etc.
To be continued..!!