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

1. HTTP Probe: For an HTTP probe, kubelet sends an HTTP request to a specified port and path to perform the check.

2. 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.

3. 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.

4. 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

1. Create a pod with command sleep 3600, image busybox, and exec readinessProbe that runs the command echo I'm ready

2. Create a pod with nginx image and TCP livenessProbe on port: 80 and path: / .

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..!!