Kubernetes Day-9: Labels, Selectors, ReplicaSets, and Deployment YAML Explained

In the previous days of this Kubernetes journey, we explored Pods, Replication Controllers, Deployments, Rolling Updates, and Rollbacks. We learned how Kubernetes helps us deploy applications with minimal downtime and provides mechanisms to recover from failures automatically.

As we move deeper into Kubernetes, understanding how resources identify and manage workloads becomes extremely important. In real-world production environments, a Kubernetes cluster may contain hundreds or even thousands of Pods running multiple applications across different teams.

This raises an important question:

How does Kubernetes know which Pods belong to which application?

The answer lies in Labels and Selectors.

In this article, we'll cover:

• Labels and Selectors

• Equality-Based Selectors

• Set-Based Selectors

• ReplicaSets

• Difference between Replication Controller and ReplicaSet

• Deployment, ReplicaSet, and Pod relationship

• Creating Deployments using YAML

Let's dive in.

Why Labels and Selectors Matter

Kubernetes is designed to manage large-scale containerized applications.

Imagine an organization where multiple teams share the same Kubernetes cluster:

• Team A manages frontend applications.

• Team B manages backend services.

• Team C manages monitoring tools.

Each team may deploy dozens of applications, and each application may run multiple Pod replicas.

In such an environment, manually managing Pods becomes nearly impossible.

Kubernetes solves this problem using Labels and Selectors.

Understanding Labels

A label is simply a key-value pair attached to a Kubernetes resource.

Think of labels as tags that help categorize resources.

Example:

labels:
    app:frontend
    team: team1
    region: india
    environment: production

These labels provide meaningful information about the resource.

For example:

• app: frontend identifies the application.

• team: team1 identifies ownership.

• region: india identifies deployment location.

• environment: production identifies the environment.

The more descriptive your labels are, the easier it becomes to manage resources within a cluster.

You can think of labels as hashtags on social media platforms. They help Kubernetes quickly identify and group related resources.

What are Selectors?

Labels alone are not enough.

Kubernetes also needs a mechanism to search for resources using those labels.

This mechanism is called a Selector.

A selector continuously looks for resources matching specific label criteria.

Many Kubernetes resources use selectors internally:

• Services use selectors to find Pods.

• ReplicaSets use selectors to find Pods.

• Deployments use selectors to find ReplicaSets.

One important thing to remember:

Kubernetes never relies on Pod names or Pod IP addresses for management.

Since Pods are dynamic and their IP addresses can change at any time, labels provide a stable way to identify resources.

Equality-Based Selectors

Initially, Kubernetes supported only Equality-Based Selectors.

These selectors work using:

• =

• ==

• !=

Examples

Find all Pods belonging to Team 1:

kubectl get pods -l team=team1

Find all Pods running in India:

kubectl get pods -l region=india

Find all Pods that do not belong to Team 2:

kubectl get pods -l team!=team2

Equality-Based Selectors work well for simple filtering scenarios.

However, as Kubernetes environments became larger and more complex, more flexible searching capabilities were needed.

Set-Based Selectors

To overcome the limitations of Equality-Based Selectors, Kubernetes introduced Set-Based Selectors.

These selectors support:

• In

• NotIn

• Exists

• DoesNotExist

Examples

Display Pods running in India or the US:

kubectl get pods -l 'region in (india,us)'

Display Pods belonging to Team 1 or Team 2:

kubectl get pods -l 'team in (team1,team2)'

Exclude Pods running in India and the US:

kubectl get pods -l 'region notin (india,us)'

Set-Based Selectors are significantly more powerful because they allow multiple values and more advanced filtering conditions.

This flexibility becomes essential in enterprise-scale Kubernetes clusters.

ReplicaSet vs Replication Controller

Many Kubernetes beginners assume that Replication Controller and ReplicaSet are completely different resources.

In reality, they serve a very similar purpose.

Both are responsible for maintaining the desired number of Pod replicas.

However, there is one major difference.

The word "Set" in ReplicaSet comes from its ability to use Set-Based Selectors.

This enhancement provides significantly better Pod management capabilities.

Common Misconception About ReplicaSets

A very common misunderstanding is:

ReplicaSets handle rollouts and rollbacks.

This is incorrect.

ReplicaSet responsibilities include:

• Maintaining desired replica count

• Self-healing Pods

• Ensuring desired state

Deployment responsibilities include:

• Rolling updates

• Rollbacks

• Deployment strategies

• Version management

In simple terms:

ReplicaSet → Maintains Pods

Deployment → Manages ReplicaSets

Creating a ReplicaSet

ReplicaSet is a modern Kubernetes resource and uses:

apiVersion: apps/v1

kind: ReplicaSet

A ReplicaSet specification typically contains:

• Metadata

• Replica count

• Selector Pod

• Template

The selector tells Kubernetes which Pods should be managed.

The Pod template tells Kubernetes how to create new Pods when needed.

matchLabels vs matchExpressions

ReplicaSets support two selector methods.

matchLabels

Used for Equality-Based Selection.

Example:

selector:
    matchLabels:
        environment: production

Equivalent to:

environment = production

matchExpressions

Used for Set-Based Selection.

Example:

selector:
    matchExpressions:
    - key: team
      operator: In
      values:
      - team1
      - team2

Equivalent to:

team in (team1, team2)

This capability is one of the biggest advantages ReplicaSets provide over Replication Controllers.

Relationship Between Deployment, ReplicaSet, and Pods

This is one of the most important concepts in Kubernetes.

Many people assume that Deployments create Pods directly.

That is not true.

The actual hierarchy looks like this:

                        Deployment
                            ↓
                        ReplicaSet
                            ↓
                           Pods

What happens behind the scenes?

Deployment:

• Monitors ReplicaSets

• Manages updates and rollbacks

ReplicaSet:

• Monitors Pods

• Maintains replica count

Pods:

• Run application containers

For example:

kubectl create deployment mydeploy --image=httpd

Kubernetes internally performs:

                    Deployment Created 
                           ↓
                    ReplicaSet Created 
                           ↓
                       Pod Created

This layered architecture provides:

• Self-healing

• Scalability

• High Availability

• Easy upgrades

If a Pod is deleted:

ReplicaSet creates a new Pod

If a ReplicaSet is deleted:

Deployment creates a new ReplicaSet

Each resource continuously monitors the layer below it.

Deployment Using YAML

Deployments can be created using CLI commands.

Example:

kubectl create deployment mydeploy --image=httpd

However, CLI-based deployments have limitations.

In production environments, YAML files are preferred because they provide complete control over deployment configuration.

With YAML, we can:

• Configure replicas

• Define selectors

• Customize labels

• Configure rolling updates

• Add annotations

• Define deployment strategies

A Deployment internally contains a ReplicaSet template, just as a ReplicaSet contains a Pod template.

That is why understanding ReplicaSets is essential before creating Deployment YAML files.

Final Thoughts

Today's concepts form the foundation of Kubernetes workload management.

We learned how Labels and Selectors help Kubernetes identify resources, how ReplicaSets ensure the desired number of Pods are always running, and how Deployments sit on top of ReplicaSets to provide advanced application lifecycle management.

The key takeaway is:

                        Deployment
                            ↓
                        ReplicaSet
                            ↓
                              Pods

Understanding this hierarchy makes it much easier to troubleshoot applications, design scalable architectures, and confidently work with Kubernetes in production environments.