DEV Community

Pavol Z. Kutaj
Pavol Z. Kutaj

Posted on

Explaining Pods in Kubernetes

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.

Image of Timescale

Timescale – the developer's data platform for modern apps, built on PostgreSQL

Timescale Cloud is PostgreSQL optimized for speed, scale, and performance. Over 3 million IoT, AI, crypto, and dev tool apps are powered by Timescale. Try it free today! No credit card required.

Try free

Top comments (0)

Billboard image

Try REST API Generation for Snowflake

DevOps for Private APIs. Automate the building, securing, and documenting of internal/private REST APIs with built-in enterprise security on bare-metal, VMs, or containers.

  • Auto-generated live APIs mapped from Snowflake database schema
  • Interactive Swagger API documentation
  • Scripting engine to customize your API
  • Built-in role-based access control

Learn more

đź‘‹ Kindness is contagious

Immerse yourself in a wealth of knowledge with this piece, supported by the inclusive DEV Community—every developer, no matter where they are in their journey, is invited to contribute to our collective wisdom.

A simple “thank you” goes a long way—express your gratitude below in the comments!

Gathering insights enriches our journey on DEV and fortifies our community ties. Did you find this article valuable? Taking a moment to thank the author can have a significant impact.

Okay