KCNA — Services & Endpoints

3 minute read

Services & Endpoints

Pods are ephemeral — they get new IP addresses every time they’re recreated. A Service provides a stable network endpoint to access a group of pods.

The Problem Services Solve

Without Services:
  Pod A (10.1.1.5) → dies → New Pod A (10.1.1.9)
  Client was connecting to 10.1.1.5 — now it's broken!

With Services:
  Service (10.96.0.1) → routes to Pod A, Pod B, Pod C
  Pods die and recreate → Service still works (stable IP)

How Services Work

A Service uses label selectors to find its backend pods:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web           # Route traffic to pods with label app=web
  ports:
  - port: 80           # Service port
    targetPort: 8080   # Container port
  type: ClusterIP

Service (web-service: 10.96.0.1:80)
    │
    ├── Pod A (app: web, 10.1.1.5:8080)
    ├── Pod B (app: web, 10.1.1.6:8080)
    └── Pod C (app: web, 10.1.2.3:8080)

Service Types

Type Access Use Case How It Works
ClusterIP Internal only Service-to-service communication Assigns a virtual IP accessible only within the cluster
NodePort External via node IP Development, testing Opens a port (30000-32767) on every node
LoadBalancer External via cloud LB Production external access Provisions a cloud load balancer (AWS ELB, GCP LB, etc.)
ExternalName DNS alias Mapping to external services Returns a CNAME record (no proxying)

ClusterIP (Default)

┌─── Cluster ───────────────────────────┐
│                                        │
│  Pod X → web-service (10.96.0.1:80)    │
│              │                         │
│              ├── Pod A (:8080)          │
│              ├── Pod B (:8080)          │
│              └── Pod C (:8080)          │
│                                        │
└────────────────────────────────────────┘
         ❌ External access blocked

NodePort

External Client → Node IP:30080
                       │
                       ▼
                  web-service (10.96.0.1:80)
                       │
                       ├── Pod A (:8080)
                       └── Pod B (:8080)

LoadBalancer

External Client → Cloud Load Balancer (public IP)
                       │
                       ▼
                  web-service (10.96.0.1:80)
                       │
                       ├── Pod A (:8080)
                       └── Pod B (:8080)

Endpoints

An Endpoint object is automatically created for each Service. It lists the IP addresses of all pods that match the Service’s selector.

Service: web-service
  selector: app=web
  
Endpoints:
  - 10.1.1.5:8080  (Pod A)
  - 10.1.1.6:8080  (Pod B)
  - 10.1.2.3:8080  (Pod C)

When pods are added or removed, the Endpoints object is automatically updated by the Endpoints Controller.

Service Discovery

Pods find services using two methods:

CoreDNS resolves service names automatically:

DNS Name Format
Short form web-service (same namespace)
Full form web-service.default.svc.cluster.local

2. Environment Variables

When a pod starts, Kubernetes injects environment variables for every existing Service:

WEB_SERVICE_SERVICE_HOST=10.96.0.1
WEB_SERVICE_SERVICE_PORT=80

DNS is preferred because it works regardless of Service creation order.

Ingress

While Services expose applications, Ingress provides HTTP/HTTPS routing:

Feature Service (LoadBalancer) Ingress
Protocol TCP/UDP (any) HTTP/HTTPS only
Routing One service per load balancer Multiple services behind one entry point
SSL termination Not built-in Built-in
Path-based routing No Yes (/api → api-service, /web → web-service)
Host-based routing No Yes (api.example.com → api-service) 
Client → Ingress Controller (single entry point)
              │
              ├── /api    → api-service → api pods
              ├── /web    → web-service → web pods
              └── /admin  → admin-service → admin pods

Exam note: Know what Ingress is and how it differs from Services. You don’t need to know how to configure Ingress Controllers for KCNA.

Key Takeaways for the Exam

  • Services provide stable network endpoints for ephemeral pods
  • ClusterIP (default) = internal only; NodePort = external via node port; LoadBalancer = external via cloud LB
  • Services use label selectors to find backend pods
  • Endpoints are auto-managed lists of pod IPs for each Service
  • DNS (CoreDNS) is the recommended way for pods to discover services
  • Ingress provides HTTP routing (path-based, host-based) and SSL termination
  • kube-proxy implements Service-to-Pod routing on each node

What’s Next?

Let’s learn how to organize resources with Namespaces and Labels.

Namespaces & Labels →

Updated:

You may also enjoy