Basic usage of pod

The requirement for long-running containers in the kubernetes system is: the main program needs to be running in the foreground all the time
If the docker container we create is running in the background
kuberlet creates a container that contains this containerAfter the Pod command, it is considered that the pod execution is completed, and the pod is destroyed immediately.
If a replicationController is defined for the pod, the system will monitor that the pod has terminated, and then copy the pod according to the RC definition.Quantity generates a new pod
Once this new pod is created, it enters an infinite loop after running the startup command
So kubernetes needs to start with the foreground command to create a docker image

Unable to transform the application executed in the foreground, use the open source tool supervisor to assist in the foreground operation function
Supervisor provides a mechanism that can start multiple background applications at the same time and keep the supervisor itself executing in the foreground, which can meet the needs of kubernetes for containersLocal startup requirements
A pod can be composed of one or more containers
When two containers are tightly coupled and combined into a whole to provide external services, the two containers should be packaged into one pod
When applications belonging to the same container access each other, they only need to communicate through localhost, so that this group of containers is bound in one environment

Static pod

Static pods are managed by kubelet and exist only on specific Nodes
They cannot be managed by api server and cannot be associated with replicationcontroller, deployment or daemonset
and kubelet cannot perform health checks on them
Static pods are always created by the kubelet and always run on the node where the kubelet is located