Shulou(Shulou.com)05/31 Report--

This article will explain in detail what the design concept of kubernetes is. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

I. kubernetes Design concept and distributed system

API design principles:

For cloud computing system, system API is actually in the leading position of system design. Every time K8S cluster system supports a new function and introduces a new technology, the corresponding API object will be introduced to support the management operation of this function.

1. All API should be declarative. Declarative operations are more stable for repetitive operations than imperative operations, which is important for distributed environments that are prone to data loss or duplication. In addition, declarative operations are easier for users to use, hiding details from users, while retaining the possibility of continuous optimization of the system in the future.

2.API objects are complementary and combinable. It is advocated that API objects should achieve object-oriented design requirements as far as possible, achieve "high cohesion, low coupling", and have an appropriate decomposition of business modules. In essence, K8S, a distributed system management platform, is also a business system, but its business is to schedule and manage container services.

3. High-level API is designed on the basis of operational intent. High-level design must be from a business perspective, not from a technical point of view. The high-level API design for K8S must be based on the business of K8S, that is, based on the operation intention of the system scheduling management container.

4. The low-level API is designed according to the control needs of the high-level API. The purpose of designing and implementing low-level API is to be used by high-level API, considering the purpose of reducing redundancy and improving reusability. The design of low-level API should also be based on requirements and resist the temptation affected by technology implementation as far as possible.

5. Try to avoid simple encapsulation and avoid internal hidden mechanisms that the external API cannot explicitly know. Simple encapsulation does not actually provide new functionality, but increases dependence on the encapsulated API. The internal hidden mechanism is also a very unfavorable design way for system maintenance. For example, PetSet and ReplicaSet are already two sets of Pod. K8S uses different API objects to define them, rather than using only the same ReplicaSet, and internally uses special algorithms to distinguish whether the ReplicaSet is stateless or stateless.

The complexity of 6.API operation is proportional to the number of objects. This is mainly from the perspective of system performance, to ensure that with the expansion of the system scale, the performance of the system will not become too slow to be used, then the minimum limit is that the operation complexity of API can not exceed O (N), N is the number of objects, otherwise the system will not have horizontal scaling.

The state of the 7.API object cannot be dependent on the network connection. In the distributed environment, the disconnection of the network connection is a frequent occurrence. To ensure that the state of the API object can cope with the instability of the network, the state of the API object can not depend on the state of the network connection.

8. Try to avoid making the operation mechanism dependent on the global state, because it is difficult to ensure the synchronization of the global state in the distributed system.

Design principles of control mechanism:

1. The control logic should depend only on the current state.

In order to ensure the stability and reliability of the distributed system, for the distributed system with frequent local errors, if the control logic only depends on the current state, then it is very easy to restore a temporarily malfunctioning system to the normal state. because as long as you reset the system to a stable state, you can confidently know that all the control logic of the system will begin to operate in the normal way.

two。 Assume the possibility of any error, and do fault tolerance.

Local and temporary errors in a distributed system are high probability events. Errors may come from physical system failures, and external system failures may also come from code errors of the system itself. it is also difficult to ensure system stability by relying on self-implemented code that will not make mistakes. Therefore, it is necessary to design fault-tolerant handling for any possible errors.

3. Avoid complex state machines as much as possible, and control logic should not rely on internal states that cannot be monitored.

Because the subsystems of the distributed system can not be synchronized strictly through the program, if the control logic of the two subsystems influence each other, then the subsystems must be able to access the states that affect the control logic, otherwise, it is equivalent to the existence of uncertain control logic in the system.

4. It is assumed that any operation may be rejected by any Operand or even parsed incorrectly.

Because of the complexity of the distributed system and the relative independence of each subsystem, different subsystems often come from different development teams, so we can't expect any operation to be handled by another subsystem in a correct way. When errors occur, errors at the operation level will not affect the stability of the system.

5. Each module can recover automatically after an error.

Because there is no guarantee that each module of the distributed system is always connected, so each module should have the ability of self-repair to ensure that it will not collapse because it cannot connect to other modules.

6. Each module can gracefully downgrade the service if necessary.

In other words, it is required to clearly distinguish the basic functions and advanced functions when designing and implementing the module, so as to ensure that the basic functions will not rely on the advanced functions, which at the same time ensures that the whole module will not collapse because of the failure of the advanced functions. The system implemented according to this concept is also easier to add new advanced functions quickly, thinking that there is no need to worry about the introduction of advanced functions affecting the original basic functions.

II. Kubernetes core technology concepts and API objects

The API object is the administrative operation unit in the K8s cluster. Every time a new function is supported and a new technology is introduced in the K8s cluster system, the corresponding API object will be introduced to support the management operation of this function. For example, the API object corresponding to the replica set Replica Set is RS.

