Mastering Kubernetes Core Components: Pods, ReplicaSets, Deployments & StatefulSets

1. Core Component Principles – Pod Fundamentals

1.1 What Is a Pod?

Pod can be seen as a container that encapsulates Docker containers, essentially a container for containers.

It is a virtualized group with its own IP address and hostname, using namespaces for resource isolation, similar to an independent sandbox.

A pod behaves like an independent host; it can contain one or multiple related containers that communicate via localhost.

1.2 What Is a Pod Used For?

When deploying services, a pod manages a group of related services; for example, a pod may contain several containers that together provide a complete application stack.

Understanding a group of related services: a request reaches Nginx, which forwards it to a web container, which then accesses a database; the response travels back through the chain to the user.

1.3 Implementing a Web Service Cluster

Simply replicate multiple pod instances; scaling up or down is achieved by adjusting the pod count.

1.4 How Pod Networking and Storage Work

Containers inside a pod have their own IP and ports; using IP:port for internal communication can affect performance, so Kubernetes uses a pause container to share network and storage.

Pod Underlying Mechanism

Before creating containers, a pause container is started to share network and storage.

All service containers share the pause storage, delegating data persistence to the pause container.

The pause container acts as the network interface for the group, allowing localhost communication with high performance.

2. ReplicaSet – Replication Controller

2.1 Basic Understanding

Purpose: manage the number of pod replicas to match the desired count.

Example: replicas = 3 creates three pod copies.

If a pod fails, the ReplicaSet immediately creates a new one to maintain the target count.

2.2 Differences Between ReplicaSet and ReplicationController

Both control pod replicas, but:

Same: provide the functionality described in 2.1.

Different: label selectors. ReplicaSet supports both single and composite selectors; ReplicationController only supports single selectors.

Labels (key=value) allow the controller to select the appropriate pods.

Because ReplicaSet offers richer functionality, it is recommended over ReplicationController in newer Kubernetes versions.

3. Deployment – Deployment Object

3.1 Rolling Updates

Deployments enable rolling updates by creating new pod versions (v2) to replace old ones (v1) without downtime.

3.2 Deployment Model

A Deployment works together with a ReplicaSet to support rolling updates.

Deployment creates a new ReplicaSet.

The new ReplicaSet creates new pods.

The hierarchy is: Deployment manages ReplicaSet, which manages pods; old pods are removed while old ReplicaSets remain for possible rollback.

4. StatefulSet – Deploying Stateful Services

4.1 Introduction

Containerizing stateful services like MySQL raises issues: container lifecycles can cause data loss, and pod restarts may also lose data.

Containers have lifecycles; crashes can lose data.

Pods also have lifecycles; restarting pod replicas may lose data.

Therefore, Deployments are suited for stateless services, while StatefulSet addresses stateful service challenges.

4.2 Understanding Stateful vs. Stateless Services

Stateful Service

Requires real-time data storage.

Removing a service from the cluster can disrupt network connectivity.

Stateless Service

No real-time data storage needed.

Removing a service does not affect the cluster because there is no data synchronization.

4.3 Deployment Model

StatefulSet deployment is similar to Deployment but uses PersistentVolumeClaims (PVC) for storage.

When a pod restarts, StatefulSet keeps the hostname unchanged, allowing the pod to reconnect to its previous data.