🔧 Explaining Pods in Kubernetes

🕛 Zeit seit Veröffentlichung: 55 Tage, 20 Stunden 24 Minuten
📆 Veröffentlicht am: 11.10.2024 um 05:48 Uhr
Nachrichtenbereich: 🔧 Programmierung
🔗 Quelle: dev.to

The aim of this page📝 is to explain the concept of a pod in k8s from the five angles I find useful. A bit of context relating pods to containers and VMs, and the 3 essences of a pod: shared execution environment, scaling unit, and its ephemeral nature.

First/historically, the units of infrastructure scheduling are very in VM, Docker, and Kubernetes (k8s). 

• A VM environment is a virtual machine
• In the Docker environment, it is the container
• In Kubernetes, it is a pod

Yes — k8s run on orchestrated containers. But containers must always run within Pods

What differentiates pods from containers

My acronym is ALP.CC
1. annotation
2. labels (great for service objects <> pods and IP management)
3. policies
4. contraints (resouce)
5. co-scheduling

Essence #1: Shared execution environment

Pod is execution environment == collection of things an app needs to run**

Pod is 

• a thin wrapper k8s insists all container use
• shared execution environment
• IP address
• Port
• FS
• Memory

Every pod is an execution environment

Containers running in it share that environment — IP is shared between containers. 

Inside the pods, if they need to talk to each other - the pod hosting interface

If you have a usecase where >1 container need to share resources, they are in single pods. This is for specialist usecases. 

If not, make a loose coupling with container-per-pod and then connect them over the network

Essence #2: Scaling Unit/Reproduction

The Unit of scaling is the pod - you are adding/removing pods. You do not scale adding containers to existing pods. Scale up - add pods, scale down - remove pods. 

Multi-container pods — service mesh, injecting additional containers into the pod to get enhanced services. Complimentary container augmenting app container. 

Pod deployment is atomic operation — all or nothing job. Pod only ever shows up and running if all containers are up and running. 

All containers are always scheduled to the same node. 

There is a higher-level controller called Replica Set, wrapped into yet another higher-level controller called Deployment.

Once you introduce horizontal scaling, it's more appropriate to talk about the reproductions of pods as replicas. The terms are closely related but not identical.

Essence#3: Mortality. Pods are mortal, pods are cattle. 

Born, live, die. that's it. No magical coming back to life. Self-healing is misleading. A dead pod is not fixed. It's recreated. 

Pods are deployed via deployer - if pods don't bring anything valuable. Why not just containers?

However, that does not mean that they cannot be restarted. Quite the opposite, I often handle a "pod restart loop" situation during my support time.

...