IT Toolbox AI
Kubernetes · Services

Services

Fournissez un endpoint stable à des Pods éphémères grâce aux sélecteurs et aux différents types de Service.

Leçon disponible
20 min

Objectifs

  • Comprendre pourquoi les Pods éphémères nécessitent un endpoint stable.
  • Relier selector, labels et backends du Service.
  • Distinguer ClusterIP, NodePort et LoadBalancer.
  • Expliquer port, targetPort et nodePort.

Exposer une application avec un Service

Un Service représente un ensemble dynamique de Pods derrière une adresse et un nom DNS stables. Il sélectionne généralement ses backends grâce aux labels des Pods.

Les EndpointSlices sont l’API moderne utilisée pour suivre les adresses des backends. La commande kubectl get endpoints reste courante pour un diagnostic simple, mais les EndpointSlices sont à privilégier pour comprendre l’implémentation actuelle.

ClusterIP, NodePort et LoadBalancer

ClusterIP, le type par défaut, expose le Service uniquement dans le réseau du cluster. NodePort ouvre un port sur les nœuds. LoadBalancer demande généralement à une intégration cloud ou à un contrôleur compatible de fournir un équilibrage externe.

  • ClusterIP : accès interne stable.
  • NodePort : accès via l’adresse d’un nœud et un port attribué ou choisi dans la plage autorisée.
  • LoadBalancer : exposition externe dépendante de l’environnement et de son contrôleur.

Manifeste ClusterIP

Le selector app: nginx doit correspondre aux labels des Pods. port est le port offert par le Service et targetPort le port d’écoute dans les Pods ciblés.

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

port, targetPort et nodePort

port est utilisé par les clients du Service. targetPort désigne le port numérique ou nommé du backend. nodePort s’applique au type NodePort et représente le port ouvert sur chaque nœud selon l’implémentation réseau.

Un Service ne vérifie pas que l’application écoute réellement sur targetPort. Une valeur incorrecte produit un endpoint existant mais un trafic sans réponse utile.

Observer Service et backends

Commencez par la définition du Service, puis vérifiez les endpoints générés. Une liste vide indique souvent que le selector ne correspond à aucun Pod prêt.

Lister et décrire les Services
kubectl get services
kubectl get svc
kubectl describe service nginx-service
Vérifier les backends découverts
kubectl get endpoints
kubectl get endpointslices

Bonnes pratiques

Utilisez des labels stables et spécifiques, des ports nommés lorsque cela clarifie la configuration et exposez seulement les Services qui doivent réellement sortir du cluster.

  • Comparer selector du Service et labels réels des Pods.
  • Vérifier la readiness avant d’accuser le réseau.
  • Documenter la dépendance au cloud ou au contrôleur pour LoadBalancer.

Mini résumé

  • Un Service fournit un endpoint stable devant des Pods remplaçables.
  • Les selectors associent le Service aux labels des Pods.
  • ClusterIP, NodePort et LoadBalancer répondent à des périmètres d’exposition différents.
  • port cible les clients, targetPort le backend et nodePort les nœuds.

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Un Service existe mais ne possède aucun endpoint. Quelle vérification est prioritaire ?
2. À quoi sert targetPort ?
3. Pourquoi un Service LoadBalancer peut-il rester Pending sur un cluster local ?