(°0°)
Pod Overview
A Pod is the basic execution unit of a Kubernetes application–the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your Cluster .
Multi-container pods
The primary purpose of a multi-container Pod is to support co-located, co-managed helper processes for a primary application. There are some general patterns for using helper processes in Pods:
- Sidecar
containers “help” the main container. Some examples include log or data change watchers, monitoring adapters, and so on. A log watcher, for example, can be built once by a different team and reused across different applications. Another example of a sidecar container is a file or data loader that generates data for the main container. - Proxies, bridges, and adapters
connect the main container with the external world. For example, Apache HTTP server or nginx can serve static files. It can also act as a reverse proxy to a web application in the main container to log and limit HTTP requests. Another example is a helper container that re-routes requests from the main container to the external world. This makes it possible for the main container to connect to localhost to access, for example, an external database, but without any service discovery.
Communication
- Networking
Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers inside a Pod can communicate with one another using localhost. When containers in a Pod communicate with entities outside the Pod, they must coordinate how they use the shared network resources (such as ports). - Storage
A Pod can specify a set of shared storage Volumes . All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See Volumes for more information on how Kubernetes implements shared storage in a Pod. - IPC
Containers in a Pod share the same IPC namespace, which means they can also communicate with each other using standard inter-process communications such as SystemV semaphores or POSIX shared memory.
Dependencies and startup order
Currently, all containers in a Pod are being started in parallel and there is no way to define that one container must be started after other container.
But probably can set some containers as init ones , as refer
Pod and controller
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won’t survive an eviction due to a lack of resources or Node maintenance.
A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node.
attributes
nodeName, nodeSelector, (anti-)affinities(on pod), and taints/tolerations can be used to influence Pod scheduling
pause
The Infrastructure Container is often referred to as the pod “pause” container and is used to set up and hold the networking namespace and resource limits for each pod
others
master node is in taints state, no other pod would run on it.
pod: shared net/ipc/uts ns, but not mount/pid ns
creation
(°0°)
PLEG
[POD Lifecycle Event](https://developers.redhat.com/blog/2019/11/13/pod-lifecycle-event-generator-understanding-the-pleg-is-not-healthy-issue-in-kubernetes/refer
refer
refer2
(°0°)
- Kubelet will SyncLoop() and call Healthy() to relist(part of PLEG) all containers on that node and compare previous status to check the change every 10s. If the
takes more than 3min, it will report PLEG is not healthy. - PLEG may be caused by
- RPC timeout - too many pods on that node - relist deadlock(1.14) - failed at getting pod's CNI stack inforamtion
stop a pod
POD stop receiving request. when APIServer receive a stopping POD request, it will modity pod state in ETCD, and nodify all watchers like Kubelet, Endpoint Controller. Kubelet will send SIGTERM and Endpoint Controller will remove pod from endpoints and update API server, then kube-proxy watch notification from API server and update iptables.
(°0°)
(°0°)