Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to analyze the simple concept of K8s, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

K8s concept: basic concepts:

Cluster: cluster. The integration of computing and storage network resources.

Master: responsible for allocating and scheduling resources.

Kube-apiserver: the front-end interface of K8s Cluster, which is used to manage the resources of Cluster.

Kube-scheduler: responsible for deciding which Pod to run Pod on.

Kube-controller-manager: responsible for managing various resources in Cluster to ensure that the resources are in the desired state.

Etcd: responsible for saving the configuration information of K8s Cluster and the status information of various resources. When data transmission changes, etcd will quickly notify the relevant components of K8s.

Pod network: responsible for the communication between Pod, such as Flannel,Calico and so on.

Node: used to run applications, monitor the status of containers, managed by Matser, and support physical and virtual machines.

Kubelet: the Agent of Node. When Scheduler determines that Pod is running on a Node, it will send the specific configuration information of Pod (image,volume, etc.) to the kubelet,kubelet of that node to create and run containers based on this information, and report the running status to Master.

Kubeproxy:Service logically represents multiple Pod at the back end. Outsiders receive requests by accessing Pod,Service through Service. If there are multiple Pod copies, kube-proxy will achieve load balancing.

Pod network: responsible for the communication between Pod, such as Flannel,Calico and so on.

View all the components:

[root@k8smaster] # kubectl get pods-- all-namespaces-o wideNAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESkube-system coredns-bf7759867- 8h5x8 1 Running 1 21h 10.244.0.5 k8smaster kube-system coredns-bf7759867-slmsz 1/1 Running 1 21h 10.244.0.4 k8smaster kube-system etcd-k8smaster 1/1 Running 1 21h 192.168.43.45 k8smaster kube-system kube-apiserver-k8smaster 1/1 Running 1 21h 192.168.43.45 k8smaster Kube-system kube-controller-manager-k8smaster 1/1 Running 1 21h 192.168.43.45 k8smaster kube-system kube-flannel-ds-amd64- 6zhtw 1/1 Running 1 20h 192.168.43.136 k8snode1 kube-system kube-flannel-ds-amd64-wnh9k 1/1 Running 1 20h 192.168.43.45 k8smaster kube-system kube-flannel-ds-amd64-wqvz9 1/1 Running 1 20h 192.168.43.176 k8snode2 kube-system kube-proxy-2j8w9 1/1 Running 1 20h 192.168.43.176 k8snode2 kube-system kube-proxy-kqxlq 1/1 Running 1 20h 192.168.43.136 k8snode1 kube-system kube-proxy-nb82z 1/1 Running 1 21h 192.168.43.45 k8smaster kube-system kube-scheduler-k8smaster 1/1 Running 1 21h 192.168.43.45 K8smaster K8s Resource Abstract Type: Pod:

   Pod is a combination of several related containers, which can be understood as a group of one or more containers, and the containers are related to each other.

Containers in    Pod run on the same Host, and they use the same network command space, IP address, and port to discover and communicate with each other through localhost.

   in addition, these containers can also share a piece of storage volume space.

Summary:

Pod is the smallest unit of work in K8s, and each Pod contains one or more containers.

Containers contained in the same Pod run on the same Host, which is called a unified snap-in.

The same Pod shares the same volumes,network,namespace,ip,port through Mapped Container.

Pid ns: applications in the same Pod can see each other's progress.

Network ns: applications in the same Pod can access the same ip and port space.

Ipc ns: applications in the same Pod can communicate using systemV ipc or posix message queues.

UTC ns: share a hostname with the same Pod application.

Replication Controller (RC):

RC is used to manage Pod, and each RC consists of one or more Pod. After RC is created, the system will keep the number of Pod available in RC consistent with the number of Pod defined when creating RC. If the number of Pod is less than the defined number, RC will start a new Pod, otherwise it will kill the excess Pod.

RC is created through a defined Pod template, and the created object is called Pods (which can also be understood as RC). The properties of Pod can be modified online to achieve dynamic reduction and expand the scale of Pods.

