Que sont les Services dans Kubernetes, et quelle est la différence entre ClusterIP, NodePort et LoadBalancer ?

Question

IT Interview Practice · Accepted Answer

Un **Service** donne une identité réseau stable (une IP virtuelle et un nom DNS) à un *ensemble de Pods* sélectionnés par labels. Comme les Pods sont éphémères et changent d'IP, le Service est l'adresse durable que les clients utilisent, et il **répartit la charge (load-balance)** sur les Pods sains derrière lui.

## Pourquoi les Services existent

```text
Les Pods vont et viennent (nouvelle IP à chaque fois). Les clients ont besoin d'un ENDPOINT STABLE.
Un Service :
  → sélectionne les Pods par label  (selector: app=web)
  → obtient une IP virtuelle fixe + un nom DNS (web.default.svc.cluster.local)
  → répartit les requêtes sur les Pods correspondants et PRÊTS (Ready)
```

## Les trois principaux types de Service

```text
ClusterIP    (par défaut) → joignable UNIQUEMENT à l'intérieur du cluster
                            pour la communication pod-to-pod / service interne
NodePort                 → ouvre un port sur CHAQUE node (30000-32767)
                            le trafic externe atteint nodeIP:nodePort → Service → Pods
LoadBalancer             → provisionne un load balancer cloud externe
                            donne une IP publique qui route vers le Service
```

```text
       Internet
          │
   ┌──────┴───────┐
   │ LoadBalancer │  (cloud LB, public IP)   ← for public services
   └──────┬───────┘
          │
   ┌──────┴───────┐
   │  NodePort    │  (node:30080)            ← exposes on each node
   └──────┬───────┘
          │
   ┌──────┴───────┐
   │  ClusterIP   │  (10.96.x.x, internal)   ← the base building block
   └──────┬───────┘
       Pods (app=web)
LoadBalancer s'appuie sur NodePort, qui s'appuie sur ClusterIP.
```

## ClusterIP (interne)

```yaml
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP          # par défaut ; peut être omis
  selector:
    app: web               # correspond aux Pods labellisés app=web
  ports:
    - port: 80             # port du Service
      targetPort: 8080     # port du conteneur
```

Les autres Pods l'atteignent par DNS : `http://web` (même namespace) ou `http://web.default.svc.cluster.local`.

## NodePort et LoadBalancer

```yaml
# NodePort — chaque node écoute sur nodePort et transfère vers le Service
spec:
  type: NodePort
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080      # optionnel ; 30000-32767
---
# LoadBalancer — le cloud provisionne un LB externe avec une IP publique
spec:
  type: LoadBalancer
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080
```

```bash
kubectl get svc            # voir les types, les cluster IPs et les external IPs
kubectl get endpoints web  # les IPs réelles des Pods derrière le Service
```

## Pourquoi c'est important

Les Services sont la façon dont fonctionne le networking dans Kubernetes, donc les comprendre ainsi que la hiérarchie des types est une connaissance essentielle et quotidienne. Parce que les Pods sont éphémères et reçoivent de nouvelles IPs à chaque recréation, vous ne pouvez pas pointer les clients directement vers les IPs des Pods ; un **Service** résout cela en fournissant une **IP virtuelle et un nom DNS stables** devant un ensemble de Pods sélectionnés par label, et en **répartissant la charge** du trafic uniquement sur les Pods qui sont Ready. Les trois types forment une progression en couches : **ClusterIP** (par défaut) donne une adresse purement interne pour la communication pod-to-pod et service-to-service, et c'est le bloc de construction de base ; **NodePort** ouvre un port fixe sur chaque node pour que le trafic externe puisse atteindre le Service ; et **LoadBalancer** va plus loin en provisionnant un load balancer cloud externe avec une IP publique — chaque type s'appuyant sur celui du dessous. Savoir lequel choisir — ClusterIP pour le trafic microservice interne, NodePort pour un accès externe basique ou des setups on-prem, LoadBalancer pour exposer un endpoint public sur un cloud (et, en pratique, un Ingress devant des Services ClusterIP pour le routage HTTP) — est central pour concevoir comment les composants se parlent entre eux et avec le monde extérieur. Puisque presque chaque workload réel a besoin d'une connectivité stable et de load balancing, comprendre les Services et leurs types est une connaissance fondamentale du networking Kubernetes qui revient constamment, tant en conception qu'en débogage.

Pourquoi les Services existent

Les trois principaux types de Service

ClusterIP (interne)

NodePort et LoadBalancer

Pourquoi c'est important

Questions connexes