Technology Sharing | Basic Knowledge of Kubernetes Study Notes


Author: Zhang Qiang

He is a member of the Aikesheng R&D Center, a back-end R&D engineer, and is currently responsible for the business development of the DMP product Redis.

Source of this article: original submission

* Produced by the Aikesheng open source community, original content is not allowed to be used without authorization, please contact the editor and indicate the source for reprinting.

1. What is Kubernetes?

Kubernetes, also known as k8s (the first letter is k, there are 8 characters between the first letter and the last letter, and the last letter is s, so k8s for short) or simply "kube", is a portable and extensible open source The platform is used to manage containerized workloads and services. Compared with traditional deployment and virtualization deployment methods, it has the following characteristics:

  • Agile application creation and deployment: Compared with using VM images, it improves the simplicity and efficiency of container image creation.
  • Continuous development, integration and deployment: Support reliable and frequent container image construction and deployment through quick and simple rollback (due to image immutability).
  • Focus on the separation of development and operation and maintenance: Create application container images at build/release instead of deployment, thereby separating the application from the infrastructure.
  • Observability: It can display not only information and indicators at the operating system level, but also the operating status of the application and other indicator signals.
  • Environmental consistency across development, testing, and production: Run the same on a portable computer as in the cloud.
  • Portability across cloud and operating system releases: It can run on Ubuntu, RHEL, CoreOS, local, Google Kubernetes Engine and any other place.
  • Application-centric management: Improve the level of abstraction, from running the OS on virtual hardware to running applications on the OS using logical resources.
  • Loosely coupled, distributed, elastic, and liberating microservices: Applications are broken down into smaller independent parts, and can be dynamically deployed and managed-instead of running as a whole on a large single machine.
  • Resource isolation: predictable application performance.
  • Resource utilization: high efficiency and high density.

1. The rise of Docker

To talk about Kubernetes, we must start with docker containerization technology.

In 2013, Docker (also known as dotCloud Inc. at the time) publicly introduced Docker for the first time at the PyCon conference. The most popular PaaS project at the time was Cloud Foundary. However, the excellent design of the Docker project on the docker image solved the cumbersome steps of application packaging and application release that other PaaS technologies failed to solve at the time. Most docker images are directly composed of all the files and directories of a complete operating system, so the content in this compressed package is exactly the same as the operating system used in your local development and test environment-it is this excellent feature This makes the docker project rise rapidly in many Pass technologies.

2. Evolution of Docker Orchestration

The biggest feature of Swarm is that it completely uses the original container management API of the Docker project to complete cluster management. In a multi-machine environment where Swarm is deployed, users only need to use the original Docker instructions to create a container, and this request will be intercepted by Swarm for processing, and then find a suitable Docker Daemon to run through the specific scheduling algorithm.

In 2014, docker acquired the Fig project and developed it into the current Compose, which makes the deployment of containers more convenient-configuration files can be used to complete the configuration of more complex container orchestration parameters. In June of the same year, Google released Kubernetes.

On June 22, 2015, led by Docker, CoreOS, Google, RedHat and other companies jointly announced that Docker would donate Libcontainer and renamed it RunC project, which will be managed by a completely neutral foundation, and then runC as the basis , We jointly developed a set of standards and specifications for containers and mirroring. This set of standards and specifications is OCI (Open Container Initiative). OCI is proposed to completely separate the implementation of container runtime and mirroring from the Docker project. From the API to every layer of the container runtime, the Kubernetes project exposes an extensible plug-in mechanism for developers, encouraging users to intervene in every stage of the Kubernetes project through code. The effect of this change in the Kubernetes project was immediate, and soon a large number of secondary innovations based on the Kubernetes API and extended interfaces were spawned in the entire container community, such as:

  • Istio, a microservice governance project;
  • Stateful application deployment framework Operator;
  • There are also open source startup projects like Rook, which encapsulate heavyweight products such as Ceph into simple and easy-to-use container storage plug-ins through the extensible interface of Kubernetes.

2. Technical basis of Docker container

1. Process and Linux Namespaces

In order to exclude other processes from the container, docker uses Linux's Namespace mechanism. The system call to create a thread in a Linux system is clone(), such as:

int pid = clone(main_function, stack_size, SIGCHLD, NULL);

At this point, this system call will create a new process for us and return its process number pid. And if you use the clone() system call to create a new process, add the CLONE_NEWPID parameter, such as:

int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);

At this time, the process will be in a brand new process space, in which its pid is 1. In addition to PID Namespace, Linux system also provides Namespaces such as Mount, UTS, IPC, Newwork and User. This is why the container can only "see" the processes in its own container.

2. Resource Limits and Linux Cgroups

Although the process with PID 1 in the container can only see the situation in the container. But from the perspective of the host, it is still an equal relationship with other processes as an ordinary process, that is to say, the resources (CPU, memory, etc.) it can use can still be occupied by other processes on the host. This situation leads to the embarrassment of "isolated but not completely isolated" processes in the container, which does not conform to the characteristics of the container as a "sandbox".

The full name of Linux Cgroups is Linux Control Groups. Its main function is to limit the upper limit of resources that a process group can use, including CPU, memory, disk, network bandwidth, etc. for example:

  • blkio, set I/O limits for block devices, generally used for devices such as disks;
  • cpuset, which allocates a separate CPU core and corresponding memory node for the process;
  • memory, set the memory usage limit for the process. and many more

