A Kind Demo

kind logo

Most of the DevOps interview assignments involving Kubernetes suggest using minikube. I believe the intent is to gauge a basic understanding of containers and related DevOps tasks. I have skills far from a Kubernetes expert but I hope the interviewing team won’t mind if we do a bit of experimenting.

Looking around, I see there are more options for local Kubernetes clusters. I find the kind project a very promising contender. It’s a bit lighter since it makes use of containers instead of virtual machines. You can also load container images directly into the cluster without fussing with registries. A plus if you just need to work on a local test Kubernetes cluster. Although the project description says it runs Docker container; it runs fine with the experimental podman provider.

This is a Kind demo among other demos.

The assignment

The interviewing team may ask you to write a webserver or app that returns a JSON payload. This app is to be deployed to a Kubernetes test cluster. You can choose whatever stack you like. NodeJS and Go seem popular nowadays. Let’s say we are most comfortable with Go. In the spirit of experimentation; I will also demo a contraption I made with Labstack echo and my project LadyLua. Instead of echo Go code, I will use Lua code to return the required payload for this assignment.

To create the container image I was supposed to demo my lbuildah project and I would normally use the GoogleContainerTools/distroless base for Go code but a “from scratch” base is going to work just fine. The image will also be created using shell scripts through buildah. It can also do images in Dockerfile but I’d like to show a full Dockerless workflow.

The team will almost always also ask you to create a deploy script. Configuration management such as ansible is a popular option. In the past I found similar tools appealing but later I found them more trouble when containers already help with some of the problems they are supposed to solve. Shell scripts are enduring. They can be made maintainable and have ‘idempotent’ capabilities. To put everything together I am going to use my shell script manager rr for some semblance of ‘configuration management’. We could just run the generated shell script but we would lose the pretty STDOUT and STDERR split output.

Tools used or requirements

For a clean slate, I installed Linux on a spare machine. I installed the following software for this demo. I prefer Go software; requirements that are not in the package repositories are just a go build or go install away.

go git buildah podman shellcheck kind rr curl kubectl

Repository tree hierarchy

Once you have the supporting tools everything else is in this Git repository.

├── configs
│   ├── kind.yaml                      ► The Kind configuration
│   └── webserver.yaml                 ► App manifest
├── main
│   └── main.lua                       ► Web app (Lua)
├── main.go                            ► Web app (Go)
├── main_test.go                       ► Unit test
└── scripts                            ► rr scripts
    ├── app                            ► Application namespace
    │   ├── check-pod                  ► Check pod
    │   ├── deploy                     ► Deploy application to cluster in one-shot
    │   ├── test-fail                  ► Test expected failure
    │   ├── test-ok                    ► Test application from outside cluster
    │   └── verify                     ► Verify application
    └── cluster
        ├── create                     ► Create Kind cluster
        ├── verify-ingress             ► Verify ingress setup
        └── verify-nodes               ► Verify Kind nodes setup


It takes around five minutes to start a Kind cluster on my machine. We’ll just show a screenshot of the finished cluster creation. Here are videos of the scripts in action.

Cluster creation and verification

Application deployment and verification


Apparently, we can be playful and have some fun with Kubernetes. The docs are pretty good now for a beginner to pick up. Impressive tools such as Kind also helps a lot. It’s no longer bothersome to accomplish these kinds of DevOps interview assignments.

All tasks, payloads, and scenarios in this post are for entertainment purposes and any similarity to any DevOps interview assignment, or to any actual assignment, is intentional and anything but coincidential.

See also