Each API object has three main categories of properties: metadata metadata, specification spec, and state status. Metadata is used to identify API objects, and each object has at least three metadata: namespace,name and uid;. In addition, there are a variety of tags labels used to identify and match different objects. For example, users can use the tag env to identify and distinguish different service deployment environments, and use env=dev, env=testing and env=production to identify different services for development, testing and production. The specification describes the ideal state (Desired State) that users expect the distributed system in K8s cluster to achieve, for example, the user can set the expected number of Pod copies to 3 through the replication controller Replication Controller to describe the actual current state of the system (Status), such as the current actual number of Pod copies of the system is 2; then the current program logic of the replication controller is to automatically start a new Pod and strive to achieve a copy number of 3.

All configurations in K8s are set through the spec of the API object, that is, users change the system by configuring the ideal state of the system, which is one of the important design concepts of K8s, that is, all operations are Declarative rather than Imperative. The advantage of declarative operation in distributed system is that it is stable, and it is not afraid to lose the operation or run it many times. For example, an operation with a replica number of 3 is still a result, while the operation of adding 1 to the number of copies is not declarative. The result of running multiple times is wrong.

1.Pod

K8s has many technical concepts and corresponds to many API objects, the most important and basic of which is micro-service Pod. Pod is the smallest unit to run and deploy an application or service in a K8s cluster, and it can support multiple containers. The design idea of Pod is to support multiple containers to share network addresses and file systems in one Pod, and services can be combined in a simple and efficient way such as inter-process communication and file sharing. Pod's support for multiple containers is the most basic design concept of K8s. For example, if you run a software repository of an operating system distribution, one Nginx container is used to publish software, and the other container is specially used to synchronize from the source repository. The images of these two containers are unlikely to be developed by a team, but they can only provide a micro service if they work together. In this case, different teams develop and build their own container images and combine them into a microservice to provide services at the time of deployment.

Pod is the basis of all business types in K8s cluster. It can be regarded as a small robot running in K8s cluster. Different types of services need different types of small robots to execute. At present, the services in K8s can be divided into long-term service (long-running), batch (batch), node background support (node-daemon) and stateful application (stateful application); the corresponding small robot controllers are Deployment, Job, DaemonSet and PetSet, which will be introduced later in this article.

two。 Replication Controller (Replication Controller,RC)

RC is the earliest API object in the K8s cluster to ensure the high availability of Pod. Monitor the running Pod to ensure that a specified number of Pod copies are running in the cluster. The specified number can be multiple or 1; less than the specified number, RC will start running new Pod copies; more than the specified number, RC will kill excess Pod copies. Even if the specified number is 1, running Pod through RC is more sensible than running Pod directly, because RC can also take advantage of its highly available ability to ensure that there is always 1 Pod running. RC is an early technical concept of K8s, which is only suitable for long-term service types, such as controlling small robots to provide highly available Web services.

3. Copy set (Replica Set,RS)

RS is a new generation of RC that provides the same high availability capabilities, but the main difference is that RS comes from behind and can support more kinds of matching patterns. Replica set objects are generally not used alone, but as ideal state parameters for Deployment.

4. Deployment (Deployment)

Deployment represents an update operation by the user to the K8s cluster. Deployment is an API object that is broader than the RS application pattern. It can be creating a new service, updating a new service, or rolling upgrading a service. Rolling upgrade of a service is actually a compound operation that creates a new RS, then gradually increases the number of replicas in the new RS to the ideal state, and reduces the number of replicas in the old RS to 0; such a compound operation is not easy to describe with a RS, so it is described by a more general Deployment. With the development direction of K8s, the future management of all long-term service-oriented businesses will be managed through Deployment.

5. Service (Service)

RC, RS, and Deployment only guarantee the number of microservices Pod that support services, but do not solve the problem of how to access these services. An Pod is just an instance of running a service, which may stop at any time on one node and start a new Pod on another node with a new IP, so the service cannot be provided with a definite IP and port number. Stable service delivery requires service discovery and load balancing. The job of service discovery is to find the corresponding backend service instance for the service accessed by the client.

In the K8S cluster, the service that the client needs to access is the Service object. Each Service corresponds to a valid virtual IP within the cluster, and the cluster accesses a service through the virtual IP. The load balancing of microservices in K8S cluster is realized through kube-proxy. Kube-proxy is the load balancer within the K8S cluster. It is a distributed proxy server with one on each node of K8S. This feature reflects its scalability advantage. The more nodes that need to access the service, the more kube-proxy will provide load balancing capability, and the more highly available nodes will be.

6. Task (Job)

Job is the API object that K8S uses to control batch tasks. The main difference between batch business and long-term servo long-running service is that batch business runs from beginning to end, while long-term servo service runs forever without users stopping. The Pod managed by Job quits automatically when the task is completed successfully according to the settings of the user. The criteria for successful completion vary according to different spec.completions strategies: a single pod task with a Pod success marks completion; a fixed number of successful tasks ensures the success of all N tasks; and a work queue task marks success according to the global success confirmed by the application.

7. Background support Service set (DaemonSet)

The core focus of background-supported services is on the nodes (physical or virtual machines) in the K8S cluster, ensuring that there is one such Pod running on each node. The nodes may be all cluster nodes or some specific nodes selected by nodeSelector. Typical background support services include storage, logging, monitoring, etc., and support services running in K8S cluster on each node.

