Services Kubernetes : exposer et connecter vos applications

Un Service Kubernetes permet d’exposer un ou plusieurs Pods via une adresse IP stable et un nom DNS interne. Comme les Pods sont éphémères et changent d’adresse IP, le Service fournit un point d’accès durable pour la communication réseau entre applications ou vers l’extérieur du cluster. Ce guide vous montre comment créer des Services, choisir le bon type (ClusterIP, NodePort, LoadBalancer) et diagnostiquer les problèmes de connectivité.

Prérequis : un cluster Kubernetes fonctionnel avec au moins un Deployment ou des Pods.

Ce que vous allez apprendre

• Créer un Service avec kubectl expose et avec un fichier YAML
• Choisir le bon type : ClusterIP, NodePort, LoadBalancer, Headless
• Comprendre la résolution DNS entre Pods et Services
• Utiliser les labels/selectors pour cibler les bons Pods
• Diagnostiquer quand un Service ne fonctionne pas

Ce qu’est un Service Kubernetes

Un Service est une abstraction réseau qui expose un groupe de Pods via une adresse IP stable et un nom DNS.

Pour un débutant, retenez simplement :

• Les Pods changent d’IP à chaque recréation
• Le Service garde une IP fixe qui redirige vers les Pods
• Les autres Pods appellent le Service par son nom, pas par IP

Analogie

Pensez au Service comme à un standard téléphonique : vous appelez un numéro unique (le Service), et l’appel est redirigé vers un employé disponible (un Pod).

Pourquoi utiliser des Services

Sans Services, chaque Pod devrait connaître l’adresse IP des autres Pods — une adresse qui change à chaque redémarrage.

Les Services résolvent ce problème en fournissant :

Fonctionnalité	Description
IP stable	Une adresse fixe qui ne change pas quand les Pods sont recréés
Nom DNS	Un nom comme backend-service au lieu d’une IP
Load balancing	Répartition automatique du trafic entre plusieurs Pods
Découverte	Les Pods trouvent les autres services par leur nom

Glissez pour voir

Exemple concret

Une application web avec :

• Un frontend (React)
• Un backend (API Node.js)
• Une base de données (PostgreSQL)

Le frontend appelle backend-service:8080 au lieu de chercher l’IP du Pod backend. Si le Pod backend redémarre avec une nouvelle IP, le Service redirige automatiquement.

Créer son premier Service

Méthode impérative : kubectl expose

La façon la plus rapide de créer un Service pour un Deployment existant :

kubectl expose deployment nginx --name=nginx-service --port=80 --target-port=80

Résultat : un Service ClusterIP nommé nginx-service qui expose le port 80.

Vérifiez sa création :

kubectl get svc nginx-service

Sortie

NAME            TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
nginx-service   ClusterIP   10.43.7.235   <none>        80/TCP    5s

Méthode déclarative : fichier YAML

Pour un contrôle total, créez un fichier manifest :

nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Les champs essentiels :

Champ	Description
selector	Labels des Pods à cibler (ici app: nginx)
port	Port exposé par le Service
targetPort	Port sur lequel écoutent les Pods
type	Type de Service (ClusterIP par défaut)

Glissez pour voir

Appliquez-le :

kubectl apply -f nginx-service.yaml

Selector crucial

Le selector doit correspondre aux labels de vos Pods. Si aucun Pod n’a ces labels, le Service n’aura pas d’endpoints.

Observer et inspecter un Service

Une fois votre Service créé, vérifiez qu’il fonctionne.

kubectl get svc : vue d’ensemble

kubectl get svc -o wide

Sortie

NAME            TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE   SELECTOR
nginx-service   ClusterIP   10.43.7.235   <none>        80/TCP    2m    app=nginx

Les colonnes importantes :

Colonne	Signification
TYPE	ClusterIP, NodePort, LoadBalancer…
CLUSTER-IP	Adresse IP interne du Service
PORT(S)	Ports exposés
SELECTOR	Labels utilisés pour trouver les Pods

Glissez pour voir

kubectl describe : détails complets

kubectl describe svc nginx-service

Cette commande montre :

• Endpoints : IPs des Pods ciblés par le Service
• Session Affinity : sticky sessions ou non
• Events : historique (rarement utile pour les Services)

Sortie (extrait)

