When you talk about distributed systems nowadays, Kubernetes will be name-dropped. What is all the fuss about and why should you care and how it will make your DevOps life more relaxed?
In this blog post, I will explain why you should and shouldn't care when jumping the band wagon like a "crazy" Kubernaut.
Firstly, Kubernetes is a transliteration of the Ancient Greek κυβερνήτης which means the helmsman or captain of a ship (or more generally, one who guides or figuratively steers).
Kubernetes is an OSS project heavily backed by Google, RedHat, Microsoft, and Cloud Native Computing Foundation to name a few. They are pouring $$$ into this project like there's no tomorrow.
And who are you? You are a Kubernaut! A Kubernaut is a person who works with Kubernetes and part of the team to orchestrate your application.
I wrote a piece about "The Art of Orchestration" if you want more background information about orchestration.
Before we jump into the question what Kubernetes is and what not, let's play a little buzzword bingo first.
When we talk about distributed computing and "the Cloud," 9 out of 10 times, the Cloud Native term is dropped. Here's a small definition:
Cloud-native is an approach to building and running applications that fully exploit the advantages of the cloud computing delivery model. Cloud-native is about how applications are created and deployed, not where or tight to a Cloud provider.
And this is why Kubernetes is taking off like a SpaceX rocket.
Kubernetes Is a Scheduler
Let me simplify things. Kubernetes doesn't care about the underlying infrastructure or Cloud provider. It will treat your infrastructure (servers, volumes, network) as one big computer!
You, the Kubernaut, will just talk to Kubernetes and tell him what you want. A small conversation:
Kubernaut: Hi, Kubes, how you doing today? I want to deploy this awesome micro service called [my_spacex_rocket] and I want 10 replicas and make sure I don't have downtime. And I also want a service called [landing_pad], 5 replicas, to be deployed and this guy wants to consume the micro service called [my_spacex_rocket]. Do it!
Kubernetes: Thanks, buddy, I'm feeling great! We have enough resources on board to accommodate your request. I can schedule your micro service called [my_spacex_rocket] on server X and server Y because they are not under load. Also, I will schedule your other service on server Y and server Z because server X is almost out of memory. I use DNS based service discovery, just hit the DNS name [my_spacex_rocket] and I will redirect the traffic to one of those 10 replicas, load balancing you get for free!
Kubernetes has a lot of cool features, but his main job is to schedule your services across your fleet of servers.
First question: how do we get our services packed and scheduled by Kubernetes? Containers!
And when you talk about containers, you will still talk about Docker. Yes, Kubernetes can handle other container runtimes like RKT or Intel Clear Containers, but at the moment, Docker is still the place to go in the container runtime space.
There are two things you need to know about Docker as a Kubernaut:
- Docker is a runtime used by Kubernetes to isolate processes.
- Docker is a packaging format, and Kubernetes uses the format to pull down your service code.
Docker Is a Runtime for Process Isolation
The primary goal of a container runtime is to isolate the process, aka your service, from the rest of the system.
When the process is isolated from the underlying infrastructure, it's very easy to move your service around.
Without container runtimes like Docker, Kubernetes wouldn't exist!
Docker Is Just a Packaging Format
Despite all the efforts Docker made in the past and present, from a Kubernetes point of view, Docker is just a packaging format.
Packaging is the process of getting all the dependencies you need for your service to run in isolation.
The packaging format Docker produces, which can be used by Kubernetes, is what we call the Docker image.
A Docker image is stored in a public or private image repository. As a Kubernaut, you can produce images using a blueprint called the Dockerfile and push the image to an image repository.
The build process is NOT part of Kubernetes; you need tooling around it.
Deploying a Kubernetes cluster is hard. If you are into Ops and have time and $$$ to burn you can deploy "Kubernetes the hard way."
But from an Ops point of view, it's just the beginning. Things you need to consider, to name a few:
- How can I provision more servers to the cluster?
- How can my dev guys get their images on the cluster?
- What about databases?
- Access control?
- Supporting different cloud providers?
Basically, all the things you need to think about besides scheduling services!
That's why we create a version 2 of our Cloud 66 for Containers offering backed by Kubernetes. You get all the sweet stuff Kubernetes has to offer but as easy to use and deploy on any Cloud, or bring your own server.
From a dev point of view, things like scheduling, networking, scaling, resource management can be a bit daunting. Kubernetes will help them to achieve Cloud Nativeness, but Dev needs more.
Dev wants to focus on code and bring that code a life in a Cloud environment. Devs just want to push code, run tests and deploy it to production. They want to get the code into a CI/CD pipeline (testing, packaging) and let Kubernetes take care of the scheduling.
We made a complete container toolchain to deal with the Ops and Devs side of Kubernetes and let you thrive.