Kubernetes In Action

This is the entry level book for Kubernetes(“koo-burr-NET-eez”) beginners. The book is written by Marko Lukša, who is a fullstack programmer with 20+ years experience.


Introducing Kubernetes

Understanding the need for a system like k8s

Actually when I was doing intern in Meituan-Dianping, the deployment process is not involving any ops people. Though, we may ask them for the privileges of modifying the production environment. But during the deployment, one single github push would enable us to deploy the application to the production environment. I believe that’s the benefits of the containerized architecture.

In the last few years, we’ve also seen a shift in the whole application development process and how applications are taken care of in production. In the past, the development team’s job was to create the application and hand it off to the operations team, who then deployed it, tended to it, and kept it running. But now, organizations are realizing it’s better to have the same team that develops the application also take part in deploying it and taking care of it over its whole lifetime. This means the developer, QA, and operations teams now need to collaborate throughout the whole process. This practice is called DevOps.

Ideally, you want the developers to deploy applications themselves without knowing anything about the hardware infrastructure and without dealing with the ops team. This is referred to as NoOps. Obviously, you still need someone to take care of the hardware infrastructure, but ideally, without having to deal with peculiarities of each application running on it.

Introducing container technologies

The fundamental mechanism behind the container: how do they isolate each other, and how to limit the resources them use: namespaces & cgroups

By this point, you’re probably wondering how exactly containers can isolate processes if they’re running on the same operating system. Two mechanisms make this possible. The first one, Linux Namespaces, makes sure each process sees its own personal view of the system (files, processes, network interfaces, hostname, and so on). The second one is Linux Control Groups (cgroups), which limit the amount of resources the process can consume (CPU, memory, network bandwidth, and so on).