Name:              nginx-service
Selector:          app=nginx
Type:              ClusterIP
IP:                10.43.7.235
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.42.0.9:80,10.42.1.8:80,10.42.1.9:80

Vérifier les Endpoints

Si Endpoints est vide (<none>), le selector du Service ne correspond à aucun Pod. Vérifiez les labels avec kubectl get pods --show-labels.

kubectl get endpoints : voir les Pods ciblés

kubectl get endpoints nginx-service

Sortie

NAME            ENDPOINTS                                AGE
nginx-service   10.42.0.9:80,10.42.1.8:80,10.42.1.9:80   5m

Chaque IP correspond à un Pod qui recevra du trafic.

Types de Services

Kubernetes propose quatre types de Services selon vos besoins d’exposition.

ClusterIP : communication interne (défaut)

Le Service est accessible uniquement depuis l’intérieur du cluster.

spec:
  type: ClusterIP  # ou omettez, c'est le défaut

Cas d’usage : communication entre microservices (backend ↔ base de données).

┌─────────────────────────────────────────────┐
│                  Cluster                     │
│                                              │
│   Frontend Pod  ──────►  backend-service    │
│                              │               │
│                              ▼               │
│                         Backend Pods         │
└─────────────────────────────────────────────┘

En pratique

ClusterIP est le type le plus courant. Utilisez-le par défaut pour tout ce qui ne doit pas être accessible de l’extérieur.

NodePort : exposition sur chaque nœud

Le Service est accessible via un port sur chaque nœud du cluster.

spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080  # optionnel, entre 30000-32767

Accès : http://<IP-du-noeud>:30080

Cas d’usage : tests locaux, environnements sans cloud provider.

┌─────────────────────────────────────────────────┐
│                                                  │
│  Internet/Réseau externe                        │
│        │                                         │
│        ▼ :30080                                  │
│  ┌─────────────┐     ┌─────────────┐            │
│  │   Node 1    │     │   Node 2    │            │
│  │   :30080    │     │   :30080    │            │
│  └──────┬──────┘     └──────┬──────┘            │
│         └────────┬──────────┘                   │
│                  ▼                               │
│            Service (ClusterIP)                  │
│                  │                               │
│                  ▼                               │
│               Pods                               │
└─────────────────────────────────────────────────┘

Limitation

NodePort expose le même port sur tous les nœuds. Si le port est déjà utilisé, la création échoue.

LoadBalancer : exposition via cloud provider

Le Service demande un équilibreur de charge externe au cloud provider (AWS, GCP, Azure…).

spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80

Accès : via l’IP externe fournie par le cloud (EXTERNAL-IP).

Cas d’usage : applications en production sur le cloud.

kubectl get svc

Sortie

NAME            TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
nginx-service   LoadBalancer   10.43.7.235   203.0.113.50     80:30262/TCP   2m

Environnement local

Sur K3d/minikube, EXTERNAL-IP reste en <pending> car il n’y a pas de cloud provider. Utilisez des solutions comme MetalLB pour simuler un LoadBalancer.

Quel type choisir ?

Besoin	Type recommandé
Communication interne	ClusterIP
Test local sans cloud	NodePort
Production sur cloud	LoadBalancer

Glissez pour voir

Cas particulier : ExternalName

Le type ExternalName est à part : il ne sélectionne pas de Pods et ne fait pas de proxy. Il redirige simplement vers un nom DNS externe.

spec:
  type: ExternalName
  externalName: database.example.com

Cas d’usage : pointer vers une base de données managée (RDS, Cloud SQL…). Les Pods appellent external-db et sont redirigés vers database.example.com.

Cas particulier : Headless Services

Un Headless Service (clusterIP: None) ne possède pas d’IP de cluster. Le DNS retourne directement les IPs des Pods au lieu de l’IP du Service.

spec:
  clusterIP: None
  selector:
    app: nginx

Service normal	Headless Service
DNS → IP du Service	DNS → IPs des Pods
Load balancing par kube-proxy	Client choisit le Pod

Glissez pour voir

Cas d’usage : bases de données stateful, StatefulSets avec identité réseau stable. Voir le guide StatefulSets pour plus de détails.

Résolution DNS

Kubernetes crée automatiquement des enregistrements DNS pour chaque Service.

Format du nom DNS

<service-name>.<namespace>.svc.cluster.local

Exemples

