Kubernetes Labels and Selectors

PostedDecember 26, 2021

UpdatedFebruary 17, 2026

Author -Rajkumar Aute

In the world of Kubernetes, where thousands of containers can run across hundreds of nodes, organization isn’t just a “nice-to-have” it is critical for survival. Labels and Selectors are the core mechanism Kubernetes uses to group, filter, and operate on these resources.

Unlike traditional systems where grouping is often hierarchical (folders, groups), Kubernetes uses a flat, loosely coupled tagging system. This allows for multidimensional organization without rigid structures.

Labels are for identifying attributes of objects that are meaningful to users, while Selectors are for grouping those objects.

Key Characteristics to Remember

Characteristic	Description
Key-Value Pair	Labels always come in two parts: a `key` and a `value` (e.g., `environment: production`).
Metadata Only	Labels do not affect the Pod’s actual application logic; they are just descriptive data attached to it.
Many-to-Many	One Pod can have multiple labels (e.g., `app: nginx`, `env: prod`), and many Pods can share the same label.
Queryable	You use “Selectors” (filters) to search for resources based on their labels.
Mutable	You can add, change, or remove labels from a running Pod at any time without restarting it.

Labels

Kubernetes is a dynamic environment. Pods come and go, get new IP addresses, and move between nodes. You cannot rely on static IDs or IPs to track them. This is where the decoupling power of Labels and Selectors comes in.

A Label is attached to a Kubernetes object at creation time or later. It stores identifying metadata. A Selector is a core grouping primitive used in Kubernetes. The API currently supports two types of selectors: equality-based and set-based. A Label Selector allows a client (user or another resource) to identify a set of objects. This is the glue that holds loosely coupled components together for example, a Service knows which Pods to send traffic to only because the Service’s selector matches the Pods’ labels.

Equality-Based

If you are just starting, focus on the “Equality-Based” selectors. This is the simplest form.

Syntax: key = value
Example: You have a web server Pod. You label it app: nginx.
Action: When you create a Service to expose this web server, you tell the Service: “Look for any Pod where app equals nginx app: nginx.”
Result: The Service finds your Pod and starts routing traffic to it. If you remove the label, the Service stops sending traffic instantly.

Set-Based Selectors

As you advance, you will need Set-Based Selectors. These allow for complex filtering.

Operators: in, notin, exists (key exists), doesnotexist.
Scenario: You want to update all apps that are in production OR staging environments, but NOT testing.
Selector Logic: environment in (production, staging).

You can also combine selectors. For example, in a kubectl command, you can use a comma to say “AND”: kubectl get pods -l environment=production,tier=frontend This fetches Pods that have both labels.

Syntax and Constraints

A valid label key has two segments: an optional prefix and a name, separated by a slash (/).

Name (Required):
- Max 63 characters.
- Must start and end with an alphanumeric character ([a-z0-9A-Z]).
- Can contain dashes (-), underscores (_), dots (.), and alphanumerics.
Prefix (Optional):
- DNS subdomain (e.g., devsecopsguru.in/).
- Max 253 characters.
- Note: The kubernetes.io/ and k8s.io/ prefixes are reserved for Kubernetes core components.

Example: Pod Definition with Labels

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
    environment: production
    tier: frontend
    owner: devops-team
spec:
  containers:
  - name: nginx
    image: nginx:latest

Key Components

Prefix (Optional): Used to avoid collisions (e.g., k8s.io/).
Name (Required): The main identifier (e.g., app).
Value (Optional): The data (e.g., nginx).

Benefits

Organization: Turns a chaotic list of 100 Pods into neat, filtered groups.
Automation: CI/CD tools rely on labels to know which Deployments to update.
Loose Coupling: Services don’t need to know the exact names of Pods; they just need to know the label.

Use Cases

