Kubernetes past and present (with learning mind map)

Although Docker already very powerful, there are still many inconveniences in actual use, such as cluster management, resource scheduling, file management, and so on. So in such a blooming container era, many solutions have emerged, such as Mesos, Swarm, Kubernetes, etc., among which Google's open source Kubernetes exists as a big brother.

Kubernetes development experience

History is always the same, and good always replaces bad.

Kubernetes means "helmsman" in Greek. It was originally founded by several software engineers at Google. It was deeply influenced by the company's internal Borg and Omega projects. Many designs were borrowed from Borg, and at the same time, Borg's flaws were taken into account. Improved, Kubernetes is currently a CNCF project and a solution for many companies to manage distributed systems. One of the more interesting points is that Kubernetes is called k8s. That is to say, the word k and s consist of 8 letters, so it is a shorthand form of a word. Similarly, the internationalization we used in the project called i18n has the same effect.

Kubernetes built on Docker can build a container scheduling service. Its purpose is to allow users to manage cloud container clusters through Kubernetes clusters without requiring users to perform complex settings. The system will automatically select the appropriate tasks. Node to perform specific container cluster scheduling processing work.

The core concept is Container Pod. A Pod consists of a group of containers working on the same physical working node. These groups of containers have the same network namespace, IP, and storage quota, and port mapping can be performed on each Pod according to the actual situation. In addition, the Kubernetes worker node will be managed by the main system, and the node contains the services that can run the Docker container.

We can see multiple service methods

• Alibaba Cloud => Infrastructure as a service
• Sina Cloud => Platform as a service
• Office365 => Software as a service

As an orchestration tool, in terms of the age of the community, Kubernetes not dominant. After all, Kubernetes is only three years old, and Mesos launched by Apache has been around for 7 years. Although Docker Swarm is younger than Kubernetes, behind it is the full support from the official container center of Docker. However, because it is open sourced by Google and has more than ten years of experience in containerization, there are still many people using it, and it will become the main pillar of the entire industry in the future.

The core problem solved by Kubernetes

• Service discovery and load balancing
• Kubernetes can use the DNS name or its own IP address to expose the container. If the traffic to the container is large, Kubernetes can load balance and distribute network traffic, thus making the deployment stable.
• Storage orchestration
• Kubernetes allows you to automatically mount the storage system of your choice, such as local storage, public cloud providers, etc.
• Automatic deployment and rollback
• You can use Kubernetes describe the desired state of the deployed container, which can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, delete existing containers and use all their resources for new containers.
• Automatic binary packaging
• Kubernetes allows you to specify the CPU and memory (RAM) required for each container. When the container specifies a resource request, Kubernetes can make better decisions to manage the container's resources.
• Self-repair
• Kubernetes restarts the failed container, replaces the container, kills the container that does not respond to user-defined health checks, and does not notify the client until it is ready for service.
• Key and configuration management
• Kubernetes allows you to store and manage sensitive information such as passwords, OAuth tokens, and ssh keys. You can deploy and update the key and application configuration without rebuilding the container image, and there is no need to expose the key in the stack configuration.

The emergence of Kubernetes not only dominates the container orchestration market, but also changes the way of operation and maintenance in the past. It not only blurs the boundary between development and operation and maintenance, but also makes the role of DevOps clearer. Every software engineer has You can use Kubernetes to define the topological relationship between services, the number of online nodes, and the amount of resource usage. It can quickly realize horizontal expansion, blue-green deployment and other complex operation and maintenance operations in the past.

Performance comparison

Comparison and Analysis of Today's Three Mainstream Dispatching Systems

• Comparison summary

• Apache Mesos

Apache Mesos is an open source cluster manager for distributed system kernel. Apache Mesos appeared much earlier than Docker Swarm and Kubernetes . Coupled with Marathon, a container-based application orchestration framework, it provides an effective alternative to Docker Swarm and Kubernetes. Mesos can also use other frameworks to support both containerized and non-containerized workloads.

Mesos can run multiple types of distributed systems on the same cluster machine, and can share resources more dynamically and efficiently. And Messos also provides service failure checking, service release, service tracking, service monitoring, resource management and resource sharing. Messos can scale to thousands of nodes. If you have a lot of servers and want to build a large cluster, Mesos comes in handy. Many modern and scalable data processing applications can run on Mesos, including big data framework Hadoop, Kafka , Spark.

But large and comprehensive, it is often the corresponding complexity and difficulty. This is completely correct in Messos. Unlike Docker and Docker Swarm that use the same API, Mesos and Marathon have their own API, which makes them better than other orchestration. The system is more complicated. Apache Mesos is a perfect orchestration tool for mixed environments. Because it includes container and non-container applications, although Messos is very stable, it makes it more difficult for users to quickly learn applications, which is also difficult to promote in application and deployment scenarios. one of the reasons.

• Docker Swarm

Docker Swarm is a container orchestration system of Docker Company. It uses the standard Docker API interface. The container use commands and docker commands are a set, which is simple and convenient. The basic architecture of Docker Swarm is simple and straightforward. Each host runs a Docker Swarm agent, and a host runs a Docker Swarm manager. This manager is responsible for commanding and scheduling the containers on these hosts. Docker Swarm runs in high availability mode. Docker Swarm One of the nodes acts as a manager of other nodes, including a container for the scheduler and service discovery components.