RC associates the corresponding Pods through label, and deletes the corresponding Pods by modifying the label of the Pods. When you need to update the containers in the Pods, RC uses a replacement principle to update the Pod in the entire Pods.

Reschudeling: maintain a copy of Pod, "return more and make up less"; even if some minion downtime.

Scaling: expand or shrink running Pods horizontally by modifying the number of copies of RC.

Rolling updates: replace Pods one by one to update the service.

Multiple release tracks: if you need to run multiple release services on your system, Replication Controller uses labels to distinguish between multiple release tracks.

Label:

Label is the Key/Value key-value pair used to distinguish between Pod,Service,RC.

A Pod,Service,RC can have multiple Label, but the Key of each Label can only correspond to one Value.

The whole system is associated through Label to get the target that really needs operation.

Service:

   Service is defined as a set of abstract resources that run Pod collections in a cluster. It provides all the same functions. When a Service resource is created, a unique IP, also known as cluster IP, will be assigned. This IP address will exist in the entire life resources of Service. Once the Service is created, the entire IP cannot be modified.

   Pod can communicate through Service, and all traffic will be automatically load balanced to all containers in Pod through Service.

Service is the abstraction of real application services.

Service is typically used to associate floating resources with containers that actually provide services at the back end.

Service is externally represented as a single access interface, and there is no need to understand the scale and mechanism of the back end.

Controller:

   K8s usually does not create Pod directly, but uses Controller to manage the attributes of Pod defined in Pod,Controller. In order to meet different business scenarios, K8s provides a variety of Controller, including Deployment,Replicaset,Daemonset,Statefulset,Job and so on.

Deployement: the most commonly used Controller, used to manage multiple copies of Pod. And make sure that Pod is running as expected.

Replicaset: multi-replica management of Pod is implemented, and Replicaset is automatically created when using Deployment, that is, Deployment manages multiple copies of Pod through Replicaset, and usually does not require the use of Replicaset in the main section.

Daemonset: for scenarios where you can run at most one copy of Pod per node.

Statefuleset: can guarantee that the name of each copy of Pod will remain the same throughout the life cycle, while other Controller does not provide this function. When a Pod fails and needs to be deleted and restarted, the name of Pod will change, and Statefulset will ensure that the Pod copy will be started, updated or deleted in the specified order.

Job: used for applications that are deleted as soon as they are finished, while Pod in other Controller usually runs continuously for a long time.

Namespace:

   logically divides a physical Cluster into multiple virtual Cluster, and each Cluster is a Namespace. Different Namepace. The resources of each Cluster are separated.

View all Namespace

[root@k8smaster ~] # kubectl get namespaceNAME STATUS AGEdefault Active 19hkube-node-lease Active 19hkube-public Active 19hkube-system Active 19h running application flow: [root@k8smaster ~] # kubectl run http-app-- image=httpd-- replicas=2kubectl run-- generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run--generator=run-pod/v1 or kubectl create instead.deployment.apps/http-app created [root@k8smaster ~] # kubectl get deploymentsNAME READY UP-TO-DATE AVAILABLE AGEhttp-app 0There 22049s [root@k8smaster ~] # kubectl get pod-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEShttp -app-c5f548d75- 44hxm 0ta 1 ImagePullBackOff 0 21m 10.244.2.3 k8snode2 http-app-c5f548d75-kzlrt 0ta 1 ImagePullBackOff 0 21m 10.244.1.2 k8snode1 process:

Kubectl sends a deployment request to API Server.

API Server tells Controller Manager to create a deployment resource.

Scheduler performs scheduling tasks, and the tasks to be created are scheduled to the relevant nodes according to certain policies.

The Kubelet on the Node node is responsible for receiving and scheduling tasks, receiving and running pod on their respective nodes through Kubelet.

Node1:node1-http-app-c5f548d75-44hxm

Node2:node2-http-app-c5f548d75-kzlrt

After reading the above, do you have any further understanding of how to analyze the simple concept of K8s? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.