Today, I will continue to introduce the relevant knowledge of Linux operation and maintenance. The main content of this article is the core object of Kubernetes.
1. Pod resource object
A Pod resource object is a collection of one or more application containers, storage resources, dedicated IPs, and other resources that support the operation of containers. In a Kubernetes cluster, a Pod is a cluster and the smallest scheduling unit of Kubernetes. The word "Pod" means "pod" in English, which is extended to the smallest scheduling unit in a Kubernetes cluster.
In a Kubernetes cluster, containers in a Pod all run on one node, and different Pods are in a network segment and can communicate with each other. It should be noted that in a Kubernetes cluster, the access of any node to the Pod is equivalent. For example, if the Pod resource runs on Node1, the Pod resource can also be accessed on other Nodes or on the Master. access.
In a Pod, different containers share network and storage volumes . After a Pod is created, Kubernetes assigns the Pod an IP address. All containers in a Pod share the network and UTS namespace, including hostname, IP address, and port. The mutual access between the containers inside the Pod node needs to use the local loopback address, and the access to the containers inside the Pod from the outside of the Pod needs to be completed with the help of the traffic forwarding of the Service object. Pods can be configured with a set of "storage volumes" resources that are shared by all containers in the Pod. And even if the Pod object is down or deleted, the data on the storage volume still exists, thus realizing the persistent storage of data in the full declaration cycle of the Pod.
Kubernetes supports Pod expansion, that is, if a single Pod cannot meet huge access requirements, multiple Pod instances can run in a Kubernetes cluster, and each instance is called a "replica". The creation and management of these "copy" objects is usually implemented by the Controller controller.
When a Pod is created, you can use the Pod Preset object to inject specific information into the Pod, such as ConfigMap, Secret, storage volume, mounted volume, and Metadata data. With the Pod Preset object, the creator of a Pod template does not need to provide all the information for each template display, and therefore, does not need to know every detail of Pod creation. After Kubernetes receives the command to create a Pod, it will schedule the Pod to run on a selected node, which will start the container in the local container running environment. The Master will save the state of the entire cluster to ETCD and share it with the components of the cluster and clients through the API Server.
In a Kubernetes cluster, a Pod has a declaration cycle. It is created manually by the operation and maintenance personnel or directly by the controller until the process ends, and then it is deleted. In addition, other reasons such as worker node or scheduler failure, node resource exhaustion, etc. will also cause Pod objects to be deleted.
2. Controller resource object
In a Kubernetes cluster, Controller is used to manage Pod objects. Through the Controller, the Pod will run according to our settings, including the number of copies of the Pod, the creation of the Pod, the expansion, the update of the shrinkage, and the automatic recovery.
Controller Controller itself is also a resource type. Commonly used are Replication Controller, Deployment, StatefulSet, DaemonSet, and Jobs.
The definition of a Controller generally consists of the desired number of Pod replicas, a Pod template, and a label selector. The Controller will match the labels of the Pod objects according to the label selector, and all Pods that meet the conditions will be counted as a copy.
3. Service resource object
The schematic diagram of the Service object in a Kubernetes cluster is as follows:
In a Kubernetes cluster, there are three forms of Service resource objects. The first is the Cluster IP type that is only used for internal communication within the cluster; the second is the NodePort type that accesses external requests from the cluster ; The third is the LoadBalancer type that implements load balancing between Nodes . Each of these three types is premised on the realization of the former.
The Service of the Cluster IP type can only be used for intra-cluster communication. In this mode, the Service provides an IP address upwards, and forwards data traffic to each Pod downwards. For devices inside the Kubernetes cluster, access to the Service IP and access to the Pod IP result in the same of. Moreover, whether it is Pod IP or Service IP, it is only within the Kubernetes cluster. However, the advantage of Cluster IP is that once the Pod object is deleted and restarted, the IP address of the Pod will change, but the IP address of the Service will remain unchanged.
The Service of NodePort type retains all the functions of the Cluster IP, and at the same time binds a port of the Node node to the service port of the Pod object, so that we can realize the IP and port of the Node node outside the cluster. Access, and then access the Pod service in the Kubernetes cluster. In addition, a great advantage of the Kubernetes cluster is that the Service of NodePort type will take effect on any Kubernetes cluster node, which means that our access to the service can be achieved through any node in the Kubernetes cluster.
Based on the implementation of the NodePort type Service, if a load balancer is provided outside the Kubernetes cluster to load balance user requests to each Node node, it becomes a LoadBalancer type Service. This load balancing component does not accept Kubernetes clusters. Therefore, it needs to cooperate with the components outside the cluster to achieve.
Originality is not easy, please indicate the source for reprinting: https://blog.csdn.net/weixin_40228200