Canary Deployments: Label 5% of your Pods with track: canary and 95% with track: stable.
Environment Separation: Use env: dev, env: stage, env: prod to keep resources distinct even if they live in the same cluster.
Debugging: Label a crashing Pod with status: investigating. This signals to your team that you are looking into it.

Common Issues

Typos: env: prod vs env: production. If you are not consistent, your Selectors will miss resources.
Selector Mismatch: Creating a Service that looks for app: frontend when your Pod is labeled name: frontend. The Service will find nothing.
Over-labeling: Adding 50 labels to every Pod makes the YAML file hard to read and manage.

Solutions

Validation: Use tools like kube-linter or admission controllers to enforce valid labels before the YAML is applied.
Automation: Use Helm charts or Kustomize to apply labels automatically so humans don’t make typing mistakes.
Documentation: Maintain a central list of “Standard Labels” that everyone must use.

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels

https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels

Selectors

If Labels are the “tags,” Label Selectors are the “search queries.” Selectors allow you to identify a set of objects based on their labels. This is the primary grouping mechanism in Kubernetes.

Labels are the Identity (Who am I?), and Selectors are the Group Definition (Who do I want?).

Key Characteristics to Remember

Characteristic	Description
The Bridge	Selectors are the only link between a Service/Deployment and its Pods. There is no hard-coded linking.
Equality-Based	The simplest type. Matches exact values. Uses `=`, `==`, or `!=`.
Set-Based	The powerful type. Matches a list of values. Uses `in`, `notin`, or `exists`.
Logic is “AND”	If you define multiple selectors (e.g., `app: ui`, `env: prod`), a Pod must have BOTH to be selected.
Live & Dynamic	Selectors never stop working. If you add a label to a running Pod right now, the Selector picks it up immediately.

The core logic of a Selector is Dynamic Grouping. In traditional IT, we used static IP addresses to connect servers. In Kubernetes, we use Selectors to create “Logical Sets.”

When a Deployment needs to know which Pods it manages, it uses a Selector. When a Service needs to know where to route a user’s request, it uses a Selector. This means you can scale from 1 Pod to 1,000 Pods, and you never have to update the Service configuration. The Service’s selector app=frontend automatically “catches” all 1,000 Pods because they all share that label.

There are two types of selectors supported by the Kubernetes API:

Equality-Based Selectors

These allow filtering by label keys and values. Three operators are allowed: =, ==, and !=.

environment = production: Selects resources where the key is environment and value is production.
tier != frontend: Selects resources where the key tier is present but the value is NOT frontend, or the key tier is missing entirely.

Keyword: matchLabels
How it looks in YAML:YAMLselector: matchLabels: app: my-web-app tier: frontend
What it means: “Find me all Pods that have the label app equal to my-web-app AND tier equal to frontend.”
Note: If a Pod has extra labels (like version: v1), it is still selected. It just needs to match the ones you asked for.

Tools for Beginners:

Kubectl: Try kubectl get pods --selector app=nginx. This is the manual way to run a selector.
Lens / OpenLens: Click on a Service in Lens, and it will auto-generate the selector query to show you exactly which Pods are being targeted.

Set-Based Selectors

These allow filtering keys according to a set of values. Operators are: in, notin, and exists (often implicitly checking just the key).

environment in (production, qa): Selects resources with environment set to either production OR qa.
tier notin (frontend, backend): Selects resources with tier NOT set to frontend or backend.
partition: Selects all resources that have a label with the key partition (value doesn’t matter).

Keyword: matchExpressions
Where used: Job, Deployment, DaemonSet, ReplicaSet (and node affinity).
Structure:

Bash

selector:
  matchLabels:
    app: backend  # Older style (Equality)
  matchExpressions: # Newer style (Set-based)
    - {key: tier, operator: In, values: [cache, database]}
    - {key: environment, operator: NotIn, values: [dev]}

selector:
  matchLabels:
    app: backend  # Older style (Equality)
  matchExpressions: # Newer style (Set-based)
    - {key: tier, operator: In, values: [cache, database]}
    - {key: environment, operator: NotIn, values: [dev]}

