Kubernetes
Why Kubernetes?
So far we talked a bit about virtual machines, docker and containers. It has become clear that abstractions can provide us with a lot of power. As developers, once we can abstract all the difficulties of managing a real environment and the dependencies between all the software running inside of it, we can focus on adding value to the application we are developing.
That’s awesome and good for your local environment convenience. But what about the production environment? How do you make sure that your application has as many instances running as necessary to support your user base? How do you handle a container that stopped responding for some reason? Well, that’s when Kubernetes comes into play.
Kubernetes is a platform to manage multiple containers in a real life production environment. It’s not very simple to set up, but once it’s configured you get a lot of powerful tools to handle containers, such as container recovery, managing networks and auto-scaling. It’s also worth mentioning that Kubernetes can handle other types of containers besides docker containers, but for the scope of this post we’ll only be talking about docker containers.
Kubernetes can handle multiple containers… but doesn’t docker already do that?
It’s quite hard to explain the difference between kubernetes and docker itself without going into technical details, which I don’t want to do. I’ll leave some reference resources for this. My goal is to find a useful abstraction to keep in place. In that sense, we can think of Kubernetes as a very powerful production ready container management tool, while docker is a great container management tool for developing applications. It’s worth mentioning that Kubernetes uses docker for creating the docker containers that it orchestrates, so it’s not like we either use one thing or the other, and more like they are complimentary solutions. Docker provides an abstraction to package and run applications in containers, while Kubernetes helps deploy, scale, and manage these containers in a clustered environment.
The main topics I think are relevant to knowing about Kubernetes are:
pod
node
service
helm
A pod is the smallest deployable unit in Kubernetes, which can contain one or more containers that share the same network and storage. A node, on the other hand, refers to the machine that will run the pod, be it a real machine or a virtual one.
The term service in this context is an abstraction that represents an endpoint that is the entrypoint for multiple pods. One example of a service is a LoadBalancer that you can call and will redirect your request to the appropriate pod. And finally, helm is a tool for managing Kubernetes applications, allowing us to manage complex configurations for real life applications. Quite simple, huh.
Cool, did we cover everything related to Kubernetes?
Well, we at least scratched the surface. There are a lot of extra details that can only be covered by reading extensive documentation and, maybe even more important, by actually working with Kuberentes. But at least we covered the basics, and now we have some useful abstractions for virtual machines, docker and Kubernetes.
To recap, a virtual machine is a software-based machine that runs on a real physical machine. Docker provides virtual machine abstractions that are efficient because they share the same kernel functionalities of the operating system where the docker platform is installed. We can run docker containers on different machines and expect them to behave the same, which is great. Finally, Kubernetes allows us to manage real life applications with multiple containers and auto-scaling mechanisms.