Kubernetes Services

The networking abstraction that provides stable, discoverable endpoints for ephemeral Pods. Services are the bridge between dynamic workloads and reliable client access — a core topic in the CKA “Services & Networking” domain (~20%). Synthesized from CKA Day 9 — Kubernetes Services Explained.

The Problem: Pods Are Ephemeral

Every Pod receives a unique internal IP address when it starts. But when a Pod restarts, crashes, or is rescheduled, it gets a new IP. If a front-end Pod tries to reach a back-end Pod at 10.244.1.2, that address becomes invalid the moment the back-end Pod restarts.

Services solve this by:

• Providing a stable virtual IP (ClusterIP) that never changes
• Maintaining an Endpoints list that automatically tracks which Pods are healthy backends
• Offering DNS resolution so clients use names (my-service) instead of IPs
• Enabling load balancing across multiple Pod replicas

Service YAML Anatomy

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    env: demo
spec:
  type: ClusterIP        # NodePort | LoadBalancer | ExternalName
  selector:
    app: nginx           # Must match Pod labels
  ports:
    - port: 80           # Service port (cluster-internal)
      targetPort: 80     # Pod container port
      nodePort: 30001    # Only for NodePort/LoadBalancer (30000-32767)

Field	Description	Required
apiVersion	v1 for Service	Yes
kind	Service (case-sensitive)	Yes
metadata.name	Unique name in namespace	Yes
spec.type	ClusterIP (default), NodePort, LoadBalancer, ExternalName	No
spec.selector	Label key-value pairs to match target Pods	Yes
spec.ports[].port	Port exposed by the Service inside the cluster	Yes
spec.ports[].targetPort	Port the container listens on	No (defaults to port)
spec.ports[].nodePort	Static external port (30,000–32,767)	No (auto-allocated)

YAML Tip: selector uses plain key-value pairs, not matchLabels. This is a common mistake — Services use selector: {app: nginx}, while Deployments/ReplicaSets use selector: matchLabels: {app: nginx}. Source: CKA Day 9

The Three Port Concepts

Understanding the distinction between these three ports is critical for both the exam and real-world debugging:

Port	Role	Audience
targetPort	The actual port the application container is listening on	The Service forwards traffic here
port	The port exposed by the Service within the cluster	Other Pods and Services in the cluster
nodePort	A static port opened on every node’s IP (30,000–32,767)	External users and clients outside the cluster

Example: A Nginx container listens on targetPort: 80. The Service exposes port: 80 for internal clients. If type: NodePort, it also opens nodePort: 30001 on each node’s IP. External traffic hits NodeIP:30001 → Service forwards to Pod at targetPort: 80.

How Services Route Traffic

1. The Service controller watches for Pods matching the selector
2. Healthy matching Pods are added to the Endpoints object
3. kube-proxy on each node programs iptables (or ipvs) rules to route traffic destined for the Service IP to one of the Endpoint IPs
4. The selection algorithm is typically round-robin (with iptables mode using random distribution)

User/Client
    │
    ▼
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  NodePort   │────▶│   Service   │────▶│   Pod 1     │
│  30001      │     │   ClusterIP │     │ 10.244.1.2  │
└─────────────┘     └─────────────┘     ├─────────────┤
                                        │   Pod 2     │
                                        │ 10.244.1.3  │
                                        ├─────────────┤
                                        │   Pod 3     │
                                        │ 10.244.2.5  │
                                        └─────────────┘

Endpoints and EndpointSlices

Endpoints are the dynamic backend list maintained by Kubernetes:

kubectl get endpoints        # List all endpoints
kubectl get ep               # Short form
kubectl describe svc <name>  # View endpoints attached to a service

When a Pod is created, restarted, or deleted, its IP is automatically added or removed from the Endpoints object. This is why Services remain stable even as Pods churn — the virtual IP is constant, but the backend IPs are continuously refreshed.

In large clusters, Kubernetes uses EndpointSlices (introduced in v1.21, default in v1.22+) to split endpoints into smaller, more scalable chunks instead of one large Endpoints object.

Essential kubectl Commands

Command	Purpose
kubectl get svc	List all Services
kubectl get service	Same as above
kubectl describe svc <name>	Detailed Service info including Endpoints
kubectl get endpoints	Show backend Pod IPs for all Services
kubectl apply -f service.yaml	Create/Update from manifest
kubectl delete svc <name>	Delete a Service
kubectl expose deployment <name> --port=80	Imperative Service creation

Imperative Service Creation (CKA Speed Pattern)

Writing full YAML under exam pressure is slow. Use imperative commands:

# ClusterIP (default)
kubectl expose deployment nginx-deploy --port=80
 
# NodePort with specific port
kubectl expose deployment nginx-deploy --type=NodePort --port=80 --target-port=80 --node-port=30001
 
# LoadBalancer
kubectl expose deployment nginx-deploy --type=LoadBalancer --port=80

CKA Tip: Imperative commands are ~3x faster than writing YAML from scratch. Practice them for the exam. Source: CKA Day 9

Troubleshooting Services

Symptom	Likely Cause	Fix
Service shows no Endpoints	Selector labels don’t match Pod labels	Check kubectl get pods --show-labels and align selectors
NodePort not accessible from host	Kind cluster missing extraPortMappings	Add port mapping in kind-config.yaml and recreate cluster
LoadBalancer pending external IP	No cloud provider integration	Use NodePort locally; on cloud, check CCM
Connection refused on targetPort	Application not listening on that port	Verify container’s containerPort matches targetPort
Service name not resolving	CoreDNS issues or wrong namespace	Use FQDN: <service>.<namespace>.svc.cluster.local

Sources

• CKA Day 9 — Kubernetes Services Explained

Related Pages

• Kubernetes Service Types — Deep dive into ClusterIP, NodePort, LoadBalancer, ExternalName
• Pod Fundamentals — Why Pods need Services (ephemeral IPs)
• Deployment, ReplicaSet & Replication Controller — The workloads Services expose
• Kind Cluster Setup — Port mapping for NodePort in local clusters
• Kubernetes Architecture — kube-proxy and service routing mechanics
• Kubernetes Namespaces — Namespace-scoped services and cross-namespace DNS
• CKA Certification — Exam domains and weightings
• CKA Study Roadmap — Day 9 in the 40-day learning plan

---

Tags: kubernetes services clusterip nodeport loadbalancer externalname networking cka devops endpoints kube-proxy