Service selectors and labels in Kubernetes - Commands & Configuration

Introduction

When you run multiple parts of an app in Kubernetes, you need a way to connect them. Service selectors and labels help services find the right pods to send traffic to, like a mailman delivering letters to the right houses.

When you want a service to send traffic only to specific pods running your app.

When you have multiple versions of an app running and want to route traffic to one version.

When you want to organize pods by roles or features and connect services accordingly.

When you need to update or scale parts of your app without affecting others.

When you want to monitor or manage groups of pods easily by their labels.

Config File - service.yaml

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  labels:
    app: my-app
    tier: frontend
spec:
  containers:
    - name: my-app-container
      image: nginx:1.23
      ports:
        - containerPort: 8080

This file creates two resources:

• Service: Named my-app-service, it uses a selector to find pods with labels app: my-app and tier: frontend. It listens on port 80 and forwards traffic to port 8080 on matching pods.
• Pod: Named my-app-pod, it has labels app: my-app and tier: frontend so the service can select it. It runs an nginx container exposing port 8080.

Commands

This command creates the service and pod defined in the YAML file. It sets up the connection between the service and the pod using labels and selectors.

Terminal

kubectl apply -f service.yaml

Expected Output

service/my-app-service created

pod/my-app-pod created

This command lists all pods with their labels so you can verify the pod has the correct labels for the service selector.

Terminal

kubectl get pods --show-labels

Expected Output

NAME          READY   STATUS    RESTARTS   AGE   LABELS

my-app-pod    1/1     Running   0          10s   app=my-app,tier=frontend

→

--show-labels - Displays the labels assigned to each pod

This command shows the service details, confirming it is created and ready to route traffic to pods matching its selector.

Terminal

kubectl get service my-app-service

Expected Output

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE

my-app-service   ClusterIP   10.96.0.1       <none>        80/TCP    15s

This command gives detailed information about the service, including the selector labels and endpoints (pods) it routes to.

Terminal

kubectl describe service my-app-service

Expected Output

Name:              my-app-service

Namespace:         default

Labels:            <none>

Annotations:       <none>

Selector:          app=my-app,tier=frontend

Type:              ClusterIP

IP:                10.96.0.1

Port:              80/TCP

TargetPort:        8080/TCP

Endpoints:         10.244.0.5:8080

Session Affinity:  None

Events:            <none>

Key Concept

If you remember nothing else from this pattern, remember: services use selectors to find pods by their labels and route traffic only to those matching pods.

Common Mistakes

Not adding matching labels to pods that the service selector expects.

The service will not find any pods to send traffic to, so your app won't receive requests.

Always add the exact labels to pods that match the service selector keys and values.

Using different label keys or values in the service selector and pod labels.

Selectors must exactly match labels; any difference means no pods are selected.

Double-check that selector keys and values exactly match the pod labels.

Forgetting to expose the correct container port that the service targets.

The service forwards traffic to a target port; if the pod container does not expose it, traffic fails.

Ensure the containerPort in the pod matches the targetPort in the service.

Summary

Create pods with labels that describe their role or version.

Create services with selectors that match those pod labels to route traffic correctly.

Use kubectl commands to apply configs and verify pods and services are connected.

Practice

1. What is the main purpose of a selector in a Kubernetes Service?

easy

A. To match labels on pods so the service knows which pods to send traffic to

B. To define the IP address of the service

C. To specify the container image used by pods

D. To set resource limits for pods

Solution

1. Step 1: Understand what selectors do

   A selector in a Kubernetes Service is used to find pods with matching labels.

2. Step 2: Connect selectors to pods

   The service uses the selector to route traffic only to pods that have the matching labels.

3. Final Answer:

   To match labels on pods so the service knows which pods to send traffic to -> Option A

4. Quick Check:

   Selector matches pod labels [OK]

Hint: Selector matches pod labels to connect service and pods [OK]

Common Mistakes:

• Thinking selector sets IP or image
• Confusing selector with resource limits
• Assuming selector is for service IP

