Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what are the principles of Kubernetes design". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Introduction:

What I'm going to bring you today is a share of Kubecon held in Seattle at the end of 2018, the "Kubernetes Design principles" shared by Saad Ali, an engineer on Google's K8s team. Although it has been more than a year since this meeting, I think the content of this conference is worth learning. Most of us know how K8s works, but this article takes us to understand the design principles behind K8s and why it is designed in this way. Kubernetes quickly became indispensable for managing and deploying workloads on distributed systems across cloud and local environments. While most people are now familiar with how to use Kubernetes, few know the "why" behind it. Why does Kubernetes API look like this? Why do Kubernetes components interact with each other only through Kubernetes API? Why do you have PersistentVolumeClaim objects when you can easily reference volumes directly from pod? To answer these questions and help you learn more about Kubernetes, this lecture will reveal the principles that underpin Kubernetes design.

Principle 1. Kubernetes APIs

It's declarative, not imperative.

Let's start with the simplest example of how to start a task that needs to be run on a node. The easiest way is to send a command to start the container. But in doing so, if the container or node crashes, or when the node is temporarily inaccessible, the user must monitor and store the status of each node and container, catch all exceptions, and do exception handling. That is to say, leave all the complex exception handling logic to the client.

This introduces the first design principle of Kubernetes: Kubernetes APIs is declarative rather than Kubernetes APIs are declarative rather then imperative imperative:

User: provides a series of instructions to drive the system to a set state.

Systems: executing instruction

User: monitor the system and provide further instructions according to the system status

Declarative:

Users: defining expected statu

Systems: working towards a specified state

The following figure is an example of declarative API:

1. The user creates an API object

2. The components used work in parallel to achieve this state.

Declarative API supports automatic recovery. For example:

1. Node B is dead

2. The system independently moves the Pod to the healthy node A.

It is important to note that the primary node only stores the definition declaration of Pod and does not send commands to node B. if you do so, the primary node will become as complex and fragile as the client we mentioned earlier, and difficult to expand. This introduces the second design principle of K8s: the Kubernetes control plane is transparent and there is no hidden internal API (The Kubernetes control plane is transparent. There are no hidden internal APIs. )

Principle 2. Kubernetes control plane

Is transparent and has no hidden internal API

Before:

Master node: provides a series of instructions to drive the node to a set state.

Nodes: execute instructions from the master node

Master node: monitor each node and provide further instructions according to the status of the node

Now:

Master node: define the state you want to achieve

Nodes: working independently to achieve the state defined by the primary node

Let's take a look at an example of Pod creation: as shown in the following figure, all components monitor Kubernetes API and then decide what they should do. The user calls API to declare the definition of the creation Pod of the Pod master node to be created

Scheduler observes the definition of Pod A through API, and through the scheduling operation, decides to create Pod An on Node B, and updates the definition of Pod An on the primary node through API.

Node B observes that the definition of Pod An is within its own jurisdiction, and initiates Pod A users to delete Pod A node B through API to find that Pod A has been deleted node B removes Pod A, which leads to a simpler, more robust system design that can easily recover from the failure state. There is no single point of failure in the system, and the responsibility of the master node is very simple. Another benefit of this is that the system is easier to expand and combine. Because there is no internal hidden API, users can easily replace existing components with custom components, or add custom features. K8s also has objects that are important to the business, such as the key file secret that stores passwords, the configuration configmap, or the downlink API that provides basic information about Pod. So does the application have to be modified to call KubeAPI or this information? This introduces the third design principle of Kubernetes: meeting the needs of users (Meet the user where they are)

Principle 3. Meet the needs of users

Before:

The application must be modified to know the existence of K8s and call KubeAPI

Now:

Applications can load configuration files or key files from environment variables, so there is no need to modify

We can give an example of remote storage.

As shown in the figure above, Pod can directly reference a remote storage volume (GCE PD,AWS EBS,NFS, etc.), and kubernetes automatically causes the volume to be used for Pod. But if you do this, there is a problem, if you want to migrate to a new infrastructure, then it will not work. So this introduces the fourth principle of kubernetes design:

Portable workload (Workload portability)

Principle 4. Portable workload

Persistent volumes (PersistentVolumn,PV) and persistent volume declarations (PersistenVolumnClaim, PVC) are such examples.

As shown in the figure above, through the abstraction of PVC, the user Pod does not directly reference GCE PD or EBS, which makes the Pod portable across different infrastructures. Like the operating system, the design decouples the system application from the underlying hardware or architecture.

Summary

This article summarizes the "Kubernetes Design principles" shared by Google senior software engineer and kubernete developer Saad Ali in Kubecon 2018. The four design principles are:

Kubernetes APIs is declarative, not imperative.

The Kubernetes control plane is transparent and there is no hidden internal API

Meet the needs of users

Portable workload

Through this sharing, we can find that the reason behind the design principles of K8s, in fact, some of its general principles of software design are consistent, although object-oriented is no longer a popular term, but the design principles in this paper are highly consistent with the object-oriented design principles.

The object should be responsible for himself. When designing an object, the object should encapsulate the internal state as much as possible, be responsible for itself, and we design a driveable car. One design consists of two objects, driver and car, and then diver.run (car). A better design is to not need driver, or to think of dirver as an attribute of Car, which is Car.run (). The second design is more in line with the principle of object-oriented design. This is the principle behind declarative API, where components are responsible for themselves.

Kube API is similar to the interface of an object, which is closed to modification and open to extension. Through open API, users can easily implement functional extensions, but you cannot modify existing components. You can develop custom components to replace existing components.

The design of portability makes use of similar object-oriented polymorphism, which defines abstract interface PVC and hides the specific implementation details.

I hope the sharing of this article will help you understand the design principles behind K8s. This is the end of the content of "what are the principles of Kubernetes Design". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.