What Makes Kubernetes Difficult For Beginners?

I just finished teaching a two-day Kubernetes workshop, and I had a few surprises.

This wasn’t my first time presenting a technical topic in front of people, but this was my first time teaching a class of 20+ developers how to use Kubernetes effectively in their daily jobs.

Without going into too many details about the difference between a technical presentation and a technical training, let me just say that throughout a training, you need to ensure that people understand the information you’re trying to teach them — and they can act on it.

If you’re planning to start using Kubernetes in your team, I’ve listed a few topics that seemed to be especially hard to grasp for my students. If you want to make sure your team gets the most out of a Kubernetes training, here are my recommendations for the topics that need special attention so the event is a success for everyone involved.

YAML

The most common way to define Kubernetes configuration is using the YAML file format. Almost all the examples you’ll find online will be written in YAML.

Anyone who has experience on a team that deploys its application on Kubernetes knows that with time, you end up with a huge wall of small YAML files that define all of the resources in your environment.

I was surprised to see that many participants in the course didn’t have enough experience working with YAML. I planned on showing only one slide to refresh everyone’s memory, however, during the first lab assignment, it became obvious that I should have spent a little bit more time on that topic.

Kubernetes’ YAML configuration is relatively complex. You not only need to understand how to write a simple key/value object, but with Kubernetes, you’ll use YAML’s more advanced features, like how to work with blobs of text or with more complex “array in a hash in an array” type of structures.

Networking

Since the course was aimed at developers, I deliberately eliminated in-depth explanations about the inner workings of K8s networking.

However, some concepts like services are hard to explain without at least a basic understanding of networking concepts like Virtual IPs or the methods used to route traffic from the outside world using a reverse proxy or load balancers.

Unfortunately, it seemed that this topic was very hard to explain, even to more experienced developers in the room. I blame the curse of knowledge for that! (More on that a bit later.)

For the next iteration of the workshop, I will rework this part of the training and try to spend more time explaining the basics of networking and instead of assuming that it’s common knowledge.

Many Small, Interconnected Components

Kubernetes resources are small interconnected components that can be leveraged in many different ways. For Kubernetes users, it’s a very good thing to have a huge list of little pieces that you can combine to build your own solutions, like Lego bricks.

I found that it’s hard to explain all these concepts to beginners who will need to learn about a lot of small components and practice using them before they will even be able to deploy their first applications.

I spent a good portion of the first day explaining the core concepts of Kubernetes even before we could tackle the important topics like Ingress and deployments.

To explain about the deployment resource, first I needed to explain and practice topics like these:

• Docker, and why we should run one process per container
• Pods, and why we need more than one container per Pod
• Services, and how they help with service discovery and exposing your application to the outside world
• ReplicaSets, and how they differ from the Replication Controllers

By the time we got to deploying the first “serious” application on our dev clusters, it was already almost the end of the first day, and it was obvious that everyone was already exhausted.

Why Do We Need Kubernetes?

When preparing the materials for any technical workshop, no matter how small it may be, it’s important to be aware of the “curse of knowledge” bias. We almost always assume that our audience will have the same experience and background as we have.

As I was preparing for this training, I had a very long debate with myself about if I should include a presentation that explains the challenges of Docker orchestration and leads the student to understand why Kubernetes is even necessary.

I’m so happy that eventually I included these slides! Having extra material on the evolution of Docker from a developer’s tool to a production infrastructure component was a lifesaver. Presenting this material to the class helped prepare the background for more technical and hands-on topics that came afterwards.

Nowadays, Docker and Kubernetes has such a huge momentum that it’s hard to remember that Docker is still a fairly young technology, and a lot of the developers still didn’t have a chance to work with Docker in production to experience the problems Kubernetes solves.

Maybe it will change in a year or two, but for now, make sure to include a few slides that provide a wider context than “just” Kubernetes as a technology. Adding a short introduction about the challenges of Docker orchestration plus Kubernetes’ history and ecosystem is a great idea.

Summary

I really enjoyed the process of designing and presenting this technical training, so I’ll probably do a few additional workshops in the future. It was a huge pleasure to see how people learn and evolve.

If you’re managing a small team of developers and planning to start using Kubernetes in the near future, I recommend setting aside at least half a day for a hands-on workshop. You can use the syllabus from my Kubernetes training as a baseline for topics you will need to cover. Pay a special attention to the topics I’ve mentioned in this article, and make sure that you set aside your assumptions about developers’ current knowledge base and cover them in a bit more detail.

‍