The Operators:
1. In: The value must be one of these (Logic: A OR B).
2. NotIn: The value must NOT be one of these.
3. Exists: The label key exists (value doesn’t matter).
4. DoesNotExist: The label key must not exist at all.

Tools for Advanced Users:

Kube-score: A static analysis tool that checks your YAMLs. It can warn you if your selectors are missing or targeting the wrong things.
Goldilocks: While mostly for resources, it helps visualize if your deployments (grouped by selectors) are set up correctly.

Key Components

matchLabels: Simple map of key-value pairs (Exact match).
matchExpressions: List of requirements (Set-based logic).
- key: The label key to check.
- operator: The logic (In, NotIn, Exists, DoesNotExist).
- values: The array of values to check against.

Use Cases

Release Management: Use a selector version: v2 to route traffic only to the new version of your app.
Debugging: Create a Service with a selector status: debug. Then, label any problematic Pod with status: debug to instantly pull it into a special “debugging network.”
Cleanups: kubectl delete pods -l tier=frontend deletes all frontend pods at once.

Benefits

Self-Healing: If a Pod dies, the ReplicaSet sees the number of “selected” Pods drop. It creates a new one to match the selector.
No Hardcoding: You never have to write an IP address in your code.
Load Balancing: The Service selector automatically distributes traffic to all matching Pods.

Common Issues

The “Orphaned” Service: You create a Service with selector app: nginx, but your Pods are labeled app: my-nginx. The Service points to nothing.
Selector Overlap: Two different Deployments have the same labels. The Service will send traffic to both sets of Pods randomly. This causes weird errors where 50% of requests fail.
Immutable Fields: Trying to edit a Deployment’s selector and getting an API error.

Solutions

Use kubectl get endpoints: This is the 1^st debugging command. If your Service has no endpoints, your Selector is wrong.
Label Verification: Before applying a Service, run kubectl get pods --show-labels to ensure your spelling matches exactly.
Unique Labels: Always include a unique label (like deployment-id) to prevent overlaps.

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#labelselectorrequirement-v1-meta

How Kubernetes Uses Them: The “Glue”

How Labels and Selectors Bind Everything

We have learned about Labels (the sticky notes) and Selectors (the filters). Now, let’s talk about the Glue the magic that connects them.

In Kubernetes, there are no cables. Everything is floating in the cluster. The “Glue” is simply a Matching Rule.

The Rule: A “Service” (or Deployment) constantly shouts: “I am looking for anyone with the tag app: frontend!”
The Match: Any Pod that has that tag instantly “sticks” to the Service.
The Magic: If you peel the label off a Pod, it instantly “unsticks” and falls away. The connection is broken, even though the Pod is still running.

The “Glue” is not a permanent weld; it is a magnetic attraction that only exists as long as the Label matches the Selector.

Key Characteristics to Remember

Characteristic	Description
Loose Coupling	The Service and Pod are independent. They don’t know each other’s IDs, only the labels.
Dynamic Binding	The connection is live. It is re-evaluated constantly (milliseconds).
Self-Healing	If a “glued” Pod dies, the Selector notices the gap and the Deployment creates a replacement to fill the glue spot.
Endpoint Object	The actual list of IPs that stick to a Service is stored in a hidden object called `Endpoints`.
Many-to-One	A single Service (Selector) can glue itself to hundreds of Pods (Labels) at once.

In Kubernetes, the “Glue” isn’t a static configuration. It is an active process managed by the Controller Manager.

Watch: The Controller watches the state of the cluster.
Filter: It applies the Selector (e.g., app=nginx) to the list of all running Pods.
Update: It updates the Endpoints object with the IP addresses of the matching Pods.
Repeat: If a Pod is added or removed, the loop runs again and updates the list instantly. This is why Kubernetes feels so responsive.

