k8s overall architecture

k8s-overall overview and architecture

1. What is Kubernetes

Kubernetes is a lightweight and extensible open source platform for managing containerized applications and services. Automated deployment and scaling of applications can be carried out through Kubernetes. In Kubernetes, the containers that make up the application are combined into a logical unit for easier management and discovery. Kubernetes has accumulated 15 years of experience in running workloads as a Google production environment, and has absorbed the best ideas and practices from the community. After several years of rapid development, Kubernetes has formed a large ecological environment. Google adopted Kubernetes as an open source project in 2014. The key features of Kubernetes include:

• Automated boxing: Without sacrificing availability, the container is automatically deployed based on the container's resource requirements and constraints. At the same time, in order to improve utilization and save more resources, the critical and optimal workloads are combined.
• Self-healing ability: When the container fails, the container will be restarted; when the deployed Node node has a problem, the container will be redeployed and rescheduled; when the container fails the monitoring check, the container will be shut down; until the container is normal Services will be provided externally only when it is running.
• Horizontal expansion: Through simple commands, user interface or CPU-based usage, the application can be expanded and contracted.
• Service discovery and load balancing: Developers can perform service discovery and load balancing based on Kubernetes without using additional service discovery mechanisms.
• Automatic release and rollback: Kubernetes can release applications and related configurations programmatically. If there is a problem with the release, Kubernetes will be able to return to the changes that have occurred.
• Confidentiality and configuration management: Without the need to rebuild the image, you can deploy and update confidentiality and application configuration.
• Storage Orchestration: Automatically attach storage systems. These storage systems can come from local, public cloud providers (for example: GCP and AWS), network storage (for example: NFS, iSCSI, Gluster, Ceph, Cinder, Floker, etc.).

2. The overall architecture of Kubernetes

 

Kubernetes is a master-slave distributed architecture, mainly composed of Master Node and Worker Node, as well as the client command line tool kubectl and other additional items.

• Master Node: As the control node, it manages the cluster scheduling; Master Node is composed of API Server, Scheduler, Cluster State Store and Controller-Manger Server;
• Worker Node: As a real worker node, a container for running business applications; Worker Node includes kubelet, kube proxy and Container Runtime;
• kubectl: used to interact with the API Server through the command line, and operate on Kubernetes, to realize the addition, deletion, modification, and other operations of various resources in the cluster;
• Add-on: It is an extension of the core functions of Kubernetes, such as adding network and network strategy capabilities.
• repliceation is used to scale the number of replicas
• Endpoint is used to manage network requests
• scheduler

1. Prepare a yml file containing the deployment of the application, and then send it to ApiServer through the kubectl client tool.

2. ApiServer receives the client's request and stores the resource content in the database (etcd).

3. The Controller component (including scheduler, replication, endpoint) monitors resource changes and reacts.

4. ReplicaSet checks the database for changes and creates the desired number of pod instances.

5. The Scheduler checks the database changes again and finds that the Pod has not been assigned to a specific execution node (node), and then assigns the pods to the nodes that can run them according to a set of related rules, and updates the database to record the pod allocation.

6. Kubelete monitors database changes, manages the life cycle of subsequent pods, and discovers those pods that are assigned to run on the node where it is located. If a new pod is found, the new pod will be run on that node.

7. kuberproxy runs on each host in the cluster to manage network communications, such as service discovery and load balancing. For example, when data is sent to the host, it is routed to the correct pod or container. For the data sent from the host, it can discover the remote server based on the requested address and route the data correctly. In some cases, it will use the round-robin algorithm to send the request to multiple instances in the cluster.

 

 

Kubernetes and container ecosystem

 

 

Typical process

The entire process of creating a Pod, the sequence diagram is as follows:

1. The user submits a request to create a Pod through the REST API of the API Server or the Kubectl command line tool, which supports both Json and Yaml formats;

2. API Server processes user requests and stores Pod data to Etcd;

