GoKawiilThis post requires JavaScript The demos in this article need JavaScript to function. I know this isn’t what you want to hear, and I’m sorry. If you don’t want to read on because of that, no hard feelings. The demos are pretty cool, though.
I’m going to show you, really show you, how probes work in Kubernetes. How they can make your application more resilient, and how they can help you prevent avoidable mistakes. Like restart loops that take hours to recover from, and dropping requests during rollouts.
Every interactive demo in this post uses webernetes, my partial port of the Kubernetes to TypeScript. It contains more than 100,000 lines of ported Kubernetes Go code to run a simulated cluster right here in your browser. I verified the behaviour of these demos against k3s and managed to find a bug in Kubernetes! More on that later.
What you will learn The 3 types of probe and what they’re for. How to configure and combine them. How common misconfigurations fail. How probes affect Deployment speed.
Bookmark this section A pod without probes
I want to run a pod with a single container. Here’s its manifest, pod-a.yaml :
pod-a.yaml 1 apiVersion : "v1" 2 kind : "Pod" 3 metadata : ⋯ 4 name : "pod-a" 5 spec : ⋯ 6 containers : ⋯ 7 - name : "app" ⋯ 8 image : "my-app:latest"
This image, my-app:latest , spends a few seconds initialising before listening on port 8080. You will see this below when you click restart to send the container a signal, causing it to crash and get started back up by Kubernetes. You can pause or reset any demo at any time.
node-1 Reset cluster Pause cluster 0 / 2 Restart container Not yet complete. Restart container
After the first crash, the container restarts straight away. After the second, Kubernetes imposes a CrashLoopBackOff on it before starting it again. By default this delay is 10 seconds, doubling with each crash up to a maximum wait of 5 minutes. I shortened it to 3 seconds for this demo.
... continue reading