With the mechanism of Cgroups, containerization technology can complete the resource restriction of the process in the container.

3. Container image and file system

There is a chroot in the Linux operating system, which is used to change the root directory of the process to a specified location. For example, chroot $HOME/test /bin/bash , if you execute ls / , you will see that the content returned by the command is the content in the $HOME/test directory. The first Namespace of the Linux operating system is Mount Namespace, which is based on the continuous improvement of chroot.

In order to make the directory in the container look more "real", generally a file system of a complete operating system is mounted in the root directory of the container. For example, the ISO of Ubuntu 16.04. In this way, after starting the container, execute ls / in the container to view the contents of the root directory, which are all the directories and files of Ubuntu 16.04. This file system mounted on the root directory of the container and used to provide an isolated execution environment for the container process is the so-called "container image", also known as rootfs (root file system).

Therefore, for Docker, the core process is:

  1. Enable Linux Namespace configuration;
  2. Set the specified Cgroups parameters;
  3. Switch the root directory of the process (pivot_root or chroot).

At the same time, please note: rootfs is only the files, configurations and directories contained in an operating system, and does not include the Linux operating system kernel. All containers share the kernel of the host operating system.

In summary, a "container" is actually a process isolation environment constructed by the three technologies of Linux Namespace, Linux Cgroups, and rootfs. It can be divided into two parts:

  • The container image is the rootfs jointly mounted on /var/lib/docker/aufs/mnt.
  • When the container is running, it is an isolated environment composed of Namespace + Cgroups.

3. Introduction to Kubernetes architecture

From a developer's point of view, what really needs to be concerned about is the container image. From the perspective of container cluster management, the "container orchestration" technology that can define container organization and management specifications is the most important. Among the most representative container orchestration tools are the Compose+Swarm combination of Docker and Kubernetes jointly led by Google and RedHat.

Kubernetes was born out of the Borg project within Google. And Borg is the core dependency that carries the entire infrastructure of Google. In the infrastructure system papers that Google has published publicly, the Borg project does its part to occupy the bottom of the entire infrastructure technology stack. At the same time, with the efforts of the open source community, Kubernetes has repaired the defects and problems in the original Borg system. Leveraging on the theoretical advantages of the Borg project, a global architecture as shown in the figure below has been gradually determined:

The architecture of the Kubernetes project is composed of two nodes, Master and Node, corresponding to the control node and the computing node respectively. in:

  • Master control node

    • Kube-apiserver responsible for API services;
    • The kube-scheduler responsible for scheduling;
    • The kube-controller-manager responsible for content layout;
    • Etcd responsible for the persistent data of the cluster.
  • Node compute node

    • The kubelet component responsible for interacting with the container runtime. In addition, configure the network and persistent storage for the container;
    • Responsible for maintaining the network rules kube-proxy on the node.
    • When the container is running, Kubernetes supports multiple container running environments such as Docker, containerd, and CRI-O.

The above design consideration is that Kubernetes does not use Docker as the core of the architecture, but only implements Docker as a low-level container runtime. The core problem of Kubernetes is that there are actually various relationships among various tasks running in large-scale clusters. The handling of these relationships is the most difficult part of the job scheduling and management system.

In a slightly more complex cluster system, there will be a variety of different service relationships, such as the access relationship between a Web application and the database, and the access relationship between a computing service and a monitoring suite. Before the popularization of container technology, for the convenience of deployment, these applications may be deployed in the same virtual machine. After the emergence of container technology, the original applications, components, and daemons can be mirrored separately and run in each dedicated container. They do not interfere with each other, have their own resource quotas, and can be scheduled on any machine in the entire cluster.

In order to better handle the application access relationship between containers, tightly connected containers will be divided into a "Pod". The containers in the Pod share the same Network Namespace, the same set of data volumes, etc. At the same time, Kubernetes will bind a Service service (kube-proxy) to the Pod, which is mainly used as the proxy entrance of the Pod, thereby replacing the Pod to expose a fixed network address.

Kubernetes also defines improved objects based on Pod. For example, Job is used to describe a one-time running Pod; DaemonSet is used to describe a daemon process with only one copy; another example is CronJob, which is used to describe timing tasks.

Kubernetes uses a declarative API approach to orchestrate applications. The so-called declarative is to submit a defined API object to "declare" the desired final state. If the submitted commands are one by one, to reach the desired state step by step, this is the "command type". For example, to use kubernetes to start an Nginx container image, the specific steps are as follows:

  1. Write a file named nginx-deployment.yaml to define a Depoloyment object. The main body is a Pod that uses Nginx mirroring, and the number of replicas can be defined as 2 (replicas=2);
  2. Execute the command kubectl create -f nginx-deployment.yaml to start the container.

From the perspective of design goals, Kubernetes provides a set of container-based basic dependencies that can facilitate the construction of distributed systems, and can complete the deployment of container applications and the flexible management of applications. What it is good at is to automatically process various relationships between containers (applications/services) in accordance with user definitions and system rules. And all of this is achieved based on containerization technology. For further learning about the Kubernetes architecture and environment development in the Kubernetes environment, please see the follow-up related article updates.

Four. Reference

[1] Wikipedia: Kubernetes entry (

[2] Kubernetes official document (

[3] In-depth analysis of Kubernetes (

[4] Wikipedia: Linux namespaces entry (

[5] Wikipedia: Cgroups entry (

阅读 477


275 声望
149 粉丝
0 条评论


275 声望
149 粉丝