mirror of
https://github.com/marcel-dempers/docker-development-youtube-series.git
synced 2025-06-06 17:01:30 +00:00
121 lines
3.6 KiB
Markdown
121 lines
3.6 KiB
Markdown
# Introduction to Kubernetes Probes
|
|
|
|
|
|
## Create a kubernetes cluster
|
|
|
|
In this guide we we''ll need a Kubernetes cluster for testing. Let's create one using [kind](https://kind.sigs.k8s.io/) </br>
|
|
|
|
```
|
|
cd kubernetes/probes
|
|
kind create cluster --name demo --image kindest/node:v1.28.0
|
|
```
|
|
|
|
Test the cluster:
|
|
```
|
|
kubectl get nodes
|
|
NAME STATUS ROLES AGE VERSION
|
|
demo-control-plane Ready control-plane 59s v1.28.0
|
|
|
|
```
|
|
|
|
## Applications
|
|
|
|
Client app is used to act as a client that sends web requests :
|
|
|
|
```
|
|
kubectl apply -f client.yaml
|
|
```
|
|
|
|
The server app is the app that will receive web requests:
|
|
|
|
```
|
|
kubectl apply -f server.yaml
|
|
```
|
|
|
|
Test making web requests constantly:
|
|
|
|
```
|
|
while true; do curl http://server; sleep 1s; done
|
|
```
|
|
|
|
Bump the server `version` label up and apply to force a new deployment </br>
|
|
Notice the client throws an error, so traffic is interupted, not good! </br>
|
|
|
|
This is because our new pod during deployment is not ready to take traffic!
|
|
|
|
## Readiness Probes
|
|
|
|
Let's add a readiness probe that tells Kubernetes when we are ready:
|
|
|
|
```
|
|
readinessProbe:
|
|
httpGet:
|
|
path: /
|
|
port: 5000
|
|
initialDelaySeconds: 3
|
|
periodSeconds: 3
|
|
failureThreshold: 3
|
|
```
|
|
|
|
### Automatic failover with Readiness probes
|
|
|
|
Let's pretend our application starts hanging and not longer returns responses </br>
|
|
This is common with some web servers and may need to be manually restarted
|
|
|
|
```
|
|
kubectl exec -it podname -- sh -c "rm /data.txt"
|
|
```
|
|
|
|
Now we will notice our client app starts getting errors. </br>
|
|
Few things to notice:
|
|
|
|
* Our readiness probe detected an issue and removed traffic from the faulty pod.
|
|
* We should be running more than one application so we would be highly available
|
|
|
|
```
|
|
kubectl scale deploy server --replicas 2
|
|
```
|
|
|
|
* Notice traffic comes back as its routed to the healthy pod
|
|
|
|
Fix our old pod: `kubectl exec -it podname -- sh -c "echo 'ok' > /data.txt"` </br>
|
|
|
|
* If we do this again with 2 pods, notice we still get an interuption but our app automaticall stabalises after some time
|
|
* This is because readinessProbe has `failureThreshold` and some failure will be expected before recovery
|
|
* Do not set this `failureThreshold` too low as you may remove traffic frequently. Tune accordingly!
|
|
|
|
Readiness probes help us automatically remove traffic when there are intermittent network issues </br>
|
|
|
|
## Liveness Probes
|
|
|
|
Liveness probe helps us when we cannot automatically recover. </br>
|
|
Let's use the same mechanism to create a vaulty pod:
|
|
|
|
```
|
|
kubectl exec -it podname -- sh -c "rm /data.txt"
|
|
```
|
|
|
|
Our readiness probe has saved us from traffic issues. </br>
|
|
But we want the pod to recover automatically, so let's create livenessProbe:
|
|
|
|
```
|
|
livenessProbe:
|
|
httpGet:
|
|
path: /
|
|
port: 5000
|
|
initialDelaySeconds: 3
|
|
periodSeconds: 4
|
|
failureThreshold: 8
|
|
```
|
|
|
|
Scale back up: `kubectl scale deploy server --replicas 2`
|
|
Create a vaulty pod: `kubectl exec -it podname -- sh -c "rm /data.txt" `
|
|
|
|
If we observe we will notice the readinessProbe saves our traffic, and livenessProbe will eventually replace the bad pod </br>
|
|
|
|
## Startup Probes
|
|
|
|
The [startup probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes) is for slow starting applications </br>
|
|
It's important to understand difference between start up and readiness probes. </br>
|
|
In our examples here, readiness probe acts as a startup probe too, since our app is fairly slow starting! </br>
|
|
This difference is explained in the video. </br> |