Service Discovery (Service -> Pods)

Focus on the Service-to-Pod connection. This is the most common use of the “Glue.”

Scenario: You have 3 Web Pods. You want one IP address to access all of them.
The Glue: The Service.
Visual:
- Pod A (app: web) <— GLUED —> Service (selector: app: web)
- Pod B (app: web) <— GLUED —> Service
- Pod C (app: db) <— X (No Glue) X —> Service

Tools:

kubectl get endpoints: This command reveals the glue. It shows you the IP addresses of the Pods that were successfully “caught” by the Service.

A Service explicitly uses a selector to determine which Pods to send traffic to.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: web           # This Service targets any Pod with label app=nginx
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Deployments & ReplicaSets (Controller -> Pods)

Now, look at the Deployment-to-ReplicaSet connection.

Ownership: A Deployment manages a ReplicaSet, and a ReplicaSet manages Pods. How does it know which Pods it owns? The Glue.
The “Orphan” Risk: If you manually remove a label from a running Pod that belongs to a Deployment:
1. The Deployment’s selector no longer matches the Pod.
2. The “Glue” breaks.
3. The Deployment thinks: “Oh no! I lost a Pod!”
4. It immediately creates a new Pod to replace it.
5. The old Pod is now an “Orphan” it is still running, but the Deployment ignores it.

Tools for Advanced Users:

kubectl get pods --show-labels: Essential for debugging broken glue.
kubectl label --overwrite: The tool to break or fix glue on the fly.

A Deployment manages a set of Pods. It must know which Pods it owns. It uses matchLabels or matchExpressions.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:  # The Pod template
    metadata:
      labels:
        app: nginx  # MUST match the selector above
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

Critical Rule: The spec.template.metadata.labels must match the spec.selector. If they don’t, the Deployment will fail to create the Pods (or will create them and immediately lose track of them).

Advanced: `matchExpressions`

For more complex logic in deployments (like “schedule this pod on nodes that are NOT in zone-a”), we use matchExpressions.

YAML

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

Best Practices & Recommended Labels

Don’t just use arbitrary names like foo=bar. Kubernetes recommends a standard set of labels to visualize and manage applications effectively across tools.

Key	Description	Example
`app.kubernetes.io/name`	The name of the application	`mysql`
`app.kubernetes.io/instance`	A unique name identifying the instance	`mysql-abcxzy`
`app.kubernetes.io/version`	The current version of the application	`5.7.21`
`app.kubernetes.io/component`	The component within the architecture	`database`
`app.kubernetes.io/part-of`	The name of a higher-level application	`wordpress`
`app.kubernetes.io/managed-by`	The tool being used to manage the operation	`helm`

Practice Lab

Executable YAML file that demonstrates Labels, Selectors (Equality & Set-Based), and the “Glue” logic.

1: Create k8s-labels.yaml and copy below code.

Bash

# ==============================================================================
# KUBERNETES LABELS & SELECTORS
# 
# This file demonstrates:
# 1. Best Practice Labeling (Standard Labels)
# 2. Equality-Based Selectors (Service -> Pod)
# 3. Set-Based Selectors (Deployment -> Pod)
# 4. The "Glue" Logic (How Services find Deployment Pods)
# ==============================================================================

# ------------------------------------------------------------------------------
# 1. THE "MANUAL" POD
# Use Case: A standalone pod to demonstrate rich metadata labeling.
# ------------------------------------------------------------------------------
apiVersion: v1
kind: Pod
metadata:
  name: manual-web-pod
  # --------------------------------------------------------------------------
  # LABELS: The "Sticky Notes"
  # These do not change how the pod runs, but they allow us to find it later.
  # --------------------------------------------------------------------------
  labels:
    # --- Standard Kubernetes Labels (Best Practice) ---
    app.kubernetes.io/name: my-web-app       # What application is this?
    app.kubernetes.io/instance: manual-01    # Which specific instance?
    app.kubernetes.io/version: "1.27"        # Version (Must be a string)
    app.kubernetes.io/component: frontend    # Architecture layer
    app.kubernetes.io/part-of: corporate-site # Higher-level system
    app.kubernetes.io/managed-by: kubectl    # What tool deployed this?
    
    # --- Custom Organization Labels ---
    environment: production
    tier: frontend
    owner: devops-team-a
    cost-center: "9901"
    
    # --- Operational Labels (for debugging/logic) ---
    status: stable
    security-scan: passed