3. Schedule checks the new pod through the watch mechanism of the API Server, and tries to bind the Node to the Pod;

4. Filter hosts: The scheduler uses a set of rules to filter out the hosts that do not meet the requirements. For example, if the Pod specifies the required resources, then it must filter out the hosts with insufficient resources;

5. Host scoring: score the hosts that meet the requirements selected in the first step. In the host scoring stage, the scheduler will consider some overall optimization strategies, such as distributing a copy of a Replication Controller to different hosts, using the lowest load Host, etc.;

6. Select host: select the host with the highest score, perform binding operation, and store the result in Etcd;

7. The kubelet executes the Pod creation operation according to the scheduling result: After the binding is successful, the container will be started, docker run, and the scheduler will call the API Server API to create a bound pod object in etcd, describing all binding and running on a worker node Pod information. The kubelet running on each worker node will also periodically synchronize bound pod information with etcd. Once it is found that the bound pod object that should be running on the worker node has not been updated, it will call the Docker API to create and start the container in the pod.

2 Master Node

2.1 API Server (API Server)

API Server is mainly used to process REST operations, ensure that they take effect, execute related business logic, and update related objects in etcd (or other storage). API Server is the entry point of all REST commands, and its related result status will be stored in etcd (or other storage). The basic functions of API Server include:

• REST semantics, monitoring, persistence and consistency guarantee, API version control, abandonment and validation
• Built-in admission control semantics, synchronous admission control hooks, and asynchronous resource initialization
• API registration and discovery

In addition, API Server also acts as a gateway to the cluster. By default, the client accesses the cluster through the API Server. The client needs to pass authentication and use the API Server as a fortress and proxy/channel for accessing Node and Pod (and service).

2.2 Cluster state store (cluster state store)

Kubernetes uses etcd as the overall storage of the cluster by default, of course, other technologies can also be used. etcd is a simple, distributed, and consistent key-value store, mainly used for shared configuration and service discovery. etcd provides a REST API for CRUD operations, as well as a registered interface to monitor the specified Node. All the status of the cluster is stored in the etcd instance, and has the ability to monitor, so when the information in etcd changes, it can quickly notify the relevant components in the cluster.

2.3 Controller-Manager Server (control management server)

Controller-Manager Serve is used to perform most of the cluster-level functions. It performs life cycle functions (for example: namespace creation and life cycle, event garbage collection, terminated garbage collection, cascade delete garbage collection, node garbage collection) , Also execute API business logic (for example: elastic expansion of pod). Control management provides self-healing capabilities, capacity expansion, application lifecycle management, service discovery, routing, service binding and provisioning. Kubernetes provides Replication Controller, Node Controller, Namespace Controller, Service Controller, Endpoints Controller, Persistent Controller, DaemonSet Controller and other controllers by default.

2.4 Scheduler (Scheduler)

The scheduler component automatically selects the host on which the container runs. According to constraints such as the availability of requested resources and the quality of service requests, the scheduler monitors unbound pods and binds them to specific node nodes. Kubernetes also supports the scheduler provided by the user. The Scheduler is responsible for automatically deploying the Pod to the appropriate Node according to the scheduling strategy. The scheduling strategy is divided into a preselected strategy and a preferred strategy. The entire scheduling process of a Pod is divided into two steps:

1) Pre-select Node: Traverse all Nodes in the cluster, and filter out a list of Nodes that meet the requirements according to specific pre-selection strategies. If no Node meets the pre-selected policy rules, the Pod will be suspended until a Node that meets the requirements appears in the cluster.

2) Preferred Node: Based on the pre-selected Node list, score and sort the to-be-selected Nodes according to the preferred strategy to obtain the optimal Node.

3. Worker Node (slave node)

3.1 Kubelet

Kubelet is the most important controller in Kubernetes. It is the main implementer of Pod and Node API. Kubelet is responsible for driving the container execution layer. In Kubernetes, application containers are isolated from each other and from the host running them. This is the key point for independent decoupling management of applications.

