Kubernetes (k8s)

first, the core concept 1, Node

node as a working node in a cluster, running a real application, the smallest unit of Kubernetes managed on node is pod. Node runs kubernetes kubelet, Kube-proxy service processes that are responsible for pod creation, start-up, monitoring, restart, destruction, and load balancing of software patterns.

Node contains information: node address: The IP address of the host, or node ID. Node's state of operation: Pending, Running, terminated three states. Node Condition: ... Node system capacity: Describes the system resources available to node, including CPU, memory, maximum number of scheduled pods, and so on. Other: Kernel version number, kubernetes version and so on.

To view node information:

Kubectl describe node

2. Pod

Pod is the most basic operating unit of kubernetes, containing one or more tightly related containers, a pod can be considered as the "logical host" of the application layer by a container environment; multiple container applications in a pod are usually tightly coupled, and pod is created, started, or destroyed on node. ; Each pod runs a special container called pause, and the other containers are business containers that share the pause container's network stack and volume mount volumes, so they communicate and exchange data more efficiently, At design time, we can make full use of this feature to put a set of closely related service processes into the same pod.

The containers in the same pod can communicate with each other only through localhost.

An application container in a pod shares the same set of resources: PID namespaces: Different applications in the pod can see the process IDs of other applications; network namespaces: Multiple containers in a pod can access the same IP and port range; IPC Namespaces: Multiple containers in a pod can communicate using SYSTEMV IPC or POSIX message queues; UTS namespaces: Multiple containers in a pod share a host name; Volumes (shared storage volume): Each container in the pod can access the volumes defined at the pod level;

The lifecycle of the pod is managed through replication controller, defined by a template, and then assigned to a node to run, and after the pod contains the container, the pod ends.

Kubernetes designed a unique network configuration for pod, including assigning an IP address to each pod, using the pod name as the host name for communication between containers, and so on. 3. Service

In the Kubernetes world, although each pod is assigned a separate IP address, the IP address disappears as the pod is destroyed, which raises the question of how to access a set of pods that form a cluster to provide services. Service.

A service can be viewed as a set of external access interfaces for pods that provide the same service, and which pod is defined by the label selector. Have a specified name (such as My-mysql-server), a virtual IP (Cluster IP, Service IP or VIP) and port number, the destruction will not change before, only intranet access, can provide some kind of remote service capability; is mapped to a set of container applications that provide this service capability;

If service to provide extranet services, you need to specify the public IP and nodeport, or external load balancer;

Nodeport
The system opens the real port of a host on each node in the Kubernetes cluster, so that clients with access to node can access the internal service through this port 4, Volume

Volume is a shared directory in pod that can be accessed by multiple containers. 5, Label

Labels are attached to various objects, such as pod, Service, RC, node, and so on, to identify these objects, manage association relationships, etc., such as service and Pod Key/value. 6, RC (Replication Controller) target pod definition, target pod needs to run the number of replicas, to monitor the target pod label (lable);

Kubernetes through the definition of RC lable filter out the corresponding pod instances, and real-time monitoring of their status and number, if the number of instances is less than the definition of the number of replicas (replicas), will be based on the definition of the pod template in the RC to create a new pod, The pod is then dispatched to the appropriate node to start the operation until the number of pod instances reaches its intended target. II. Overall structure of the kubernetes Master and Node

Kubernetes divides the machines in the cluster into a master node and a group of working nodes (node). Where the cluster management-related set of processes Etcd, API Server, Controller Manager, Scheduler are running on the master node, and the last three components form the Kubernetes Master Center, which implements the resource management of the entire cluster, Pod scheduling, flexible scaling, security control, system monitoring and error correction and other management functions, and are all automatically completed. Run Kubelet, proxy, Docker daemon three components on each node to manage the lifecycle of the pod on this node, and to implement the service proxy functionality.

Process
A request to create an RC is submitted via Kubectl, which is written to Etcd via API server, where controller manager hears the RC event through the interface of the API server's monitoring resource changes, and after analysis, found that the current cluster does not have its corresponding pod instances, so based on the pod template definition in RC to generate a Pod object, through the API server to write ETCD, then this event was scheduler found, it immediately executes a complex scheduling process, Select a settled node for this new Pod and write it to ETCD via API server, and then the Kubelet process running on target node monitors this "newborn" Pod through API server, and according to its definition, Start the pod and take charge of it for the rest of the day, until the pod's life is over.

Then we submit a new creation request for a service mapped to the pod via Kubectl, Controller Manager will query the associated pod instance through the label label and generate endpoints information for the service. and written to Etcd via API server, the proxy process running on all node then queries and listens to the service object and its corresponding endpoints information through API server. A software-mode load balancer is established to realize the traffic forwarding function of service access to the back-end pod.

Etcd
Used to persist all resource objects in the storage cluster, such as node, Service, Pod, RC, namespace, and so on; API server provides a wrapper interface API for manipulating ETCD, which is essentially an interface for adding additions and deletions to resource objects in a cluster and monitoring resource changes.

API Server
Provides a unique entry point for the resource object, all other components must manipulate the resource data through the APIs it provides, and these components can perform the relevant business functions "in real Time" by "Full volume query" + "Change monitoring" for the relevant resource data.

Controller Manager
Cluster internal Management control center, the main purpose is to achieve the Kubernetes cluster fault detection and recovery automation, such as the definition of the RC pod to complete the reproduction or removal, to ensure that the number of Pod instances in accordance with the definition of RC copy; According to the relationship between service and pod management, The creation and updating of the endpoints object for the service, other tasks such as node discovery, management and status monitoring, disk space occupied by the death container, and the cleanup of the locally cached mirrored files are also performed by controller manager.

Scheduler
The scheduler in the cluster is responsible for the dispatch and distribution of pod in the cluster node.

Kubelet
Responsible for the lifecycle management of pod creation, modification, monitoring, deletion, etc. on node nodes, and kubelet the status information of "Escalation" node to API server.

Proxy
Implement the service agent and software model of the load balancer.

The client accesses the Kubernetes system through the Kubectl command-line tool or Kubectl proxy, and clients within the Kubernetes cluster can manage the cluster directly using the KUBERCTL command. Kubectl Proxy is a reverse proxy for API server, and clients outside the Kubernetes cluster can access the API server via Kubernetes Proxy.

API server has a complete set of security mechanisms, including authentication, authorization and access control and other related modules.

Https://www.cnblogs.com/menkeyi/p/7134460.html