Day-6-Kubernetes

TLDR: This blog post explores Kubernetes health probes, specifically readiness and liveness probes, detailing their functions, practical implementations, and the importance of these components in managing containerized applications.

Welcome back to the Kubernetes series. In this sixth installment, we will delve into the concept of health probes in Kubernetes. If you are new to this series, I recommend watching the previous video where we discussed Ingress, private SSL keys, TLS secrets, and deployed a voting application using Docker.

What Are Health Probes?

Health probes are essential components in Kubernetes that help manage the lifecycle of containers within pods. They allow Kubernetes to determine the health status of containers and take appropriate actions based on that status. There are three main types of health probes:

1. Readiness Probe

2. Liveness Probe

3. Startup Probe

Readiness Probe

The readiness probe checks if a container is ready to accept traffic. If a container fails this probe, Kubernetes will stop routing traffic to it, ensuring that users do not experience downtime or errors. However, it is important to note that the readiness probe does not restart the container; it merely informs Kubernetes that the container is not ready to serve requests.

Liveness Probe

The liveness probe, on the other hand, checks if a container is still running. If this probe fails, Kubernetes will restart the container, allowing it to recover from issues that may have caused it to become unresponsive. This is crucial for maintaining the availability of applications.

Startup Probe

The startup probe is primarily used for legacy applications that may take longer to start. It is designed to ensure that the application is fully initialized before the readiness and liveness probes are applied. This probe is particularly useful for applications that require a significant amount of time to boot up.

How Health Probes Work

To understand how health probes function, consider a scenario where a user attempts to access an application running in a container. If one of the containers is down due to network issues or other reasons, Kubernetes needs to know this to take appropriate action. This is where health probes come into play.

The Role of Kubelet

Kubelet is a key component in each node that monitors the health of containers. It relies on health probes to determine whether a container is serving traffic correctly. If a container is not functioning as expected, Kubelet will take action based on the type of probe that has failed.

Practical Implementation of Health Probes

Let’s move on to the practical aspect of implementing health probes in a Kubernetes deployment. We will create a deployment that includes both readiness and liveness probes.

Setting Up the Deployment

1. Create a Deployment: We will create a deployment with three replicas of a sample application. The deployment YAML file will include the readiness and liveness probes.

2. Readiness Probe Configuration: The readiness probe will be configured to check if the container is ready to accept traffic by sending an HTTP GET request to a specific path (e.g., /index.html).

3. Liveness Probe Configuration: The liveness probe will be set up similarly but will restart the container if it fails.

Example YAML Configuration

Here is a simplified example of how the deployment YAML might look:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-one
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-one
  template:
    metadata:
      labels:
        app: app-one
    spec:
      containers:
      - name: app-container
        image: your-image
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 15
          periodSeconds: 20

Testing the Probes

After deploying the application, we can test the functionality of the probes by simulating a failure:

• Remove the index.html file from the container to simulate an unresponsive state.

• Observe how the readiness probe prevents traffic from being routed to the affected container while the liveness probe restarts it.

Conclusion

In summary, health probes in Kubernetes are vital for maintaining the health and availability of applications. The readiness probe ensures that traffic is only routed to containers that are ready, while the liveness probe automatically restarts containers that are not functioning correctly. Understanding and implementing these probes effectively can significantly enhance the reliability of your applications.

In the next session, we will explore sidecar containers, resource quotas, and cron jobs. Thank you for joining me today, and don't forget to subscribe for more insights into Kubernetes and container management!

# login to management server
kubectl cluster-info
kubectl get nodes -o wide

kubectl create deployment app1 --image kiran2361993/kubegame:v1 --replicas 3 --dry-run -o yaml

# readinessProbe
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-one
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-one
  template:
    metadata:
      labels:
        app: app-one
    spec:
      containers:
      - name: app-container
        image: your-image
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10

echo "<paste yml>" | kubectl apply -f -
kubectl get pods

# create duplicate tab of management server 
sudo su -
watch kubectl get pods # after deleting index file of both 1st and 2nd pod -> ready : 0/1 (not serving)

# login to 1st pod in original management server and remove index files, so that pod will stop working
kubectl exec -it <deployment-replica-pod_name> --bash
ls -al
cd /var/www/html
ls -al
rm -rf index*

# login to 2nd pod in original management server and remove index files, so that pod will stop working
kubectl exec -it <deployment-replica-pod_name> --bash
ls -al
cd /var/www/html
ls -al
rm -rf index*

# readinessProbe
# livenessProbe
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-one
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-one
  template:
    metadata:
      labels:
        app: app-one
    spec:
      containers:
      - name: app-container
        image: your-image
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 15 # after 15 sec -> [ready : 0/1 (restart will start after it reaches to 15sec) -> ready : 1/1]
          periodSeconds: 20

echo "<paste yml>" | kubectl apply -f -
kubectl get pods

# create duplicate tab of management server 
sudo su -
watch kubectl get pods # after deleting index file of both 1st and 2nd pod -> ready : 0/1 (not serving)
# initialDelaySeconds: 15 ->  ready : 0/1 -> ready : 1/1 

# login to 1st pod in original management server and remove index files, so that pod will stop working
kubectl exec -it <deployment-replica-pod_name> --bash
ls -al
cd /var/www/html
ls -al
rm -rf index*

# login to 2nd pod in original management server and remove index files, so that pod will stop working
kubectl exec -it <deployment-replica-pod_name> --bash
ls -al
cd /var/www/html
ls -al
rm -rf index*