spec:
  containers:
  - name: nginx
    image: nginx:alpine

---

# ------------------------------------------------------------------------------
# 2. THE SERVICE (THE "GLUE")
# Use Case: Demonstrates "Equality-Based" Selectors.
# This Service acts like a magnet. It attracts ANY Pod that matches its selector.
# ------------------------------------------------------------------------------
apiVersion: v1
kind: Service
metadata:
  name: web-service-glue
  labels:
    description: "public-entry-point"
spec:
  type: ClusterIP
  # --------------------------------------------------------------------------
  # SELECTOR: The "Filter" / "Search Query"
  # Logic: "Select ALL Pods where (app.kubernetes.io/name == my-web-app) AND (tier == frontend)"
  # --------------------------------------------------------------------------
  selector:
    app.kubernetes.io/name: my-web-app  # Equality Match
    tier: frontend                      # Equality Match
    
    # CRITICAL NOTE: This selector will match:
    # 1. The 'manual-web-pod' defined above.
    # 2. The Pods created by the Deployment defined below.
    # PROOF: Run 'kubectl get endpoints web-service-glue' to see all IPs grouped together.
  ports:
  - port: 80
    targetPort: 80

---

# ------------------------------------------------------------------------------
# 3. THE DEPLOYMENT (THE "MANAGER")
# Use Case: Demonstrates "Set-Based" Selectors (Advanced).
# The Deployment manages Pods. It must find them to ensure 3 replicas exist.
# ------------------------------------------------------------------------------
apiVersion: apps/v1
kind: Deployment
metadata:
  name: advanced-web-deployment
  labels:
    app.kubernetes.io/name: my-web-app
spec:
  replicas: 3
  
  # --------------------------------------------------------------------------
  # ADVANCED SELECTOR: matchExpressions
  # This is more powerful than the simple key:value pair.
  # --------------------------------------------------------------------------
  selector:
    matchLabels:
      app.kubernetes.io/name: my-web-app  # Simple match
    matchExpressions:
      # Logic: Tier must be IN the list [frontend, ui, web]
      - key: tier
        operator: In
        values:
          - frontend
          - ui
          - web
      # Logic: Environment must NOT be 'dev' (Safety check)
      - key: environment
        operator: NotIn
        values:
          - dev
      # Logic: The label 'owner' must exist (Value doesn't matter, just the key)
      - key: owner
        operator: Exists

  # --------------------------------------------------------------------------
  # POD TEMPLATE: The Blueprint
  # The labels here MUST match the selector above, or the Deployment fails.
  # --------------------------------------------------------------------------
  template:
    metadata:
      labels:
        # These match the 'matchLabels' part
        app.kubernetes.io/name: my-web-app
        
        # These match the 'matchExpressions' part
        tier: frontend            # Is inside [frontend, ui, web] -> MATCH
        environment: production   # Is NOT [dev] -> MATCH
        owner: devops-automation  # Key 'owner' exists -> MATCH
        
        # Extra labels (ignored by selector, but useful for other tools)
        version: "2.0"
    spec:
      containers:
      - name: nginx
        image: nginx:alpine

---

# ------------------------------------------------------------------------------
# 4. THE "CANARY" SERVICE (TRAFFIC SPLITTING)
# Use Case: Demonstrates how to target a SUBSET of the same pods.
# ------------------------------------------------------------------------------
apiVersion: v1
kind: Service
metadata:
  name: canary-service-check
