January 16, 2017 was just a few months after I first delved into Kubernetes. The container wars had been raging for over a year by then—Docker being the clear winner, but the battle between orchestration solutions hadn’t fully concluded yet. Today, we’re talking about Kubernetes and how it’s slowly becoming the standard.

When I started working with Kubernetes in October 2016, my goal was simple: to deploy and manage containers on a more organized and scalable level. I joined an early adopter team where everyone was still figuring out the nuances of this new world.

The Initial Setup

Setting up a basic cluster was straightforward enough using kubeadm, but it quickly became apparent that the real work lay in understanding how to use Helm to manage applications and services. We spent countless hours wrestling with manifests and trying to figure out how to properly set environment variables. The learning curve was steep; Helm charts were still evolving rapidly, and our initial attempts at creating templates often led to frustration.

Debugging and Troubleshooting

One of the early challenges we faced was troubleshooting issues that seemed to be Kubernetes-specific rather than application-related. For instance, a simple kubectl describe pod command would give us just enough information to understand what was wrong with a pod, but it wasn’t always obvious how to resolve those issues.

We spent quite some time debugging an issue where a deployment wouldn’t scale out as expected. After hours of staring at the logs and adjusting configuration files, we finally discovered that the resource requests for our application were set too low—causing Kubernetes to keep restarting pods instead of scaling them up. This was a humbling moment; it taught me that understanding the underlying principles is just as important as the tools themselves.

The Hype Around Serverless

As 2017 began, there was a lot of hype around serverless computing with AWS Lambda leading the charge. Our team was still focused on Kubernetes, but we couldn’t ignore the potential it held for simplifying our infrastructure. We toyed with the idea of integrating some serverless functions to handle certain edge cases, but ultimately decided that the complexity didn’t justify the benefit at the time.

The GitOps Movement

Around this same period, GitOps was starting to gain traction. The concept of treating your Kubernetes configuration as a code repository appealed to us because it seemed like a natural fit for our version control workflows. However, implementing GitOps required some changes in how we worked. We had to set up a continuous delivery pipeline that could push updates directly into the Kubernetes cluster using tools like Spinnaker or Flux. The initial setup was non-trivial and involved overcoming numerous hurdles.

Personal Reflections

Looking back on that year, it’s clear that Kubernetes was still very much in its early stages. The ecosystem was growing rapidly with new tools and features being released almost daily. As I look at the landscape today, where Kubernetes is practically everywhere, I am reminded of how far we’ve come and how much more there is to learn.

In 2017, I found myself spending a lot of time in the command line, reading documentation, and debugging. Those early days were tough but rewarding. The sense of community among those using Kubernetes was also a highlight; people were eager to share their experiences and help each other out.

As we continue to navigate this ever-evolving landscape, one thing is certain: Kubernetes has firmly established itself as the de facto standard for container orchestration. Whether you’re just starting or are an experienced user, there’s always something new to learn—and that’s what makes it such a compelling journey.

---

This was my year of learning and growing with Kubernetes. What about you? How did 2017 shape your relationship with containers and orchestration?