In Kubernets, Pod is the basic execution unit. It can have multiple containers and storage data volumes. It can conveniently package a single application in each container, thereby decoupling the concerns during application construction and deployment. , It has been able to facilitate the migration between physical machines/virtual machines. API admission control can reject or Pod, or add additional scheduling constraints to Pod, but Kubelet is the final arbiter of whether Pod can run on a specific Node, not scheduler or DaemonSet. By default, kubelet uses cAdvisor for resource monitoring. Responsible for managing Pods, containers, images, data volumes, etc., to realize cluster management of nodes, and report the running status of containers to the Kubernetes API Server.

3.2 Container Runtime (container runtime)

Each Node runs a Container Runtime, which is responsible for downloading images and running containers. Kubernetes itself does not stop the container runtime environment, but provides an interface that can be inserted into the selected container runtime environment. kubelet uses the gRPC framework on Unix socket to communicate with the container runtime, kubelet as the client, and CRI shim as the server.

The protocol buffers API provides two gRPC services, ImageService and RuntimeService. ImageService provides RPC for pulling, viewing, and removing images. RuntimeSerivce provides RPC for managing Pods and container lifecycle management, as well as interacting with the container (exec/attach/port-forward). The container runtime can manage images and containers (for example: Docker and Rkt) at the same time, and can provide these two services through the same socket. In Kubelet, this socket is set through the –container-runtime-endpoint and –image-service-endpoint fields. The container runtimes supported by Kubernetes CRI include docker, rkt, cri-o, frankti, kata-containers, and clear-containers.

3.3 kube proxy

Based on a public access strategy (for example: load balancing), the service provides a way to access a group of pods. This method is achieved by creating a virtual IP, the client can access this IP, and can transparently proxy the service to the Pod. Each Node will run a kube-proxy. The kube proxy guides access to the service IP through iptables rules and redirects to the correct back-end application. In this way, kube-proxy provides a highly available load balancing solution. Service discovery is mainly realized through DNS.

In Kubernetes, kube proxy is responsible for creating proxy services for Pod; leading access to services; and implementing routing and forwarding from services to Pod, as well as load balancing through applications.

3 、 kubectl

kubectl is the command line interface for Kubernetes clusters. The syntax for running the kubectl command is as follows:

$ kubectl [command] [TYPE] [NAME] [flags]

The command, TYPE, NAME and flags here are:

• comand: Specify the operation to be performed on the resource, such as create, get, describe, and delete
• TYPE: Specify the resource type. The resource type is size-sensitive. Developers can use singular, plural and abbreviated forms. E.g:

$ kubectl get pod pod1 
$ kubectl get pods pod1 
$ kubectl get po pod1

• NAME: Specify the name of the resource. The name is also case-sensitive. If the name is omitted, all resources will be displayed, for example:

 $kubectl get pods

• flags: Specify optional parameters. For example, you can use the -s or -server parameters to specify the address and port of the Kubernetes API server.

In addition, you can get more information by running the kubectl help command.

4 Additional items and other dependencies

In Kunbernetes, the functions of Kubernetes can be expanded in the form of additional items. At present, there are three main types of additional items: network, service discovery, and visualization. The following are some of the additional items available:

4.4.1 Network and network strategy

• ACI uses container networking and network security integrated with Cisco ACI.
• Calico is a secure 3-layer network and network policy provider.
• Canal unites Fannel and Calico through the network and the network side.
• Cilium is a 3-layer network and network-side plug-in, which can transparently strengthen HTTP/API/L7 strategies. It supports routing and overlay/encapsultion mode.
• Flannel is an overlay network provider.

4.4.2 Service discovery

• CoreDNS is a flexible and extensible DNS server, which can be installed as a DNS in a Pod cluster.
• Ingress provides a routing and forwarding mechanism based on the Http protocol.

4.4.3 Visualization & Control

• Dashboard is the web user interface of Kubernetes.