spec:
  type: ClusterIP
  selector:
    # This acts as an AND operator.
    # It will ONLY select pods that have BOTH labels.
    app.kubernetes.io/name: my-web-app
    version: "2.0" 
    
    # RESULT:
    # - Will it pick up 'manual-web-pod'? NO (It has version "1.27")
    # - Will it pick up Deployment pods? YES (They have version "2.0")
  ports:
  - port: 80
    targetPort: 80

# ==============================================================================
# KUBERNETES LABELS & SELECTORS
# 
# This file demonstrates:
# 1. Best Practice Labeling (Standard Labels)
# 2. Equality-Based Selectors (Service -> Pod)
# 3. Set-Based Selectors (Deployment -> Pod)
# 4. The "Glue" Logic (How Services find Deployment Pods)
# ==============================================================================

# ------------------------------------------------------------------------------
# 1. THE "MANUAL" POD
# Use Case: A standalone pod to demonstrate rich metadata labeling.
# ------------------------------------------------------------------------------
apiVersion: v1
kind: Pod
metadata:
  name: manual-web-pod
  # --------------------------------------------------------------------------
  # LABELS: The "Sticky Notes"
  # These do not change how the pod runs, but they allow us to find it later.
  # --------------------------------------------------------------------------
  labels:
    # --- Standard Kubernetes Labels (Best Practice) ---
    app.kubernetes.io/name: my-web-app       # What application is this?
    app.kubernetes.io/instance: manual-01    # Which specific instance?
    app.kubernetes.io/version: "1.27"        # Version (Must be a string)
    app.kubernetes.io/component: frontend    # Architecture layer
    app.kubernetes.io/part-of: corporate-site # Higher-level system
    app.kubernetes.io/managed-by: kubectl    # What tool deployed this?
    
    # --- Custom Organization Labels ---
    environment: production
    tier: frontend
    owner: devops-team-a
    cost-center: "9901"
    
    # --- Operational Labels (for debugging/logic) ---
    status: stable
    security-scan: passed
spec:
  containers:
  - name: nginx
    image: nginx:alpine

---

# ------------------------------------------------------------------------------
# 2. THE SERVICE (THE "GLUE")
# Use Case: Demonstrates "Equality-Based" Selectors.
# This Service acts like a magnet. It attracts ANY Pod that matches its selector.
# ------------------------------------------------------------------------------
apiVersion: v1
kind: Service
metadata:
  name: web-service-glue
  labels:
    description: "public-entry-point"
spec:
  type: ClusterIP
  # --------------------------------------------------------------------------
  # SELECTOR: The "Filter" / "Search Query"
  # Logic: "Select ALL Pods where (app.kubernetes.io/name == my-web-app) AND (tier == frontend)"
  # --------------------------------------------------------------------------
  selector:
    app.kubernetes.io/name: my-web-app  # Equality Match
    tier: frontend                      # Equality Match
    
    # CRITICAL NOTE: This selector will match:
    # 1. The 'manual-web-pod' defined above.
    # 2. The Pods created by the Deployment defined below.
    # PROOF: Run 'kubectl get endpoints web-service-glue' to see all IPs grouped together.
  ports:
  - port: 80
    targetPort: 80

---

# ------------------------------------------------------------------------------
# 3. THE DEPLOYMENT (THE "MANAGER")
# Use Case: Demonstrates "Set-Based" Selectors (Advanced).
# The Deployment manages Pods. It must find them to ensure 3 replicas exist.
# ------------------------------------------------------------------------------
apiVersion: apps/v1
kind: Deployment
metadata:
  name: advanced-web-deployment
  labels:
    app.kubernetes.io/name: my-web-app
