The concept of
pod A pod is a collection of a set of containers. Multiple containers are placed in a pool, and this pool is called a pod. Pods can be divided into two categories, autonomous pods and controller-managed pods. Autonomous pods are not managed by the controller (if they die, they are gone, except for the administrator to start them again). The pods that are controlled and managed have a continuous life cycle and are managed by the controller.
Pod controller RC, RS, Deployment, HPA, StatefulSet, DaemonSet, Job, Cronjob
RC: ReplicationController, used to ensure that the number of copies of the container application always remains at the user-defined number of copies, that is, if the container exits abnormally, it will be created automatically Replace with new pods; and if the abnormally more containers will automatically recycle
RS: ReplicaSet and RC are just different names, and RS supports collective slelctor
Deployment: Automatic management of ReplicaSet. No need to worry about incompatibility with other mechanisms, support rolling update (rollong-update)
Horzontal Pod Autoscaling: only applicable to Deployment and ReplicaSet, in the V1 version only supports expansion and contraction based on the CPU utilization of the pod, in the V1alpha version, support According to memory and user-defined metrics,
StatefulSet is designed to solve the problem of stateful services. The application scenarios of the device include:
1 Stable persistent storage, that is, the same persistence can be accessed after the pod is rescheduled. Data, based on PVC to achieve
2 stable network logo, that is, after pod rescheduling, its podName and HostName remain unchanged, based on HeadlessService (headless service), that is, there is no ClusterIP Service to achieve
3 orderly deployment and orderly expansion. That is, pods are in order, and they must be deployed or expanded in sequence according to the defined order (that is, from 0 to n-1, all previous pods must be running and ready before the next pod runs), based on init containers Realize
4 orderly shrink, orderly delete (that is, from n-1 to 0)
DaemonSet: Ensure that a copy of a pod is running on all or some nodes. When a node joins the cluster, it will also add a pod for them. When a node is removed from the cluster, these pods will also be recycled. Deleting the DaemonSet will delete all pods it created.
Some typical usages of using DaemonSet:
1) Run cluster storage deamon. For example, run glusterd and ceph on each node
2) Run a log collection daemon
on each node , such as fluentd, logstash 3) Run a monitoring daemon on each node, such as Prometheus Node Exporter
Job: Responsible for batch processing tasks, that is A task that is executed only once, it guarantees that one or more pods of the batch processing task will successfully end
CronJob: Manage jobs based on time, that is, run once at a given point in time; run periodically at a given point in time
Pod's network communication method
pause: the first container in the pod, which provides network infrastructure settings for the entire pod, so the overall NetworkSettings only has lock settings in the pause container, and it is responsible for the content and init Similar, including the sharing of the namespace set by the basic network and the handling of zombie processes
Flannel four CoreOS team designed a network planning service for Kubernetes. Its function is to make the Docker containers of different nodes in the cluster have the unique virtual IP address of the entire cluster. And it can also establish a sub-high (Overlay Network) between these IP addresses, through this overlay network, the data packet is passed to the target container intact and the
same pod internal communication: the same pod shares the same network name Space, sharing the same linux protocol stack (applications that call frequently are placed in the same pod, such as nginx and php-fpm)
Pod1 and pod2 communicate: pod1 and pod2 are on the same machine, and the docker0 bridge directly forwards the request to pod2, There is no need to
communicate through flannel pod1 and pod3: pod1 and pod3 are not on the same host, the address of pod is on the same network segment as docker0, but the network segment of docker0 and the host network card are two completely different IP addresses, and different nodes Communication between them can only be carried out through the physical network card of the host computer. The IP and IP related pod where the node is up, so that through this association pod can visit each other (the second package forwarding achieve fannel, etcd, packet)
pod to service networks: currently based on performance considerations, and all maintenance as iptables Forward the
pod to the external network: The pod sends a request to the external network, looks up the routing table, and forwards the data packet to the host's network card. After the host network card completes the routing selection, iptables insists on Masquerade, changes the source IP to the host network card IP, and then goes out Web server sends request