DEV Community

Cover image for Why Your Kubernetes Lab Needs a Verify Script
Sanjeev Kumar
Sanjeev Kumar

Posted on

Why Your Kubernetes Lab Needs a Verify Script

#automation #devops #kubernetes #tutorial

Most Kubernetes tutorials show you the output you should see. You run the command, compare your terminal with the screenshot, and move on.

The comparison is the weak part. Your output can look the same and your cluster can still be in the wrong state. A pod is still starting. A label matches a pod from an earlier lab. You scaled something down and forgot. Nothing in the tutorial can tell you.

So every lab in my Kubernetes series ends with a verify.sh. It checks the cluster and says which check failed, with a hint.

What a check looks like

Each lab's script is a list of checks. This is one from lab 1, copied from the repo:

check "nginx-deployment exists" \
  "kubectl get deploy nginx-deployment" \
  "kubectl apply -f manifests/nginx-deployment.yaml"
Enter fullscreen mode Exit fullscreen mode

A description, a command that must succeed, and a hint to show when it does not. Lab 1 has seven checks. They cover whether a cluster is reachable, whether the Deployment exists and asks for at least 3 replicas, whether every replica is ready, whether the pods are exactly the Deployment's pods, whether nginx answers inside them, and whether the image is the pinned one from the manifest.

The script checks the state of the cluster, not the commands you typed. You can get to the same state by different routes, and the script passes either way.

Before, after, and broken

Before you do the lab, a cluster is reachable and nothing else is true:

Episode 1: What Is Kubernetes

  PASS  a cluster is reachable
  FAIL  nginx-deployment exists
        hint: kubectl apply -f manifests/nginx-deployment.yaml
  FAIL  it asks for at least 3 replicas
        hint: the manifest declares 3; you may have scaled it below that
  ...

6 of 7 checks failed.
Enter fullscreen mode Exit fullscreen mode

After you apply the manifest and the rollout finishes:

  PASS  a cluster is reachable
  PASS  nginx-deployment exists
  PASS  it asks for at least 3 replicas
  PASS  every replica it asks for is ready
  PASS  the pods with app=nginx are exactly the Deployment's pods
  PASS  nginx answers inside the pods
  PASS  the image is the pinned one from the manifest

All 7 checks passed.
Enter fullscreen mode Exit fullscreen mode

Then break it on purpose. Scale the Deployment down to 2 and run the script again:

kubectl scale deployment nginx-deployment --replicas=2
./verify.sh
Enter fullscreen mode Exit fullscreen mode

Output of verify.sh with one failing check: it asks for at least 3 replicas

One check fails and the hint points at the cause. The other six still pass, which tells you the cluster is otherwise healthy. That is more useful than a screenshot, because it narrows down where to look.

Try it

You need Docker, kind and kubectl. The labs are validated on Kubernetes 1.37 with Kind v0.33.0.

git clone https://github.com/sanjeevkkansal/kubernetes-unlocked.git
cd kubernetes-unlocked
./cluster/up.sh
cd episodes/01-what-is-kubernetes
Enter fullscreen mode Exit fullscreen mode

Follow the lab README, then run ./verify.sh.

Limits

I have tested this on macOS and Linux. Windows with WSL2 is untested. There is no automated test run for the labs yet, so a Kubernetes version other than 1.37 may behave differently.

If a lab does not work for you, open an issue with the step you were on and what verify.sh printed.

Where this goes

The repo has four labs so far: what Kubernetes is, a three-node Kind cluster, the architecture found on a real cluster, and pods, including how to read a CrashLoopBackOff. Each one has a video as well, but each lab works without it.

The code is MIT licensed and the written material is CC BY 4.0.

Top comments (0)