What is a Kubernetes Service? A beginner guide to stable networking

You learned that Pods run your containers and Deployments keep them running — see Pods vs Deployments if you need a refresher. The next question every beginner hits: how does traffic reach those Pods? Pod IP addresses change. A Service is Kubernetes’ answer — a stable way to send traffic to the right Pods.

This guide explains what a Service is, why you need one, how selectors connect Services to Pods, the main Service types, and the kubectl commands that make the relationship visible on a real cluster.

The one-sentence version

• Pods get ephemeral IP addresses — they change when Pods restart.
• A Service provides a stable name and IP (or external access) in front of a set of Pods.
• You match Services to Pods using labels and selectors — not by hard-coding Pod names.

Why Pod IP alone is not enough

Each Pod has its own IP on the cluster network. That sounds fine until a Pod is recreated: new Pod, new IP. If your frontend hard-coded pod-api-7d4f8b9c-xk2lm:8080, the next restart breaks the connection.

• Deployments replace Pods — IP addresses are not stable identifiers
• Multiple replicas mean multiple Pod IPs — clients need one entry point
• Services abstract away which specific Pod answers a request

What is a Service?

A Service is a Kubernetes API object that defines a logical set of Pods and a policy to access them. Inside the cluster, other workloads usually reach your app at a DNS name like api.default.svc.cluster.local — backed by the Service, not a single Pod.

Client / another Pod
        │
        ▼
   Service "api"  (stable ClusterIP + DNS)
        │
        ├── Pod api-aaa111
        ├── Pod api-bbb222
        └── Pod api-ccc333

Selectors: how the Service finds Pods

A Service does not list Pod names. It uses a label selector. For a full beginner walkthrough, see labels and selectors explained. Your Deployment labels Pods with app: api; the Service selects app: api. When replicas scale up or Pods restart, the Service automatically includes matching Pods.

apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: default
spec:
  selector:
    app: api          # must match Pod template labels
  ports:
    - port: 80        # Service port
      targetPort: 8080 # container port
  type: ClusterIP

If selector labels do not match any Pod, the Service exists but nothing receives traffic — a very common beginner bug.

Service types (beginner view)

Most in-cluster traffic uses ClusterIP. You expose to the internet with LoadBalancer (or Ingress on top — a later topic).

Endpoints: proof the Service has backends

Kubernetes maintains an Endpoints (or EndpointSlice) object listing the Pod IPs that match the Service selector. If Endpoints is empty, your Service has no backends — check labels on the Deployment template and the Service selector.

kubectl get services
kubectl get svc -n staging
kubectl describe service api -n default

kubectl get endpoints api -n default
kubectl get pods -l app=api -n default --show-labels

Common beginner mistakes

• Service selector does not match Pod labels → Endpoints empty, connection refused
• targetPort wrong → Service forwards to a port nothing listens on
• Calling a Pod IP directly in config instead of the Service name
• Expecting ClusterIP to be reachable from your laptop without port-forward or LoadBalancer

Same checks in natural language (optional)

kprompt turns plain English into a reviewable plan before anything reaches the cluster. Listing and describing Services is read-only. Mutations still require approval.

kprompt "list services in staging"
kprompt "describe service api in default"
kprompt "get endpoints for api in staging"

What to learn next

Pods run workloads. Deployments keep Pod counts stable. Services give those Pods a stable address inside (and sometimes outside) the cluster. Still mixing Service and Deployment? Read Service vs Deployment. Next in this beginner series: Namespaces — how to organize resources across teams and environments.