Pod
In Kubernetes the containers are not deployed directly on the Worker Node, the containers are encapsulated in a Kubernetes object called Pod. It is a single instance of an application, it is also the smallest object that we can create in Kubernetes
When the application load increases, we can increase the number of the Pods of the application on the Worker Node to handle the traffic, if we reach the maximum capacity of the node, we can add another Worker Node to the Cluster to further expand the cluster and handle the additional load.
It is necessary to understand that the Pod and the container have a one to one relation and it is not recommended to run more than one container in any pod, if the application container needs to have a helper container which needs to live alongside with the main container, we can achieve this using Sidecar Container, these can be the applications that process something on the background like file upload or file processing, another use case would be helper container to monitor the main container using tools like Prometheus, Mimir or Thanos
The containers in the same pod can communicate with each other using localhost as they are in the same Namespaces, they also share the same storage space as well
Kubernetes Pod
Link to original
Static Pods
We can schedule Pods on a worker node without the Kube API Server, pods scheduled in this manner are called Static Pods, Pods created in this manner are ignored by the Kube Scheduler
the Kubelet can create pods without the intervention of the API server by reading the manifest files from the Worker Node and manages them as necessary by creating them when a new file is added, recreation when the manifest file changes and deletion when the file has been removed
Pods created in this manner are known to the Control Plane Node and the Kube API Server , as there exists a mirror object of the pod on the cluster, but the API server cannot modify the state of the static pod as the replica exists as a read only object.
This is the way the Control Plane Node is deployed using the Kubeadm tool, we setup the Kubelet on the Control Plane Node and add the manifests files to the Control Plane Node, all the components of the cluster such as Kube Proxy ETCD Kube DNS and other server components are deployed as pods and managed by the Kubelet as at the end of the day they are pods
Init Containers
When we want to run a container before we run another container, such as download file or download a binary just before