What is the primary purpose of a selector in a Kubernetes Service?
Think about how a Service knows which Pods to send traffic to.
A selector in a Service matches labels on Pods to determine which Pods receive traffic. It does not configure ports, IPs, or storage.
Given the following Pods with labels:
pod1: app=web, env=prod pod2: app=web, env=dev pod3: app=db, env=prod
What is the output of the command kubectl get pods -l app=web,env=prod --no-headers -o custom-columns=:metadata.name?
The command filters Pods matching both labels app=web and env=prod.
Only pod1 has both labels app=web and env=prod. pod2 has env=dev, pod3 has app=db.
You want to create a Service that routes traffic only to Pods labeled app=frontend and tier=production. Which selector configuration is correct?
Selectors use key-value pairs in YAML mapping format.
The selector must be a map with keys and values. Option A correctly defines two keys with their values. Option A is invalid syntax, A uses a list which is incorrect, and D uses a wrong key name.
You created a Service with selector app: backend. However, no traffic reaches the Pods. The Pods have labels app: backend and version: v1. What is the most likely cause?
Check Pod readiness and endpoints associated with the Service.
If Pods match the selector but are not ready or have no endpoints, the Service will not route traffic. Node location does not affect routing, and ClusterIP Services route traffic inside the cluster.
Arrange the steps in the correct order to expose a Deployment named myapp using a Service that routes traffic to its Pods via selectors.
Think about creating resources and applying them in order.
First define the Deployment with labels, then apply it. Next define the Service with matching selectors, then apply it. This ensures Pods exist before Service tries to select them.