2. Which of the following is the correct way to specify a selector in a Service YAML to match pods with label app: frontend?

easy

A. matchLabels:
app: frontend

B. labels:
app: frontend

C. podSelector:
app: frontend

D. selector:
app: frontend

Solution

1. Step 1: Identify correct selector syntax in Service YAML

   The Service spec uses selector: followed by key-value pairs to match pod labels.

2. Step 2: Compare options

   selector: app: frontend uses selector: with app: frontend, which is correct. Others use incorrect keys like labels, matchLabels, or podSelector which are not valid in Service spec.

3. Final Answer:

   selector: app: frontend -> Option D

4. Quick Check:

   Service selector key is 'selector' [OK]

Hint: Service selector key is always 'selector' not 'labels' or others [OK]

Common Mistakes:

• Using 'labels' instead of 'selector'
• Confusing with pod label syntax
• Using 'matchLabels' which is for label selectors, not Service

3. Given this Service selector:

selector:
  tier: backend
  env: prod

Which pods will this Service select?

medium

A. Pods with label tier=backend only

B. Pods with labels tier=backend and env=prod

C. Pods with label env=prod only

D. Pods with either tier=backend or env=prod

Solution

1. Step 1: Understand selector matching logic

   A Service selector matches pods that have all the specified labels with exact values.

2. Step 2: Apply to given selector

   The selector requires pods to have both tier=backend and env=prod labels to be selected.

3. Final Answer:

   Pods with labels tier=backend and env=prod -> Option B

4. Quick Check:

   Selector matches all labels, not any [OK]

Hint: Selector matches pods with all labels, not just one [OK]

Common Mistakes:

• Thinking selector matches pods with any one label
• Ignoring one of the labels in selector
• Confusing OR with AND logic in selectors

4. You have a Service with this selector:

selector:
  app: myapp
  version: v1

But your pods have labels:

app: myapp
version: v2

What is the problem?

medium

A. The Service selector syntax is invalid

B. The Service will select pods with version v2 anyway

C. The Service selector does not match any pods because version labels differ

D. Pods need a label 'service: myapp' to be selected

Solution

1. Step 1: Compare Service selector and pod labels

   The Service selector requires version: v1, but pods have version: v2.

2. Step 2: Understand label matching rules

   Labels must match exactly for the pod to be selected. Different version values mean no match.

3. Final Answer:

   The Service selector does not match any pods because version labels differ -> Option C

4. Quick Check:

   Exact label match required for selection [OK]

Hint: Labels must match exactly; different values mean no selection [OK]

Common Mistakes:

• Assuming partial label match works
• Thinking selector syntax is wrong
• Believing extra pod labels are needed

5. You want a Service to select pods with label app=web but exclude pods with label env=dev. How can you configure the selector?

hard

A. Use a selector with app: web and add a matchExpressions to exclude env=dev

B. Use selector:
app: web
env: !dev

C. Set selector:
app: web
env: dev

D. Label pods with app=web and remove env label from dev pods

Solution

1. Step 1: Understand label selector limitations

   Simple selectors only match labels present; to exclude labels, use matchExpressions with operators.

2. Step 2: Use matchExpressions to exclude

   You can specify matchExpressions with operator NotIn to exclude pods with env=dev.

3. Step 3: Review options

   Use a selector with app: web and add a matchExpressions to exclude env=dev correctly describes using matchExpressions to exclude labels. Use selector: app: web env: !dev syntax is invalid. Set selector: app: web env: dev includes the label to exclude. Label pods with app=web and remove env label from dev pods is about pod labeling, not selector configuration.

4. Final Answer:

   Use a selector with app: web and add a matchExpressions to exclude env=dev -> Option A

5. Quick Check:

   Exclude labels using matchExpressions NotIn [OK]

Hint: Use matchExpressions with NotIn to exclude labels in selector [OK]

Common Mistakes:

• Trying to exclude labels with simple selector syntax
• Using invalid selector syntax like env: !dev
• Confusing pod labeling with selector configuration