Deploying on Kubernetes #1: The use case

💡 I am now writing at andrewhowden.com. Check out this article over there!

Assumptions

To read this, it’s expected that you’re familiar with Docker and have perhaps played with building Docker containers. Additionally, some experience with docker-compose is perhaps helpful, though not immediately related.

Why Kubernetes?

Kubernetes is a tool for managing docker containers. In turn, docker containers are packaged versions of software. Docker is unique in that it packs software + everything a software needs to execute into a single image, which can then be deployed onto any machine — without the inherent complication of preparing that machine first.

It solves several issues such as package conflicts, deploying testable units of software and replicating environments from testing through to production.

Another post more deeply compares automation approaches, and the infamous Borg paper approaches the problems of and solutions to managing software in this way.

Picking an application

Broadly, any application can be deployed onto Kubernetes. Further, after working with it for a couple of years, as well as working primarily with Ansible as another model of managing software, I’m comfortable that Kubernetes does not present any additional challenge of managing some software in comparison to Ansible, given similar knowledge in both.

However, at this moment I have a particular piece of software that I would like to deploy as part of ongoing trials to increase our visibility across the fleet of machines we manage. In particular, I would like to deploy the tool Kolide/fleet such that we can more effectively manage the OSQuery installations on some nodes, as part of our ongoing trial of OSQuery.

It seems reasonable to deploy this software onto Kubernetes as the cluster has spare capacity, and Kubernetes is a reliable way to manage this stack.

Requirements

Kollide Fleet is a fairly simple application consisting of:

• The fleet binary (a web server)
• MySQL or a MySQL compatible database
• Redis

Additionally, it requires some configuration to get up and running. The configuration can be stored via yaml file, and includes a number of different configuration options associated with specifying the MySQL db and the RedisDB.

It optionally tunnels it’s web connection over HTTP, and it should be possible to supply appropriate TLS credentials optionally. However, Kollide does not currently support mutual TLS authentication, instead authenticating simply with a shared secret.

General Design

Container

There is already a supported docker container, so I will use this.

Kubernetes configuration

As a general rule I will structure my Kubernetes projects as a helm chart. Kubernetes involves a lot of configuration (all in yaml), and the project helm provides some nice primitives to manage that across installations. It packages applications into a format called a “chart”, which can be thought of as the Kubernetes version of a .deb or a .rpm package.

I have a template for helm charts that I start with, but the goal is to submit this as a package to the helm charts repository so I will keep as close as I can to the style common to these charts.

Helm provides existing charts for both MySQL and Redis. I can take these charts and include them in my own chart as a dependency. This dramatically reduces the work required to host it.

The root of the chart will be the definition for kolide/fleet. kolide/fleet seems to require an install step for which I will use the post-install hook and simply allow the running kolide/fleet resource to crash while it installs. I do not think H/A is a good idea at this point.

Lastly, kolide does not appear to store any state on the filesystem, which is nice, so it appears I do not have to worry so much about persistent storage.

Definition of Done

1. It should be possible to install a kolide/fleet server easily with:

helm install stable/kolide-fleet

and that server be “production ready”. No configuration should be required, and random credentials used where passwords are required. Instructions on enrolling OSQuery should be printed on the successful release.

2. It should be possible to minimally extend that installation such that it can fit into the primitives for backup and restoration that we already have (namely, logical volume snapshots)

3. It should be possible to modify all configuration options for kolide/fleet.

In Conclusion

Kubernetes provides an exciting new model of managing software, with some unique challenges. This series will explore some of these challenges, as well as the approaches that I tend to advocate.

Want more? You can check out the whole series on andrewhowden.com.