by Daniel Southward-Ellis
Over the summer break between 2021 and 2022 I was offered the opportunity to work as a cloud native intern at Catalyst. The position would involve improving Cove, Catalyst's platform as a service built on top of Kubernetes. The project was fascinating but I had never worked with Kubernetes before. To make things more challenging, I couldn't find a simple explanation of what Kubernetes was or how it worked. Luckily it turned out to be easier to learn than I'd feared it would be.
What I knew going in
Before the job I knew that containers were lightweight virtual machines that programs could be installed into and then run from. This avoids the end user needing to install the program themselves which means less work for them. From my research before starting, I knew that Kubernetes was a system that could organize containers running code seamlessly over several machines. It does this by creating and destroying containers and changing how they are connected to bring the whole cluster towards a desired state. So with this understanding I started working on Cove.
Upgrading an Ingress Controller
After getting settled in at Catalyst my first task was to upgrade the version of the ingress controller installed with Cove. This seemed like a simple task (I just needed to change a version number) but it would help me get to grips with how Kubernetes worked.
First I had to figure out how networking works in a Kubernetes cluster and where the ingress controller fit in. I discovered that ingresses are used to direct web traffic to different apps depending on the URL. So if you ran a food blog, you could setup one ingress to send traffic from a recipe page to one service and traffic for the blog list to a different one.
In practice the upgrade turned out to involve a lot more than just changing a number. Upgrading the controller required upgrading other programs that used it. One of these programs had hardcoded a change in recent versions that broke in Cove. Fixing it ended up introducing me to another tool in Cove, Kyverno.
Resources and Kyverno
Everything in Kubernetes, even the machines the cluster runs on, are represented as resources. These describe the state I'd read about before I started. They're written and stored as YAML files which describe a type and all the settings and data needed to create the resource. A big part of getting familiar with Kubernetes was learning all the different resource types and what they did.
Kyverno is a tool that runs in the cluster and can automatically validate or modify resources when they're created or updated. The rules for this are called policies and are also resources in the cluster. Because Kubernetes uses resources for everything, I could write policies to change the values on resources created by another application.
While this turned out to be a less than ideal way to solve the problem, it was a great introduction to how Kubernetes operates. When the state Kubernetes is trying to match changes in quick succession it doesn't try to follow through the changes, it only ever tries to match the current state. This makes testing and development far easier, you only have to worry about what the state looks like now.
Working at Catalyst
Catalyst was a great introduction to different ways to manage software development. While I'd heard of Agile before I started, my internship was a great introduction to this style of working. The team would start each day with a short meeting where we'd share our progress during the previous day and outline our plans for today. These meetings were great to get up to speed on what was happening. While I was working in the office for most of my internship, covid restrictions required that people work from home some days. While this was happening, these meetings and the team's willingness to help out made sure I didn't get lost or stuck.
A different approach to development
Working in the cloud native team was very different to other development work I'd done in the past. Because I was working on systems meant to operate in a cloud environment nothing could be run or tested locally. Everything needed access to the APIs operated by cloud providers to operate. It took me a while to realize that this is part of what "cloud native" means, software purpose built to run in the cloud.
Still there was plenty that I did recognise, Git, merge requests, and tracking down strange bugs. Once I'd learned how things worked and learned all the different languages I found it wasn't so different from the style of programming I was used to. The team were amazing and incredibly helpful as I tried to find my way around the project. Contributing to Cove has been a great experience and I've learned so much from it.