Kubernetes container cluster management system basic explanation, kubernetes Management System

Kubernetes container cluster management system basic explanation, kubernetes Management System
Kubernetes Overview

Kubernetes is open-source by GoogleContainer Cluster Management SystemIs an open-source version of Google's large-scale container management technology Brog, which includes the following features:

Container-based application deployment, maintenance, and rolling upgrading of Server Load balancer, service discovery cross-machine and cross-region cluster scheduling, automatic scaling of stateless services, and a wide range of Volume support plug-in mechanisms to ensure scalability

Kubernetes is designed as an ecosystem platform for building components and tools to easily deploy, expand, and manage applications.

Kubernetes is not a PaaS System in the traditional sense. It does not limit the types and languages of applications. As long as applications can run in containers, they can run on Kubernetes;

Core Components

Kubernetes consists of the following core components:

Etcd: stores the status of the entire cluster. apiserver: provides a unique entry for resource operations and authentication, authorization, access control, API registration, and discovery. controller manager: maintains the status of the cluster, schedet for fault detection, automatic scaling, and rolling update: responsible for resource scheduling and scheduling the Pod to the corresponding machine according to the predefined policy. kubelet: maintenance of the container lifecycle, responsible for Volume and network management Container runtime: image management and the true running of pods and containers kube-proxy: Provides service discovery and load balancing in the cluster.

Communication Between Core Components

It can be seen that the API Server is the core of the entire cluster and is responsible for communication between modules of the cluster. The functional modules inside the cluster store information to ETCD through the API Server, and other modules read the information through the API Server to achieve information interaction between modules. For example, Kubelet on a Node reports its status through the API Server every time period. After receiving the information, the API Server saves the Node status information to ETCd. The Node Controller in Controller Manager regularly reads the status information of these nodes through the API Server and processes them accordingly. After listening to the information created by a Pod, Scheduler retrieves the list of all nodes that meet the Pod requirements and binds the Pod to the most compliant nodes in the node list: if schedpod detects that a Pod is deleted, the corresponding Pod instance on the current node is deleted.

From the above communication process, we can see that the access pressure on the API Server is very high, which is also the key to limiting (restricting) The size of the Kubernetes cluster. To relieve the pressure on the API Server, you can implement it through caching, through the watch/list operation, the information of the resource object is cached locally. This method relieves the pressure on the API Server to a certain extent, but is not the best solution.

Basic Concepts Container

Container is a lightweight operating system-level virtualization technology. It uses namespace to isolate the runtime environments of different software, and uses images to include the runtime environment of the software, so as to conveniently run anywhere.

Container features:

Small Size and Fast startup. You can package an application in each container image without binding to the external basic environment, because the application does not require external dependencies to be more transparent than virtual machines, the depression monitoring management application is encapsulated in containers, and managing containers is equivalent to managing applications.

You must use the Pod management container on Kubernetes. Each Pod can contain multiple containers. Pod is the minimum unit of Kubernetes.

Pod

Po is a collection of closely related containers. They share PID, IPC, Network, and UTS namespace, and are the basic unit of Kubernetes scheduling, supports sharing networks and file systems among multiple containers in a Pod. You can combine services through simple and efficient methods such as inter-process communication and file sharing.

In Kubernetes, all objects are defined using manifest (yaml or json). For example, a simple nginx service can be defined as nginx. yaml, which contains a container whose image is nginx:

apiVersion: v1kind: Podmetadata:  name: nginx  labels:    app: nginxspec:  containers:  - name: nginx    image: nginx    ports:    - containerPort: 80

Node

A Node can be a physical machine or virtual machine. It is the carrier that truly runs the Pod.Container runtime (such as docker),KubeletAndKube-proxyService.

Namespace

Namespace is an abstract set of resources and objects. For example, it can be used to divide objects in the system into different project groups or user groups. Common pods, services, replication controllers, and deployments all belong to a certain namespace (default), while node and persistentVolumes do not belong to any namespace.

Service

Service is the abstraction of application services. It provides load balancing and Service discovery for applications through labels. The Pod IP address and port list matching labels constitute an endpoints, and kube-proxy is responsible for balancing the service IP address load to these endpoints.

Each Service is automatically assigned a cluster IP address (a virtual address that can be accessed only within the cluster) and a DNS name. Other containers can access the Service through this address or DNS, you do not need to know how the backend container runs.

apiVersion: v1kind: Servicemetadata:  name: nginxspec:  ports:  - port: 8078 # the port that this service should serve on    name: http    # the container on each pod to connect to, can be a name    # (e.g. 'www') or a number (e.g. 80)    targetPort: 80    protocol: TCP  selector:    app: nginx

Label

A Label is a Label used to identify a Kubernetes object. It is attached to an object as a key/value (the maximum length of a key cannot exceed 63 bytes, and the value can be blank, it can also be a string of no more than 253 bytes ).

Label does not provide uniqueness. In fact, many objects (such as Pods) use the same label to mark specific applications.

After the Label is defined, other objects can use the Label Selector to select a group of objects with the same label (for example, ReplicaSet and Service use the label to select a group of pods ). Label Selector supports the following methods:

Equations, such as app = nginx and env! = Production set, such as env in (production, qa) Multiple labels (the relationship between them is AND), such as app = nginx, env = test

Annotations

Annotations are Annotations attached to objects in the form of key/value. Unlike Labels, which are used to mark and select objects, Annotations is used to record additional information to assist in application deployment, security policies, and scheduling policies. For example, deployment uses annotations to record the status of rolling update.