The only thing I really know about Kubernetes is sometimes it is called k8s (ubernete is 8 characters long). Let’s look into it together.

Oh and it’s symbol is a ship wheel! Matt Artz : https://unsplash.com/photos/4KaY-etsnKc

So what is it?

Kubernetes looks after your containers, similar to another resource called Docker Swarm. It helps manage their size/scale, balances loads and helps updating. It also helps with connecting to different resources like databases, other clusters and security credentials.

Kubernetes is what is know in the business as a “declarative” model. That simply means you declare/say what you want there to be, and Kubernetes will then do the heavily lifting and “thinking” to provide what you want. The architecture is built entirely around what you declare.

“I want 6.” — “I will make 6”….

1 dies.* — “I will add another immediately”
[note: we didn’t speak to it to say
‘hey ones gone down’ — it noticed itself.]

Essentially, you say what state you want and it will do that.

Kubernetes is ancient Greek for “helmsman”. It steers the ship and sorts everything out so it all goes smoothly. You say where to go.

Open Source?

This isn’t a history lesson but basically some Google guys started it and now it is run by an open source foundation (Cloud Native Computing Foundation — CNCF) which is supported by RedHat, IBM, Amazon, Google, Microsoft and many more.

Okay, but what is the difference with Docker Swarm and Kubernetes?

There is a temptation to say it is just a different naming convention. This isn’t entirely true. This post goes through some real detail, but I think it is nicely summarised by a comment on it:

I think there is a single difference which can guide the choice: monetization of Swarm comes from users running it on premises, monetization of Kubernetes comes from users running it in Google cloud*.

K8s is a pain to set up locally, but easy on GCP. Docker Swarm is much easier. With GCP you get monitoring and dashboards. With Docker Swarm you can make or buy your own.

*note that all other major cloud providers also offer Kubernetes.

So, back to Kubernetes

A resource model

This took a long time to get my head around. To run with Kubernetes you need to create a resource model. There is a lot to read on this (for good reason), but is incredibly dense to start:

It is just a list.

A list that you have declared. A list, that you declared, which Kubernetes will follow.

There are obviously lots of things you can define: configuration variables/secrets, desired states/levels, define endpoints (entry/exit comms channel), and much much more.

This is all done in the resource model.

Pods

Pods are groups of containers. These groups may just have one container, or there may be a few containers inside.

A replica is a copy of a pod. Why would you want replicas? Load balancing or safety and security.

An app can and should be made from a few pods and can be scaled by making replicas.

Pods in a resource model

A key component of a resource model will be the you say what code you want to run. In Kubernetes you do this by saying which pod you want to run and each pod will have their codelines/images written to it.

YAML

And where do you have to write this information? In a YAML file. What is a YAML file? Yet Another Markup Language. Well that isn’t helpful. A YAML file is essentially a short cut to writing a JSON file. This JSON is read by Kubernetes and then created.

Ignore all of that. The YAML is the list to tell Kubernetes what we need — it has the pods, their images, and the resource model.

Updating your demands

If you want a change, all you have to do is update the YAML file and save your changes. Kubernetes will see that its state (list) doesn’t match and begin making the changes. Similarly you can change which version of an image is being used.

Now, knowing this all, this video should help make the rest of the picture:

Why do people want it?

Well because it is the simplest way to manage apps/sites on the cloud. It is, relatively, simple to set up; it saves a lot of monitoring; it allows access of data across different applications (by running multiple pods in the same namespace); it means we don’t have to think about it much more!

Focused on saving our time: everyhour.xyz for your life balance; tree-meals-a-day.earth for our food emissions and compairbnb.info/hello for booking airbnbs.