New to Kubernetes? Me too
Getting tossed into the deep-end and learning how to swim amongst the Pods.
Why am I writing about this?
Disclaimer: This article is meant to act as a conceptual overview and introduction to Kubernetes and where to begin when working with it. No code examples will be provided.
If you’re anything like I was just a few weeks ago, you probably have little to no experience in the wonderful world of Kubernetes. Just a few days prior to starting my new job at Mavenlink, I received a call to update me on the team I would be working with and the tasks we would be challenged with. “You will be migrating our third party integrations platform to Kubernetes, pretty cool stuff”, I heard and at the time I believed that it would indeed be pretty cool.
After all, who doesn’t want to learn about and work with a popular technology? No, I had no idea that it was developed by Google. And no, I didn’t know much else besides for the fact that it was associated with Docker, another technology that I knew little about. Four weeks after starting the job, I am by no means a pro, but I have scratched the surface of the Kubernetes world and am continuing to learn how to navigate the sea of pods.
What to know
Five weeks later, I am still far from being an expert, so there are likely more and possibly better resources to explore than the ones I can suggest. This blog post isn’t intended to tell you about Kubernetes, but rather provide some useful tips as to where to start when diving in. In my case, to learn about Kubernetes I found it useful to start familiarizing myself with the following:
- Docker — a platform used to containerize applications, which gives the application a performance boost and also reduces overall size by allowing it to use a shared Linux OS and embrace continuous deployment, amongst other benefits.
- Kubernetes — a tool for orchestrating Docker containers that can provide the ability to schedule or automate deploys as well as easily autoscale an application.
- Helm — a package manager for Kubernetes. Helm charts allow a developer to create templates for Kubernetes resources and preconfigure them
- Google Cloud Platform — a suite of cloud-provided services by Google that includes a plethora of tools, notably: Google Kubernetes Engine and Google Cloud SQL
- Yaml — a human-readable serialization language that is used to write Helm Charts as well as other places in an application where data is stored or transferred
If you’re looking for more in-depth knowledge on each of these tools or for some other helpful sites to explore, feel free to jump to the Resources section at the end of this post. Otherwise, I’m going to move into just what proved to be useful starting information about each of these listed items.
Docker As I began to look online for resources and to begin getting a grasp on what this Kubernetes thing really was, I found myself first needing to figure out Docker. Kubernetes acts as an orchestration and management tool for Docker containers, making it easier to automate deploys and scaling for an application. At the root of it, you will still need to know things like writing a Dockerfile or building Docker images. Without a little knowledge on this, you likely won’t be able to get a great handle on Kubernetes.
Kubernetes Building out from there, you can begin to jump into the world of Kubernetes. There are lots of things to look into, but I started with basic definitions about the various components and how everything connects together. Once you think you know what’s going on, it will be useful to check out the documentation or some tutorials to practice with commands. The Kubectl command will play a crucial role in the development, debugging, and monitoring of your app.
Helm While you may not need to use Helm depending on the complexity with which you are using Kubernetes, it is a great way to manage a Kubernetes application. Charts are useful for easily installing, managing, and upgrading various deployments and components of your app. Understanding how this tool can help you manage and simplify your app deployments is useful, especially if you are maybe unsure of whether or not to use it.
Google Cloud Platform Google Cloud Platform provides a plethora of useful tools for running an app. In particular, as the creator of Kubernetes, their Google Kubernetes Engine is useful for setting up and managing clusters. There are many other tools that will integrate well with each other and you can pick and choose which are necessary based on the needs of your application.
Yaml As you start working with Kubernetes, you will start to see so much yaml. If you aren’t familiar now, you quickly will be as you will need it to define key pieces of the Kubernetes infrastructure.
What helped
To build the basic knowledge of all of these technologies, the place I started was with online resources. Looking at online documentation is a great way to see how to use the technology, but if you’re someone who had no experience on these items, like me, then my advice would be to start simpler. Figure out exactly what you’re working with before you see how it’s used. Find easy-to-understand definitions. For me, it felt like I was back in school, reading through articles and taking notes for future reference. However, picking out key details and putting them in your own words is a great way to find answers to frequently forgotten information. As well, it adds a great way to later tweak and update your understanding as you find your knowledge expanding.
Aside from reading, the best way to gain comfort working with the different parts of Kubernetes is to actually practice. For that, it is worth spending a little time working through noobernetes.io, a quick tutorial created by Jason Carter. Here, I was able to get a good feel for what commands would be frequently used in the command line and what was influencing how the simple app was running. If you have no experience at all with Kubernetes (or even if you do), it is worth going through the entire tutorial a few times to really get a good understanding of what each part is accomplishing.
Once you’re finally getting into development, it is important to note that things still won’t make perfect sense. Still, the idea of “practice makes perfect” rings true. The paired programming culture here at Mavenlink helped me learn from teammates who had much more knowledge on the subject and after only a short amount of time, I could see that their guidance was allowing me to feel more comfortable navigating the code base. Having a pair to correct my mistakes and work with me through the development creates a great culture where questions are okay and the focus is on making sure everyone has an understanding of what is going on. Good development practices were another key contributor to my early growth. The team started a checklist to compile all of the steps for a migration from Heroku to Kubernetes. Through iteration, this checklist was refined and for a young, frequently lost developer, seeing this list repeatedly provided a great tool for me to see how the pieces of the puzzle all fit together.
While things may get frustrating early on, it is important to maintain focus as well as optimism. Like with anything else, learning Kubernetes is a gradual process and frustration and confusion resolve over time. Days in which wasn’t as engaged with my pair or times when I did not ask as many questions were the more difficult days. Making mistakes will inevitably happen and ultimately lead to better learning and the more time you work with Kubernetes, the more comfortable you will begin to feel.
Frequent “Gotchas”
The purpose of this section is to highlight a few problem areas that our dev team has identified as “gotchas”. This list is not exhaustive, but just a few things to look out for as you start your journey through Kubernetes development.
Secrets Secrets are a resource in Kubernetes that can be useful if utilized properly. They can store information in the cluster to be accessed only with the secret’s name and key. This is useful for preventing the exposure of important information, but still allowing the cluster to access things particular values (ex. credentials).
Managing Multiple Clusters On apps of a larger scale, it is very possible that you may be managing multiple clusters. This can be a potential time-waster if you forget to change the cluster context as you move through development. As well, it is important to note that changes you make on one cluster might be applicable across other clusters as well. To help manage this, it can be useful to create separate values files for each cluster and as you make changes to one, you make the appropriate (if necessary) changes to the others. Then, upgrading the helm charts can apply the changes quickly.
Resources
See our other post: Kubernetes Migration Flight Manual for how to utilize checklists to sanity check your application migrations.
