The Basics of Kubernetes
An overview of Kubernetes components and how they work
What to Expect From This Post?
In this post I will be explaining the basic Kubernetes components and how they interact with one another. I will be giving a short description of each of them, how they are used and what problem they solve.
What Not to Expect From This Post?
This post will not be showing you any code or YAML config. In my opinion, if you want to be able to manage a Kubernetes cluster you have to understand the concepts before the code. If you understand the logic behind all the components, you can easily find the code for what you are trying to do online.
Let’s Get Started!
Kubernetes is an awesome tool for anyone looking to up their game when it comes to hosting your code on a server, especially in cloud. But awesome doesn’t mean easy. This is a guide to understanding why Kubernetes exists and how it is used. We will go over the basic components of a Kubernetes cluster and how to manage them.
What Problem Does Kubernetes Solve?
With the shift to container technologies such as Docker, hosting your code on the internet was easier than ever. You didn’t need to manage VMs, instead you just need to wrap your code inside a container and describe the dependencies of your application. This is extremely useful but container technologies don’t fix the fact that you still need to manage the server that the Docker containers are running on. You need to start the containers on servers manually and when that server has a problem, you need to find a way to get the services that were previously running on it to a new location. This tedious work is what led to the development of Kubernetes. Kubernetes is what we call a container orchestrator. This means that you give your container to Kubernetes and it will handle the lifecycle of the container. It will automatically find a place on a server to run that container, if a server goes down it will keep track of what services were running on the server and migrate it to somewhere else without the need of any human interaction.
Kubernetes is a game changer when it comes to server management and is used by a lot of huge companies in production. That being said it is useful for anyone who has more than a single service running on a server.
What Is the Basic Server Architecture of Kubernetes
The basic architecture of a Kubernetes cluster is actually really simple. You have two types of servers when running Kubernetes. You have your control plane servers and your worker nodes. The control plane servers are responsible for making all the decisions in your cluster. It will be the one that will deploy your docker images and make sure that they are all running well. On the other hand the worker nodes are responsible for actually running your containers. They are the equivalent of what you would consider your server(s) in the traditional world. They are the ones doing all the heavy work of running the code that you wrote.
That’s it! The server architecture of Kubernetes is only comprised of these two things. The only thing that changes from a tiny Kubernetes cluster to a huge one is the number of servers that Kubernetes is managing. For high availability it is recommended that you have a couple of servers in the control plane and multiple worker nodes. Let’s say you notice that you containers need a little more processing power, you can attach new worker nodes to your cluster and the control plane will automatically rebalance your containers to use that new processing power. It’s that simple.
Now that we know the basic server architecture of Kubernetes, let’s talk about the logical components that are used to actually manage those containers and services that we want to deploy in the cluster.
Pods
The first component we will talk about is the simplest one, the pod. The truth is that the control plane of Kubernetes doesn’t really deploy containers, it deploys pods that include containers. You can think of a pod as an environment for containers. Most of the time a pod will only have a single container inside but it can have more than one. Let’s say that you have a metric server that fetches different metrics for your application. You would deploy both the application and the metric service in the same pod. That means that you know that both services will be deployed on the same machine and at the same time. It also means that they share the same storage and network resources which could be mandatory for some applications to work.
WARNING: If you have two applications that don’t absolutely need to be deployed on the same worker node to work but you would like them to be for performance reasons (for example a web server and a database). Look into Pod Affinity. This is an advanced topic so I will not be covering it in this article.
For simplicity’s sake, you can generally think of a pod as a container. This is not 100% true, but they act very similarly in the majority of scenarios.
Deployment
Now that you know what a pod is, you need a way to tell Kubernetes how to deploy it. In the Kubernetes world, this is called a deployment. This component is responsible for describing how you want to deploy a pod. Let’s say you have a web server and you want to have 3 replicas of that web server for load balancing, you would define that requirement inside a deployment. This deployment would create what we call a Replica Set. That Replica Set is then responsible for keeping three replicas of your web server running on your worker nodes at all time. The Replica Set is running inside the control plane while the pod is running inside of worker nodes. In short, the pod describes the environment that the container will run in while the deployment describes how to deploy that environment on your worker nodes.
Services
Cool! now you have a service running on a server. The code is being executed, but how do you call it from the internet? What’s the IP of the service? On what port is it running on? All of these questions are answered with a service! The job of the service is to expose your application to the outside world. It could be through a simple IP or a more complex Load Balancer. There are many types of services that will cover most if not all of the different ways to expose an application to the world. This is also where you define the port that the application will be exposed to. Simply speaking, services just describe how you want the application to be made available to the outside world.
Secrets / Config Map
And finally, Secrets and Config Maps. All your pods, Deployment, Services or any other component of a Kubernetes cluster is defined in YAML. While YAML is really cool, it’s a pretty static language. You can’t define variables that can be shared between files or get a value from the disk. This could be quite annoying when managing large Kubernetes clusters as some configurations might be shared between different services (Think DB login info, URLs to third-party services, etc.). And, as we all know from the DRY principle, repeating these configs by hand makes it less maintainable and more error-prone. The solution to this problem in Kubernetes is Secrets and Config Maps.
Secrets and Config Maps are components that you can use to store configs (URLs, log levels, etc.) or secrets (passwords, API keys, etc.) for your application. In theory they both accomplish the same thing. They store config in a way that can be accessed in other components of Kubernetes. The difference between them is that secrets are made for more sensitive data such as DB password while config maps are made for less sensitive information such as a feature flag or the database URL. Also one thing to keep in mind is that you have to base64 encode your values if you want to put them in a secret.
Conclusion
Kubernetes is an extremely useful technology in the modern technology stack. It allows you to automate container deployment and make sure that your applications are running on your servers. It does take a little bit of time to set up but it’s worth every second. If you are interested in DevOps or Cloud, it’s a must to add to your toolkit. Although I did not show you any code in this article, I think that the basic knowledge of the different types of component will help you in your journey towards Kubernetes master. If you want to learn more about Kubernetes here is the link to their official docs. Thank you for reading!
