Night Vision

After the explosive adoption of containers, resulting in Kubernetes stoically taking the orchestrator reins, a number of useful tools were created in order to assist the orchestrator run containers efficiently. Every possible advantage is welcome when you're trying to keep a critical service online, and StatusBay is "an open source tool that provides the missing visibility into the K8s deployment process" [1].

In this article I look at the clever StatusBay, which is available on GitHub courtesy of an international company called SimilarWeb [2]. According to a posting on Reddit, StatusBay was recently released as open source, having been a tool "that was used internally for a long time now" [3]. To demonstrate StatusBay in action, the tech stack will include a miniscule Kubernetes distribution, K3s [4] (offered by Rancher [5]), to build a Kubernetes cluster, and the Kubernetes package manager, Helm.

A great deal of information about where to begin with K3s can be found in one of my previous articles, "Kubernetes k3s Lightweight Distro" [6], which discusses using the magically tiny K3s within Internet of Things (IoT) applications.

The name of K3s came from Kubernetes' often abbreviated form K8s; according to the docs on the Rancher website, "something half as big as Kubernetes would be a 5-letter word stylized as K3s. There is no long form of K3s and no official pronunciation" [7]. As a certified distribution sitting at less than 50MB (and using less than half the RAM of a standard cluster) the binary that runs K3s is a sight to behold and well worth getting your hands on. Especially when it's deemed production-ready, too.

So I can focus on StatusBay in greater detail, I will zoom through the basic commands required to install K3s, but be warned that some iptables tweaking is required to get certain machines to run K3s as hoped. Kubernetes is renowned for brazenly fiddling with iptables configurations to enable its proxying, so don't despair. My previous article about K3s in IoT that discusses disabling firewalld and tweaking iptables should help. Another top tip I can offer is temporarily resetting your iptables by disabling your firewall (e.g., UFW) and then switching it back on after K3s has installed correctly. Otherwise, handy docs on the K3s site [7] should provide guidance. All in all, a little trial and error should make light work of getting it running once you've spotted which other application is competing for iptables supremacy.

Teeny, Tiny

To get the excellent K3s up and running straightaway, I won't build more than a single master node, referred to as a "K3s server" in the K3s lexicon, to look at StatusBay. A worker node is referred to as an "agent." Again, the terminology is referred to in greater detail in the IoT article.

Downloading and installing K3s surprisingly requires only a single command run as root (so check the script that the command downloads and executes before trusting it implicitly by omitting the sh - after the pipe):

$ curl -sfL https://get.k3s.io | sh -

The website tells you to be a little patient, for about 30 seconds. In Listing 1, you can see what success looks like after the download and installation.

