Kubernetes Core Objects: Pod, Deployment, Service, ConfigMap

Intermediate·3 min read·

Fast recall

Quick revision

Core answer

A Pod is the smallest deployable unit — one or more containers sharing network and storage. A Deployment manages a ReplicaSet which keeps a desired number of Pods alive, handling rolling updates and rollbacks. A Service gives that dynamic set of Pods a stable virtual IP and DNS name via a label selector. A ConfigMap stores non-sensitive configuration injected into Pods as env or mounted files. Together they form a layered abstraction with reconciliation loops keeping actual state equal to declared state.

Interview Answer3 min

In Kubernetes you never manage individual containers directly — you work with abstractions that the control plane continuously reconciles toward your declared desired state. The four you interact with constantly are Pod, Deployment, Service, and ConfigMap, and they form a hierarchy: Deployments manage ReplicaSets which manage Pods, Services route traffic to Pods by label selector, and ConfigMaps inject configuration at startup.

Pod — the smallest deployable unit

A Pod wraps one or more containers that share a network namespace and storage volumes — they communicate over localhost and share the same IP; you rarely create Pods directly in production for this reason.
Pods are ephemeral by design: when a node fails or a Pod is deleted, it is gone; the Deployment controller creates a replacement Pod, typically with a new IP — nothing should depend on a Pod's IP address directly.
The Pod spec sets resource requests and limits, liveness/readiness probes, environment variables, and volume mounts — all the container-level configuration lives here.

Deployment — the controller that keeps Pods running

A Deployment declares desired state: "run 3 replicas of payment-service:v2.1" — the controller loops continuously comparing actual versus desired and creates or deletes Pods to close any gap.
Under the hood, Deployments manage ReplicaSets — when you update the image tag, a new ReplicaSet is created and scaled up while the old one scales down; this two-layer design enables zero-downtime rolling updates.
kubectl rollout undo deployment/payment-service reverts to the previous ReplicaSet in seconds; Kubernetes keeps a configurable revision history (default 10) specifically for this.

Service — stable network identity for ephemeral Pods

Pods get new IPs on every restart, so nothing should route to a Pod IP directly; a Service creates a stable virtual IP (ClusterIP) and DNS name — payment-service.default.svc.cluster.local — that survives Pod restarts.
The Service uses a label selector to find its target Pods; kubectl get endpoints payment-service shows which Pod IPs are currently behind the selector.
Ingress sits in front of Services to terminate TLS and route HTTP by host or path to different backends — the Service itself handles TCP load balancing, not HTTP-layer routing.

ConfigMap — configuration separate from image

ConfigMaps inject configuration via envFrom for env vars or as mounted files; separating config from image means the same image runs in dev, staging, and prod with different ConfigMaps.
Updating a ConfigMap does not restart Pods automatically — use a checksum/config annotation on the Pod template or a tool like Reloader to trigger a rolling update on config change.
Use Secrets for sensitive data like database passwords and API keys — Secrets are base64 at rest which is not encryption; combine with RBAC and etcd encryption-at-rest for real protection.

Interview-ready guide

Interview answer

Pod — the smallest deployable unit

A Pod wraps one or more containers that share a network namespace and storage volumes — they communicate over localhost and share the same IP; you rarely create Pods directly in production for this reason.
Pods are ephemeral by design: when a node fails or a Pod is deleted, it is gone; the Deployment controller creates a replacement Pod, typically with a new IP — nothing should depend on a Pod's IP address directly.
The Pod spec sets resource requests and limits, liveness/readiness probes, environment variables, and volume mounts — all the container-level configuration lives here.

Deployment — the controller that keeps Pods running

A Deployment declares desired state: "run 3 replicas of payment-service:v2.1" — the controller loops continuously comparing actual versus desired and creates or deletes Pods to close any gap.
Under the hood, Deployments manage ReplicaSets — when you update the image tag, a new ReplicaSet is created and scaled up while the old one scales down; this two-layer design enables zero-downtime rolling updates.
kubectl rollout undo deployment/payment-service reverts to the previous ReplicaSet in seconds; Kubernetes keeps a configurable revision history (default 10) specifically for this.

Service — stable network identity for ephemeral Pods

Pods get new IPs on every restart, so nothing should route to a Pod IP directly; a Service creates a stable virtual IP (ClusterIP) and DNS name — payment-service.default.svc.cluster.local — that survives Pod restarts.
The Service uses a label selector to find its target Pods; kubectl get endpoints payment-service shows which Pod IPs are currently behind the selector.
Ingress sits in front of Services to terminate TLS and route HTTP by host or path to different backends — the Service itself handles TCP load balancing, not HTTP-layer routing.

ConfigMap — configuration separate from image

ConfigMaps inject configuration via envFrom for env vars or as mounted files; separating config from image means the same image runs in dev, staging, and prod with different ConfigMaps.
Updating a ConfigMap does not restart Pods automatically — use a checksum/config annotation on the Pod template or a tool like Reloader to trigger a rolling update on config change.
Use Secrets for sensitive data like database passwords and API keys — Secrets are base64 at rest which is not encryption; combine with RBAC and etcd encryption-at-rest for real protection.

03 · Deep dive