K8s(0) - Introduction to Kubernetes

What is Kubernetes ? \(°Ω°)/

Kubernetes, or K8s¹, is defined as follows on Wikipedia:

Kubernetes (/ˌk(j)uːbərˈnɛtɪs, -ˈneɪtɪs, -ˈneɪtiːz, -ˈnɛtiːz/), also known as K8s, is an open-source container orchestration system for automating software deployment, scaling, and management. Originally designed by Google, the project is now maintained by a worldwide community of contributors, and the trademark is held by the Cloud Native Computing Foundation.

A lots of word soup to say that it is a software made to manipulate containers. We’ll decipher this definition point by point.

Docker, Kubernetes, containers, pod, helm, fleet, …

You may have noticed that much of the technical terminology here is nautically themed.

Engineers at Google were having fun with the naming. Containers used in shipping are standardized, hold packages, and can be easily loaded or unloaded onto boats.

Containerized software work in a similar manner: packaged in a standardized way and can be deployed to new environments without changing those environments.

Kubernetes comes from the Greek word κυβερνήτης (kybernētēs), which means “helmsman” or “pilot”, the person who steers a ship. In our case, it deploys containers to the right place.

And just as whales travel in groups called pods, Kubernetes organizes containers into logical units known as pods, the smallest deployable units in the system.

Use cases

K8s is made for mission-critical applications, needing the most uptime you can squeeze out of them, high performance, and fancy automated features.

This introduces a lot of complexity into your system, and K8s experts are pretty expensive. Your project may not need that much complexity.

One good point for K8s adoption is having already containerized your application. K8s only manages containers, so you’ll need to do it anyway.

The best practice for deploying to K8s is microservices. If you’re one of the lucky people who’ve never heard of that thing, let me introduce you to it.

The principle of microservices is to split your application into multiple services, as small as possible. Taking a library API for example, you might do the following split, creating one container per line:

• Books
• Clients
• Employees

Having things split this way, if your Books service crashes, the rest of the system is not impacted.

Now let me introduce you to hell’s version of microservices:

• Books
  • GET
  • POST
  • PUT
  • DELETE
• Clients
  • GET
  • POST
  • PUT
  • DELETE
• Employees
  • GET
  • POST
  • PUT
  • DELETE

This level of granularity makes a crash of an endpoint way smaller, impacting only one route, deleting a book, for example. With the gift of making you want to shoot yourself in the head while you’re working on it. But now you are reaching your KPIs, so everything is fine.

You can also completely ignore all of this and run the biggest monolithic application known to mankind.

Uptime

A K8s cluster is deployed across multiple servers, called nodes. One of the advantages of having multiple nodes like this is redundancy. It’s a key concept in K8s, as you have multiple nodes running your code, if one node crashes or stops responding, another node can take over.

Another feature of Kubernetes is self-healing. When a container stops responding, K8s (senpai) will notice it, and take it out of the working pool used to reply to requests. It will then wait to see if the container starts working again. If the pod is grumpy and doesn’t want to restart, it’ll be killed off and replaced by another one.

All of this keeps your application nice and running seamlessly. And most importantly, without any human intervention.

Performances

As the previously mentioned redundancy makes your code run in parallel on multiple nodes, you can even run the same service multiple times on one node. Both of these things mean more resources allocated / to be allocated to your application.

Allocation is a major feature of K8s. You can estimate how many resources your applications use during daily activities, and the maximum resources to be allocated to it. With this information, K8s will dispatch pods to nodes with enough resources to run them.

In case of the craziest discount ever, you may want to add a lot more resources. K8s checks the usage of pods, if pods are running low on resources, it will create new pods, trying to keep up with demand.

Cloud agnostic

Kubernetes manifests are cloud agnostic, meaning that you can easily migrate from Amazon EKS (Amazon Elastic Kubernetes Service) to Google GKE (Google Kubernetes Engine).

However you may need to adapt some parts of your configurations (like StorageClasses) when changing cloud providers.

This is it for today. It is a lot of information to take in, time to take a break. See you next time for a deep dive into Kubernetes various elements in my K8s() series (づ｡◕‿‿◕｡)づ