Appel depuis	Nom à utiliser
Même namespace	nginx-service
Autre namespace	nginx-service.production
Nom complet (FQDN)	nginx-service.production.svc.cluster.local

Glissez pour voir

Tester la résolution DNS

kubectl run test-dns --image=busybox:1.36 --rm -it --restart=Never -- nslookup nginx-service

Sortie

Server:    10.43.0.10
Address:   10.43.0.10:53

Name:      nginx-service.default.svc.cluster.local
Address:   10.43.7.235

En pratique

Utilisez toujours le nom du Service (ex: backend-service) plutôt que l’IP du cluster. Le nom reste valide même si l’IP change.

EndpointSlices

Kubernetes utilise aujourd’hui des EndpointSlices pour stocker efficacement les adresses des Pods derrière un Service. Dans la pratique, vous manipulerez surtout kubectl get endpoints ou kubectl describe svc. Les EndpointSlices sont utiles pour le debug avancé sur de gros clusters.

Option avancée : sessionAffinity

Par défaut, kube-proxy répartit le trafic aléatoirement. Pour garder un client sur le même Pod, ajoutez sessionAffinity: ClientIP :

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 600

Cas d’usage : websockets, sessions en mémoire. Attention : ne fonctionne pas bien derrière un proxy qui masque l’IP client.

Service ou Ingress ?

Une question fréquente : quand utiliser un Service, quand utiliser un Ingress ?

	Service	Ingress
Couche	L4 (TCP/UDP)	L7 (HTTP/HTTPS)
Routage	Par IP/port	Par path, host, headers
TLS	Non	Oui (terminaison)
Usage	Communication interne ou exposition simple	API publique, sites web

Glissez pour voir

Règle simple : utilisez un Service pour la communication interne ou l’exposition basique, un Ingress pour du routage HTTP avancé.

Ce qu’un Service ne fait PAS

Un Service Kubernetes est un outil Layer 4 (TCP/UDP). Il a des limitations :

Besoin	Solution
Routage HTTP (path, host)	Ingress
Terminaison TLS	Ingress + cert-manager
Filtrage de sécurité	NetworkPolicies
Rate limiting, circuit breaker	Service mesh

Glissez pour voir

Sécurité

Un Service seul n’offre aucune sécurité. Tout Pod du cluster peut appeler n’importe quel Service. Utilisez les NetworkPolicies pour restreindre le trafic.

Debug : diagnostiquer un Service

1. Aucun endpoint

Symptôme : Endpoints: <none> dans kubectl describe svc.

# Vérifier les labels des Pods
kubectl get pods --show-labels

# Comparer avec le selector du Service
kubectl get svc nginx-service -o jsonpath='{.spec.selector}'

Cause : le selector ne correspond pas aux labels des Pods.

2. TargetPort incorrect

Symptôme : curl nginx-service timeout ou connexion refusée.

kubectl describe svc nginx-service | grep TargetPort
kubectl exec -it nginx-pod -- netstat -tlnp

Cause : le targetPort ne correspond pas au port de l’application.

3. DNS défaillant

Symptôme : nslookup nginx-service échoue.

kubectl -n kube-system get pods -l k8s-app=kube-dns
kubectl run dns-test --image=busybox:1.36 --rm -it --restart=Never -- nslookup kubernetes

4. Test depuis un Pod de debug

kubectl run debug --image=nicolaka/netshoot --rm -it --restart=Never -- bash

Depuis ce Pod : curl, nslookup, dig, tcpdump…

Testez vos Connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Un Service donne une IP stable et un nom DNS à un groupe de Pods
2. Le selector doit correspondre aux labels des Pods (sinon pas d’endpoints)
3. ClusterIP (défaut) : communication interne uniquement
4. NodePort : exposition sur un port de chaque nœud (30000-32767)
5. LoadBalancer : demande un équilibreur externe au cloud provider
6. Headless (clusterIP: None) : DNS retourne directement les IPs des Pods
7. EndpointSlices : API moderne qui stocke les adresses des Pods
8. Un Service ne fait pas de routage HTTP, TLS ou filtrage sécurité — utilisez Ingress et NetworkPolicies

Prochaines étapes

Ingress Exposez vos Services HTTP/HTTPS avec du routage par path et host

NetworkPolicies Sécurisez la communication entre vos Pods et Services

Deployments Créez des applications résilientes qui utilisent des Services

×

📖 Voir la documentation →