spec:
  replicas: 3
  
  # --------------------------------------------------------------------------
  # ADVANCED SELECTOR: matchExpressions
  # This is more powerful than the simple key:value pair.
  # --------------------------------------------------------------------------
  selector:
    matchLabels:
      app.kubernetes.io/name: my-web-app  # Simple match
    matchExpressions:
      # Logic: Tier must be IN the list [frontend, ui, web]
      - key: tier
        operator: In
        values:
          - frontend
          - ui
          - web
      # Logic: Environment must NOT be 'dev' (Safety check)
      - key: environment
        operator: NotIn
        values:
          - dev
      # Logic: The label 'owner' must exist (Value doesn't matter, just the key)
      - key: owner
        operator: Exists

  # --------------------------------------------------------------------------
  # POD TEMPLATE: The Blueprint
  # The labels here MUST match the selector above, or the Deployment fails.
  # --------------------------------------------------------------------------
  template:
    metadata:
      labels:
        # These match the 'matchLabels' part
        app.kubernetes.io/name: my-web-app
        
        # These match the 'matchExpressions' part
        tier: frontend            # Is inside [frontend, ui, web] -> MATCH
        environment: production   # Is NOT [dev] -> MATCH
        owner: devops-automation  # Key 'owner' exists -> MATCH
        
        # Extra labels (ignored by selector, but useful for other tools)
        version: "2.0"
    spec:
      containers:
      - name: nginx
        image: nginx:alpine

---

# ------------------------------------------------------------------------------
# 4. THE "CANARY" SERVICE (TRAFFIC SPLITTING)
# Use Case: Demonstrates how to target a SUBSET of the same pods.
# ------------------------------------------------------------------------------
apiVersion: v1
kind: Service
metadata:
  name: canary-service-check
spec:
  type: ClusterIP
  selector:
    # This acts as an AND operator.
    # It will ONLY select pods that have BOTH labels.
    app.kubernetes.io/name: my-web-app
    version: "2.0" 
    
    # RESULT:
    # - Will it pick up 'manual-web-pod'? NO (It has version "1.27")
    # - Will it pick up Deployment pods? YES (They have version "2.0")
  ports:
  - port: 80
    targetPort: 80

2: Apply it.

Bash

kubectl apply -f k8s-labels.yaml.yaml

kubectl apply -f k8s-labels.yaml.yaml

3: Verify the “Glue” (Endpoints):

Run this command to see the Service connecting to the Pods:

Bash

kubectl get endpoints web-service-glue

kubectl get endpoints web-service-glue

You should see 4 IPs listed (1 manual pod + 3 deployment pods) because they all share the common labels app.kubernetes.io/name: my-web-app and tier: frontend.

4: Test the Canary Filter:

Bash

kubectl get endpoints canary-service-check

kubectl get endpoints canary-service-check

You should see only 3 IPs (Deployment pods only) because the manual pod has the wrong version.

Tech should learn

AWS(Draft)

AWS-Cloud-Tech

AWS-Compute

DevOps Essentials

DevSecOps Essentials(Draft)

CI/CD

GitHub Actions

Docker

Kubernetes (Draft)

The Kubernetes Foundation

Kubernetes Architecture

Kubernetes Setting Up the Lab

Kubernetes Namespace

Kubernetes Pod

Kubernetes Workload Controller

Programming

Python

Kubernetes Labels and Selectors

Key Characteristics to Remember

Labels

Equality-Based

Set-Based Selectors

Syntax and Constraints

Example: Pod Definition with Labels

Key Components

Benefits

Use Cases

Common Issues

Solutions

Selectors

Key Characteristics to Remember

Equality-Based Selectors

Set-Based Selectors

Key Components

Use Cases

Benefits

Common Issues

Solutions

How Kubernetes Uses Them: The “Glue”

Key Characteristics to Remember

Service Discovery (Service -> Pods)

Deployments & ReplicaSets (Controller -> Pods)

Advanced: matchExpressions

Best Practices & Recommended Labels

Practice Lab

Advanced: `matchExpressions`