Skip to content

Container vs Pod vs Deployment vs Replicaset


The previous lesson practically applied all of the Container, Pod, Deployment and ReplicaSet. And if you remmber — we even went nasty. Now, let’s see the difference — this time theoretically. Don’t skip seeing “theory”, concept matters the most. Examples and commands are everywhere in the internet but concept is rare — and it’s here. This is going to be brief.

See The Difference

Container

A Container image is basically your application packaged will all the dependencies your app requires to run in one place. That image can be run using a Container runtime such as containerd. Here’s the summary:

  • Container image → blueprint/package
  • Container → running instance of that image
  • containerd → runtime that creates and runs containers

Pod

A Pod is the definition of how one or more Containers should run together. It defines their execution environment and specifies details like:

  • which ports should be exposed
  • which volumes should be mounted and where
  • which network the Pod belongs to
  • environment variables, resource limits, security settings, etc.

A Pod is the smallest deployable unit in Kubernetes. It usually contains a single Container, but it can contain multiple tightly coupled Containers that share the same network and storage.

ReplicaSet

A ReplicaSet is a Kubernetes Controller that ensures N number of specified Pods exist at any given time. If a matching Pod is deleted or terminates, the ReplicaSet creates a replacement to maintain the desired number of Pods.

While a ReplicaSet can be deployed standalone, it’s recommended to use a Deployment instead. A Deployment manages ReplicaSets for you and provides features such as rolling updates and rollbacks.

Deployment

A Deployment is the most common way to deploy a stateless application inside a Kubernetes cluster. It is a Kubernetes Controller that manages ReplicaSets, which in turn ensure that the desired number (N) of Pods exist at any given time.

A Deployment is preferred over using a ReplicaSet directly because it provides a higher-level abstraction for managing the application’s Pods and ReplicaSets. It handles tasks such as rolling out new versions, rolling back to previous versions, and scaling the application.

If you create a ReplicaSet directly and the ReplicaSet itself is deleted, there is no higher-level controller responsible for recreating it. With a Deployment, however, the Deployment manages the ReplicaSet and can create a new ReplicaSet when needed to maintain the desired state.

Summary

“I have already mentioned — This is going to be brief — This is already the summary”.

Last updated on