[INFO]  Finding latest release
[INFO]  Using v1.17.3+k3s1 as release
[INFO]  Downloading hash https://github.com/rancher/k3s/releases/download/v1.17.3+k3s1/sha256sum-amd64.txt
[INFO]  Downloading binary https://github.com/rancher/k3s/releases/download/v1.17.3+k3s1/k3s
[INFO]  Verifying binary download
[INFO]  Installing k3s to /usr/local/bin/k3s
chcon: can't apply partial context to unlabelled file '/usr/local/bin/k3s'
[INFO]  Creating /usr/local/bin/kubectl symlink to k3s
[INFO]  Creating /usr/local/bin/crictl symlink to k3s
[INFO]  Skipping /usr/local/bin/ctr symlink to k3s, command exists in PATH at /usr/bin/ctr
[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
[INFO]  Creating uninstall script /usr/local/bin/k3s-uninstall.sh
[INFO]  env: Creating environment file /etc/systemd/system/k3s.service.env
[INFO]  systemd: Creating service file /etc/systemd/system/k3s.service
[INFO]  systemd: Enabling k3s unit
Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service ? /etc/systemd/system/k3s.service.
[INFO]  systemd: Starting k3s

Now, check to see whether a master node is running:

$ k3s kubectl get node
NAME   STATUS   ROLES    AGE   VERSION
echo   Ready    master   53s   v1.17.3+k3s1

Great! A single master node (K3s server) is available. You could easily add agents, if needed.

Take the Helm

As mentioned earlier, to install StatusBay [8] I'll use the venerable Helm and the provided StatusBay Helm chart [9] (Listing 2). Next, install Helm v3.0+, which is quite different from previous versions, so make sure you choose a version above v3.0.

$ git clone https://github.com/similarweb/statusbay-helm.git
Cloning into 'statusbay-helm'...
remote: Enumerating objects: 74, done.
remote: Counting objects: 100% (74/74), done.
remote: Compressing objects: 100% (54/54), done.
remote: Total 371 (delta 32), reused 44 (delta 20), pack-reused 297
Receiving objects: 100% (371/371), 71.24 KiB | 548.00 KiB/s, done.
Resolving deltas: 100% (202/202), done.

To begin, choose the version of Helm that you need from the release page [10]. I'm using Linux Mint 19, which is Ubuntu 18.04 under the bonnet. For security reasons, download and test the SHA256 checksum. The first command (Listing 3) downloads the Helm tarball, and the second downloads the file containing the correct checksum and then uses the cat command to see that file's content (this checksum is also on the GitHub page if you prefer to confirm it there). The third command makes sure the download hasn't been compromised: If the second and third checksum output is the same, then you're cooking with gas and can proceed.

$ wget https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz
$ wget https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz.sha256sum && cat helm-v3.1.2-linux-amd64.tar.gz.sha256sum
[...snip]
e6be589df85076108c33e12e60cfb85dcd82c5d756a6f6ebc8de0ee505c9fd4c  helm-v3.1.2-linux-amd64.tar.gz
$ sha256sum helm-v3.1.2-linux-amd64.tar.gz
e6be589df85076108c33e12e60cfb85dcd82c5d756a6f6ebc8de0ee505c9fd4c  helm-v3.1.2-linux-amd64.tar.gz

To decompress the tarball and copy the helm binary into your path, enter:

$ tar -zxvf helm-v3.1.2-linux-amd64.tar.gz
linux-amd64/
linux-amd64/helm
linux-amd64/README.md
linux-amd64/LICENSE
$ mv linux-amd64/helm /usr/local/bin

From within your home directory, test to see that the Helm binary is now where you want it to be:

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

So Helm knows where to look for the K3s cluster, you need to run the command:

$ export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

Otherwise, you're sure to get errors. Now, you can enter the repository cloned for StatusBay and use the sophisticated Helm to install the chart:

$ cd statusbay-helm/
$ helm install my-release .

Figure 1 shows, along with some excellent ASCII art, what to expect after the very precise Helm has completed its run. A few commands are trimmed from the bottom, which I'll look at more closely in a moment. For now, run the verification command, shown at the bottom of the figure, to prove that StatusBay started properly:

$ kubectl get svc,deployments,pods -l "release=my-release,app=statusbay-helm"

Figure 1: Helm weaving its magic.

If the output from the command doesn't immediately look satisfactory (i.e., if not all pods are fully up and running), you might need to be a bit more patient because a datastore (Redis [11]), among other peripheral components, has to start up before StatusBay is completely available.

Figure 2 shows what to expect when StatusBay is working correctly. As you can see, the STATUS column shows Running for all pods. Now you can open the port for StatusBay with a port-forwarding command:

$ kubectl port-forward svc/my-release-statusbay-helm-ui 3000:80
Forwarding from 127.0.0.1:3000 -> 80
Forwarding from [::1]:3000 -> 80

Figure 2: Displaying services, deployments, and pods for statusbay-helm.

The output from that command reveals that both IPv4 and IPv6 TCP 80 ports have been prised open and then forwarded to TCP port 3000. To access StatusBay, enter http://127.0.0.1:3000 in your Browser.

In Google Chrome – Linux Mint 19, Version 70.0.3538.102 (Official Build) (64-bit) – I saw a nice animation and header and then a blank screen. However, in Firefox – 74.0 (64-bit) – on the same machine, the display is more cogent (Figure 3), showing the friendly animation in action as StatusBay starts up.

Figure 3: The entry screen for StatusBay in Firefox.

Shed Some Light

To get the best from StatusBay, try to deploy something in your Kubernetes cluster. The Kubernetes site has a simple nginx example deployment [12]. Save that YAML file [13] carefully and, assuming you called that file nginx.yaml, run the command:

$ kubectl create -f nginx.yaml
deployment.apps/nginx-deployment created

StatusBay shows what happens as the Nginx deployment, with a whirling progress icon, starts up (Figure 4) and as you drill down into the deployment (Figure 5). The details are based around the CREATE/UPDATE/DELETE resources in Kubernetes, so you now have a historical list of the Kubernetes events that is easy to reference and scrutinize.

Figure 4: StatusBay shows that, besides itself, nginx-deployment is running.

Figure 5: The Nginx deployment in detail.

According to the GitHub page [14], StatusBay watches for a number of Kubernetes events, outputs them through the user interface (UI), and monitors "the progress of all the resource kinds (deployment, statefulset, daemonset, etc.) associated with that deployment, notifies the relevant persona on success/failure/timeout and provides detailed reports through the UI."