Kube-Demo
BOINC
When looking for a demo workload to use in demonstrating Kubernetes on this low budget cluster, I decided that I would at least try to lend a hand where I can to help with the pandemic. I decided to use 2 BOINC projects Rosetta@Home and OpenPandemics. Both of these projects are working to help scientists to find a cure or vaccines. Both of these projects use a system known as BOINC(Berkeley Open Infrastructure for Network Computing). BOINC allows volunteers to run distributed computations for projects in a sandboxed environment. It exists for Windows, Linux, macOS, and Android. The Boinc people have an official docker container image on the docker hub. I picked this as an easy way to demonstrate manifests and container deployment on Kubernetes.
DOCKER
Having an official image to start with definitely made it easier to get the effort going. On docker hub the BOINC page lists a number of containers. It appears that most of the tags relate to GPU optimization in each container. Since the VMs that the Kubernetes cluster is running on have no GPUs, I chose the "latest" tag which is the same as the "baseimage-ubuntu" according to the digest. It also appears that there are container images for 32 and 64-bit arm platforms.KUBERNETES
With the official docker hub container to start with, it was a fairly simple matter to come up with a manifest to deploy the container to the cluster. One of the problems with the container label is that Kubernetes uses the label to decide if the container in the repo has changed. Since the label used by the container creators is "latest", that means that the container from Kubernetes' point of view is ALWAYS current. A workaround to this is to do one of two things (from the Kubernetes configuration best practices doc):imagePullPolicy: Always: every time the kubelet launches a container, the kubelet queries the container image registry to resolve the name to an image digest. If the kubelet has a container image with that exact digest cached locally, the kubelet uses its cached image; otherwise, the kubelet downloads (pulls) the image with the resolved digest, and uses that image to launch the container.
imagePullPolicy is omitted and either the image tag is :latest or it is omitted: Always is applied.
I chose to use "imagePullPolicy: Always" since I believe listing it explicitly makes it easier to understand.
Now one approach is to just issue patches against the manifest every so often to make Kubernetes go check for itself. Somehow that felt like using a sledgehammer to drive a tack. I then discovered that there was no real good way to check the hash on the docker repo without having Docker installed locally. Since the machine I was using only had 2G ram total to manage the OpenNebula cluster and run the CD stuff, I felt that installing Docker simply to check a hash value was also overkill. So I created my first opensource project in GitHub: docker-repo-info. Docker-repo-info uses the Docker repo API to fetch metadata about repositories and tags. One of the programs in the package "etagcli" simply takes the repo name, container and tag and returns the hash associated with that container. This can easily be put in a bash script to trigger and rolling upgrade using kubectl.
If you are interested in the nitty-gritty of how this was implemented check out these pages:
Live Pod Deployments
Poor Mans Continuous Deployment
