When you talk about distributed systems nowadays Kubernetes will be name-dropped. What is all the fuss about and why should you care? How it will make your DevOps life more relaxed?

In this blog post, I will try to explain why you should be mindful 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 it isn't, let's play a little buzzword bingo first.

Cloud Native

When we talk about distributed computing and "the Cloud", 9 out of 10, 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 tied to a specific cloud provider.

And this is why Kubernetes, the most prominent cloud-native open source project, 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 it 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 its main job is to schedule your services across your fleet of servers.

Kubernetes will not deal with packing your code into containers, provisioning your hardware, securing and patching your servers, or deploying it. The plot thickens...

First question, how do we get our services packed and scheduled by Kubernetes? Containers!

And when you talk about Containers, you probably mean 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 which Kubernetes uses 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 and can be used by Kubernetes is what we called 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 (it's a scheduler, remember?), so 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 created a version 2 of our Cloud 66 for Containers offering backed by Kubernetes. Read more about our complete container toolchain.

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!

For Devs, things like scheduling, networking, scaling, resource management can be a bit daunting. Kubernetes will help them to achieve Cloud Nativeness but Devs needs more, since they mostly want to focus on their code, and to bring that code a life in a cloud environment. Devs just want to push code, run tests, and deploy 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.

Kubernetes for all

Our mission is to give anyone access to Kubernetes. It doesn't matter if you are a one man shop, start-up, grown-up business or even a large enterprise: Cloud 66, backed by Kubernetes, will give you wings when you want to innovate, iterate fast, and handle scale.

Come on board, be a cloud-agnostic Kubernaut and go wild with Kubernetes!