The advantages and disadvantages of Docker Swarm are the use of the standard Docker interface. Because it is simple to use and easy to integrate into existing systems, it is more difficult to support complex scheduling systems, especially scheduling implemented in customized interfaces. This may be the reason why success is also in Docker, and failure is also in Docker.

• Kubernetes

Kubernetes as a container cluster management system for container applications on multiple hosts cloud management platform, Kubernetes goal is to make application deployment container of the simple, yet efficient, so Kubernetes provides application deployment, planning, update , A complete set of mechanisms for maintenance.

Kubernetes has no fixed requirements for the container format, but Kubernetes uses its own API and command line interface for container orchestration. In addition to the Docker container , Kubernetes also supports a variety of other containers, such as rkt, CoreOS, etc. Kubernetes is a self-contained management tool that can implement container scheduling, resource management, service discovery, health check, automatic scaling, update upgrades, etc., and you can also specify the number of copies and service requirements (IO priority; performance priority, etc.) in the application template configuration. ), resource usage intervals, labels (Labels, etc.) to match specific requirements to achieve the desired state, etc. These characteristics are enough to conquer developers, plus Kubernetes has a very active community. It provides users with more choices to facilitate users to expand the orchestration container to meet their needs. But because Kubernetes uses its own API interface, the command system is another system, which is why kubernetes has a relatively high threshold.

For most applications, we will appropriately add monitoring when deploying. This is especially true for running carrier containers. Kubernetes provides liveness probes to check our application, which is executed regularly by the kubelet on the node.

Knowledge Graph

Mainly introduce what knowledge to learn

Software Architecture

Traditional client-server architecture

• Architecture description

Kubernetes follows a very traditional client/server architecture model. The client can Kubernetes cluster through a RESTful interface or directly using kubectl. There is not much difference between the two in fact. The latter is only for Kubernetes. The provided RESTful API is packaged and provided. Each Kubernetes cluster is composed of a set of Master nodes and a series of Worker nodes. The Master node is mainly responsible for storing the state of the cluster and allocating and scheduling resources for Kubernetes objects.

• Master Node Service-Master Architecture

As the Master node that manages the state of the cluster, it is mainly responsible for receiving client requests, arranging the execution of the container and running the control loop, and migrating the state of the cluster to the target state. The master node is composed of the following three components:

API Server: Responsible for processing requests from users. Its main role is to provide RESTful interfaces to the outside world, including read requests for viewing the cluster status and write requests for changing the cluster status. It is also the only component that communicates with the etcd cluster.

etcd: It is a key-value database with both consistency and high availability. It can be used as a backend database for storing all cluster data in Kubernetes.

Scheduler: The component on the master node that monitors those newly created Pods that are not designated to run nodes, and selects the node to let the Pod run on it. Factors considered in scheduling decisions include resource requirements for individual Pod and Pod sets, hardware/software/policy constraints, affinity and anti-affinity specifications, data location, interference between workloads, and deadlines.

controller-manager: Run the components of the controller on the master node. Logically speaking, each controller is a separate process, but in order to reduce complexity, they are all compiled into the same executable file and integrated in one Run in process. These controllers include: node controllers (responsible for notification and response when nodes fail), replica controllers (responsible for maintaining the correct number of Pods for each replica controller object in the system), endpoint controllers (filling endpoint Endpoints) Object, that is, add Service and Pod)), service account and token controller (create a default account and API access token for the new namespace).

• Work Node-Node Architecture

The implementation of other Worker nodes is relatively simple, and it is mainly composed of two parts: kubelet and kube-proxy.

Kubelet: It is the agent that the worker node performs operations, responsible for specific container lifecycle management, manages the container based on the information obtained from the database, and reports the running status of the pod, etc.

kube-proxy: is a simple network access proxy, but also a Load Balancer. It is responsible for specifically assigning the request for access to a certain service to the Pod of the same type of label on the working node. The essence of kube-proxy is to implement Pod mapping by operating firewall rules (iptables or ipvs).

Container Runtime: The container runtime environment is the software responsible for running containers. Kubernetes supports multiple container runtime environments: Docker, containerd, cri-o, rktlet, and any implementation of Kubernetes CRI (container runtime interface).

Component description

Mainly introduce some basic concepts about K8s

It is mainly composed of the following core components:

• apiserver
• The only entrance to all services, providing authentication, authorization, access control, API registration and discovery mechanisms
• controller manager
• Responsible for maintaining the state of the cluster, such as the expected number of replicas, failure detection, automatic expansion, rolling updates, etc.
• scheduler
• Responsible for resource scheduling, scheduling Pod to the corresponding machine according to the predetermined scheduling strategy
• etcd
• Key-value pair database, which saves the state of the entire cluster
• kubelet
• Responsible for maintaining the life cycle of the container, as well as for the management of Volume and network
• kube-proxy
• Responsible for providing service discovery and load balancing within the cluster for Service
• Container runtime
• Responsible for image management and real operation of Pod and container

In addition to the core components, there are some recommended plugins:

• CoreDNS
• A DNS service that resolves the correspondence between domain names and IPs can be created for SVCs in the cluster
• Dashboard
• Provides a B/S architecture access entrance to the K8s cluster
• Ingress Controller
• Officials can only implement a four-layer network proxy, while Ingress can implement a seven-layer proxy
• Prometheus
• Provide K8s cluster with the ability to monitor resources
• Federation
• Provide a unified management function that can multi-K8s across cluster centers, and provide clusters across availability zones

Author: Escape
Link: https://www.escapelife.site/posts/2c4214e7.html