8. Stateful Service set (PetSet)

RC and RS mainly control the provision of stateless services, and the name of the Pod they control is set randomly. A Pod is discarded when it fails, and a new Pod is restarted in another place. It doesn't matter where the name changed, name and startup are important, only the total number of Pod is important. PetSet is used to control stateful services, and the name of each Pod in the PetSet is determined in advance and cannot be changed. The name of the Pod in the PetSet is used to associate the corresponding state with the Pod.

9. Cluster federation (Federation)

K8s released the Federation function of the beta version in version 1.3. In a cloud computing environment, the range of services from near to far can be as follows: co-host (Host,Node), cross-host with availability zone (Available Zone), cross-availability zone with region (Region), cross-region with service provider (Cloud Service Provider), cross-cloud platform. K8s is designed to be a single cluster in the same region, because the network performance of the same region can meet the scheduling and computing storage connection requirements of K8s. The federated cluster service is designed to provide cross-Region cross-service provider K8s cluster service.

Each K8s Federation has its own distributed storage, API Server, and Controller Manager. Users can register K8s Cluster, a member of Federation, through the Federation's API Server. When a user creates and changes an API object through Federation's API Server, Federation API Server creates a corresponding API object in all its registered child K8s Cluster. When providing business request services, K8s Federation will first do load balancing among its own sub-Cluster, and for business requests sent to a specific K8s Cluster, it will do load balancing within K8s Cluster according to the same scheduling mode as when K8s Cluster provides services independently. The load balancing between Cluster is realized through the load balancing of domain name service.

All designs try not to affect the existing working mechanism of K8s Cluster, so that for each sub-K8s cluster, there is no need for a K8s Federation in the outer layer, which means that all existing K8s code and mechanisms do not need to be changed because of Federation functionality.

10. Storage Volume (Volume)

The storage volume in the K8s cluster is similar to the Docker storage volume, except that the scope of the Docker storage volume is a container, while the life cycle and scope of the K8s storage volume is a Pod. The storage volumes declared in each Pod are shared by all containers in the Pod. K8S supports a large number of storage volume types. Support a variety of public cloud platform storage, including AWS, Google, Azure cloud; support a variety of distributed storage, including GlusterFS and Ceph;, and also support easy-to-use host local directories hostPath and NFS.

K8s also supports the use of logical storage such as Persistent Volume Claim or PVC, which enables the storage user to ignore the actual storage technology in the background (such as AWS,Google or GlusterFS and Ceph) and leave the configuration of the actual storage technology to the storage administrator through Persistent Volume.

11. Persistent storage volume (Persistent Volume,PV) and persistent storage volume declaration (Persistent Volume Claim,PVC)

PV and PVC make K8s cluster have the logical abstraction ability of storage, so that the configuration of actual background storage technology can be ignored in the logic of configuring Pod, and the configuration work is left to the configuration of PV, that is, the manager of the cluster. The relationship between stored PV and PVC is very similar to that of computing Node and Pod; PV and Node are resource providers, which change according to the infrastructure of the cluster and are configured by the K8s cluster administrator; while PVC and Pod are the consumers of the resources, which change according to the needs of the business service, and the consumer of the K8s cluster is configured by the service administrator.

twelve。 Node (Node)

The computing power in the K8S cluster is provided by Node, which was originally called the service node Minion and later renamed node. The Node in the K8s cluster is equivalent to the slave node in the Mesos cluster, and it is the working host on which all Pod runs, which can be either a physical machine or a virtual machine. The unified characteristic of the working host is the container that runs on the kubelet management node above.

13. Key object (Secret)

Secret is used to store and pass sensitive information objects such as passwords, keys, and authentication credentials. Secret can prevent sensitive information from being written plainly in the configuration file.

14. User account (User Account) and service account (Service Account)

The user account provides the account identity for the person, while the service account provides the account identity for the computer process and the Pod running in the K8s cluster. One difference between the user account and the service account is the scope of action; the user account corresponds to the human identity, which has nothing to do with the namespace of the service, so the user account is cross-namespace, while the service account corresponds to the identity of a running program and is related to a specific namespace.

15. Namespace (Namespace)

Namespace provides virtual isolation for K8s clusters, which initially have two namespace, default and kube-system. In addition, administrators can create new namespace to meet the needs.

16.RBAC access authorization (Role-based Access Control, RBAC)

K8s released the authorization model of role-based access control in version 1.3. Compared with attribute-based access control (Attribute-based Access Control, ABAC), RBAC mainly introduces the concepts of role Role and role binding RoleBinding.

17.Conclusion summary

From the system architecture, technical concept and design concept of K8S, we can see the two core design concepts: fault tolerance and scalability. Fault tolerance is the basis to ensure the stability and safety of K8S system, easy expansibility is to ensure that K8S is more user-friendly, is the basis of rapid iteration to add new functions.

This is the end of the article on "what is the design concept of kubernetes". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

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.