In this post, I will give a high-level Kubernetes pods infrastructure consumption view. One might think of Kubernetes as a container management system. But, in fact, the smallest entity to be scheduled in a Kubernetes cluster is the pod. The Persistent Volume Claim (PVC) and the IP will be properties of the pod that contains the container.
Kubernetes pods infrastructure consumption
The required CPU and memory for running the pod are also possible entries when defining your container. The required memory and CPU entries will tell the scheduler to find a node in the cluster that has free capacity to run these containers.
The limits on CPU and memory will maintain the usage of these resources within these constrains. If the application use more CPU than the limit, Kubernetes will throttle your CPU to be bellow the limit.
Kubernetes also might kill your pod if it consumes more than the memory limit. If you see pods with OOMKilled status, you will need to check what is wrong. Either you have a too small memory limit or you may have a memory leak. .
Although the containers are ephemeral you still need a place to store data. For that, any container on the pod can mount a Persistent Volume Claim on any existing path. This means two containers might mount the same PVC on different paths on the same pod. Even if the PVC is ReadWriteOnce (RWO). To learn more about Persistent Volumes (PV) and Persistent Volume Claims (PVC) check back this blog next week. I will post more on PVs and PVCs.
All containers shares the IP address assigned to the pod. That means the applications, even on different containers inside the same pod, can not use the same ports because they will conflict.
If anyone that got curious on this matter, I created a more advanced post for you that would like to get deeper understanding.