Kubernetes Services — Essential Concepts — Resources

Project projet11-kubernetes-services · useful theory before (or during) the practice.

Why a Service?

A Pod is ephemeral: it can be deleted, recreated, moved to another node — and its IP address changes. Impossible, then, to hard-code a Pod IP.

The Service solves this problem: it provides a stable address (IP + DNS name) and automatically distributes traffic to all Pods that match its label selector.

The Service → Pods link is not a frozen IP: it is a label selector. Kubernetes maintains the list of matching Pods by itself (the Endpoints).

The three main types

1. ClusterIP (default)

Internal cluster IP address, unreachable from the outside.
Used for communication between Pods (e.g. the frontend calls the backend).
Basis of service discovery: reachable by DNS name (http://demo-clusterip).

2. NodePort

Opens a fixed port on every node (range 30000–32767).
Simple external access: http://<node-ip>:<nodePort> (here http://localhost:30082).
Handy in dev/local; rarely exposed as-is in production.

3. LoadBalancer

Asks the infrastructure for an external IP.
In the cloud (AWS/GCP/Azure): provisions a real load balancer.
With Docker Desktop: the EXTERNAL-IP becomes localhost (http://localhost:8090).

Comparison table

Type	Scope	Access	Typical use case
ClusterIP	Internal	Internal DNS name	Database, internal API, Pod↔Pod communication
NodePort	External	`localhost:<30000-32767>`	Demo / local dev
LoadBalancer	External	Public IP (localhost locally)	Public service in cloud production

There is also ExternalName (DNS alias to an external service) and Ingress (HTTP/HTTPS routing by domain name, seen later) — outside this project.

Service discovery (internal DNS)

Kubernetes runs CoreDNS in the cluster. Each Service receives a DNS name:

<service-name>                       # from the same namespace
<service-name>.<namespace>           # from another namespace
<service-name>.<namespace>.svc.cluster.local   # full name (FQDN)

Thus, from any Pod in the same namespace:

bash

curl http://demo-clusterip            # resolved by CoreDNS -> Service IP -> a Pod

Service and Endpoints

The Service defines what to expose (via the selector).
The Endpoints are the real list of matching Pod IP:port, updated automatically by Kubernetes.

bash

kubectl get endpoints demo-clusterip   # shows the Pod IPs behind the Service

If no Pod matches the selector → empty Endpoints → the Service answers “no backend” (connection refused).
That is error #1: a Pod label that does not match the Service selector.

To remember

A Service = stable address + load balancing + label selector.
ClusterIP (internal, DNS), NodePort (node port), LoadBalancer (external IP).
Service discovery is done by DNS name thanks to CoreDNS.
Endpoints dynamically link the Service to its Pods.

Course created by Dr. Haythem REHOUMA — Development and Deployment of Data Solutions