This is an old revision of the document!
Overview
Finally, we managed to come to the atomic unit in Kubernetes: Pods. But what is a pod ? Well it is simple:
- Hypervisors have VM
- Docker have Containers
- Kuberenets have Pods
You can think of a pod of something between container and a VM. Unlike VM they are mortal, when they die, we just bring a new one, unlike containers though, they have IPs. Generally a pod has a single container in it, but there are exceptions. So let's see how it behaves as a VM and a Container:
Network
As we already mentioned, the atomic unit of scheduling in Kubernetes is the Pod, if we want to grow, we add pods, NOT containers. So, how these pods communicate with the outside world. Well, each pod has its own IP. If you remember, when we were configuring the cluster, we configured a pod network and we even configured Calico network to serve as a pod network and routing. (P.S. Calico is using BGP routing to provide path to the pods, you can see how to configure BGP routing protocol in my Cisco Configuration pages) Either way, so, to summarize:
- InterPod Communication - Via IP from the Pod Network (192.168.0.0 for calico)
- IntraPod Communication - Via Ports and using localhost as a reference to the pod
I know you are confused, so here is a visual reference:
InterPod Communication
IntraPod Communication
Lifecycle
The lifecycle of a pod is the following:
- We present a manifest file to the API server
- The api server loads the containers, download, install, all that crap and puts it in “pending” state
- If it doesn't fail it is put in “Running state”
- Again if it doesn't fail it is put in “Succeeded” state
- If it fails in any of the previous state, it is put in: “Failed state” and we have to inspect our manifest fail or whatnot. WE DON'T WORK WITH THE FAILED PODS, WE DON'T CARE, THEY ARE DEAD, FINITO :)
Here is a picture for visual reference of the above :