Intro


In December 2019 I was fortunate enough to attend the Attacking and Defending Kubernetes Clusters workshop at CactusCon 2019 and was completely blown away. Jimmy Mesta did an excellent job creating the content and activities for this workshop. Without a doubt the experience was instrumental in helping me demystify container orchestration and firmly setting me down the DevOps/SecDevOps path. For those curious the documentation and scenarios for the workshop can be found at securekubernetes.com and at this Github repo. Since then passing the Certified Kubernetes Administrator and Certified Kubernetes Application Developer exams have been at the top of my list of priorities, and a nifty little web-application named Game of Pods has been one of my go-to tools for studying. Plus, it's a lot of fun.

Before we dive into the subject matter, let cover some basics. Kubernetes is certainly a hot-topic in the tech industry at the moment and yet ‘container orchestration’ still remains a very abstract concept for the tech industry at large. For the uninitiated I'll take a moment to review what containers are and what ‘container orchestration’ means in the context of Kubernetes.

What are Containers?


There are two fundamental parts that make up every computer:

Hardware: A collection of parts that make up the physical form and attributes of the device. (e.g. microchips, processors, video cards, etc.)

Software: Code that has been designed to control and take advantage of a set of hardware. (e.g. Windows, MacOS, Microsoft Office, etc.)

This is not limited to computers and laptops, but also applies to smartphones, cars, printers, and even some refrigerators. Arguably, the most important piece of software on any computer is the Operating System's Kernel. An Operating System's (e.g MacOS, Linux or Windows) kernel defines its character, things like how to control hardware, what kind of programs it knows how to run, and a laundry list of other attributes. This is one of the primary reasons it isn't possible to simply install a MacOS application on Linux or a Linux application on Windows (yet…). When the need arises to run an application that requires a different OS or creates an unstable, insecure or unorganized environment when running on a particular machine and purchasing a dedicated computer isn't feasible, many people turn to Virtual Machines or Hardware Emulators. Since we know how the microchips and processors that make up computer hardware works, talented programmers have made it possible to write software programs that can imitate hardware, making it possible to do things like run Windows and its applications within a Virtual Machine running on MacOS. The most well-known offerings within this software category being VMWare, Parallels, HyperV, Virtualbox and KVM/QEMU.

You still with me? Ok, good! As you might be able to conclude, running a Virtual Machine on a computer can use quite a bit of resources. Additionally, the time it takes to set up a virtual machine, install the necessary software components, connect it to a network and ensure that everything works can be an extremely time-consuming, precarious and messy process. This is where Containers come in. So we roughly understand what the kernel is, yeah? Well, who says the Operating System to kernel ratio has to be 1 to 1? Instead of emulating hardware with Virtual Machines, a container makes it possible to run a small, lightweight version of your operating system that shares the kernel of the parent OS but has its own file system, virtual network interface and can be quickly created or destroyed at will. Instead of enduring the lengthy process of installing an Operating System in a Virtual Machine, a container uses an Image to define what operating system and application will run. This makes it possible to create an image with an application and its code pre-defined, send it to another location and run it within a container on a completely different computer, as well as destroy or re-create it at will from the image without worrying about complex installations, spreading extraneous files across the system or various software conflicts. The benefits have extended past just software developers and now have yielded dividends for the everyday computer nerd. Want to run an ad-blocker on your home network? There's a container for that. How about your own VPN server to secure your web browsing activity while traveling? There are several containers for that, too. Docker, the organization that created one of the first and most popular mainstream container products, hosts an entire library of container images you can use to do just about anything. From hosting your own Wordpress blog to running a cache for all of your Steam games on your home network and pulling games on the fly to play on Steam in a GPU-accelerated container, and everything in between. Also, If you're wondering, this blog is in fact running in a container. We're in a golden age of computing where anyone with a little know-how can become their own private cloud provider.

Why Kubernetes?


For better or for worse, there are several software offerings that facilitate running containers on a machine, including but not limited to the aforementioned Docker, LXD, Podman and Systemd-nspawn, each with their own unique commands and nuances. Adding the complexity of monitoring our containers to ensure they only have access to the appropriate resources and are running at an optimal state, running containers at any scale can quickly become a hydra's nest of problems. This is where Kubernetes earns its keep. Kubernetes is to containers as a conductor is to an orchestra (hence ‘container orchestration’). It does an amazing job at maintaining the uptime of several interconnected containers that provide a single application (a Pod), allowing fine-tuned access to drive space, allowing granular control of network connectivity and providing Namespaces as a method of controlling access to specific groups of containers and resources. The best part is, instead of running multiple commands from the command line, Kubernetes allows users to define their pods in .yaml files and even does error checking on the file prior to running. I learned how to write effective .yaml in a week and quickly realized that spending 20 minutes fine-tuning a .yaml file once is orders of magnitude more time effective than typing a massive one-liner and praying that it works as intended multiplied by several times a day.

Game of Pods


By and far one of the most enjoyable experiences I've come across during my studies is the Game of Pods scenarios provided for free by KodeKloud, an online learning platform oriented towards DevOps. Game of Pods provides several hands-on scenarios oriented towards preparing aspiring DevOps Engineers (like myself) for the CKA and CKAD exams. The Game of Thrones thematics go deeper than the name. The experience provides an overworld map that mimics Westeros and surrounding lands from the award-winning book and television series.

Each location on the map features a different scenario that challenges users to test their knowledge by troubleshooting and repairing non-functional kubernetes clusters. Within each challenge the provided quiz portal has a Check button that updates you with your progress of repairing the cluster. By clicking one of the web portal tasks, you are given a list of requirements that need to be completed to mark the task as resolved. Each requirement will change its X to a check mark if its done, making it easy to be mindful of your progress while working through the challenges.

Once you've repaired the cluster, the quiz portal gives out a flag in the form of a valerian chant which can be inserted into the scenario's location on the overworld map to confirm its completion. There are videos featuring primers and solutions for each of the beginner scenarios making it easy to pick up the basics of working with a kubernetes cluster. Having the Kubernetes API Reference Manual and the kubectl Cheat Sheet open in separate tabs was a must while working on these challenges, but remembering commands and API conventions stuck relatively quickly.

I'd encourage anyone computer-curious to take a whack at these scenarios and feel free to use the files and scripts I used to complete the challenges in my game-of-pods git repo. I did my best to give brief explanations of the process without totally giving the process away. In future posts I'll do a few tutorials documenting various ways I set up my own kubernetes clusters expand upon what I've learned by experimenting with various applications that can benefit from running on kubernetes.

Since I've been out of work adding kubernetes to my toolbox is one of the most gratifying challenges I've overcome and has given real substance and purpose towards my tech journey. If you also decide to take the dive, hope it does the same for you.

-Heaven