Introduction aux Services : Abstraction réseau stable

La solution : une façade stable pour des Pods dynamiques

Face au problème des adresses IP éphémères des Pods, Kubernetes propose une solution élégante et puissante : l'objet Service. Un Service est une abstraction qui définit une politique d'accès logique à un ensemble de Pods exécutant la même application ou fonction. Il agit comme un point d'entrée réseau stable et unique pour ces Pods, masquant leur nature changeante et individuelle.

Au lieu que les clients essaient de suivre les adresses IP volatiles des Pods, ils se connectent simplement au Service. Le Service, quant à lui, se charge de diriger le trafic vers l'un des Pods cibles appropriés et disponibles. Pensez à un Service comme à un standard téléphonique intelligent pour un groupe d'employés (les Pods) : vous appelez le numéro principal (l'adresse du Service), et le standard vous met en relation avec un employé disponible, sans que vous ayez besoin de connaître le numéro de poste direct ou l'état de chaque employé.

Cette abstraction est au coeur de la manière dont les applications communiquent entre elles et sont exposées dans Kubernetes. Elle découple les consommateurs de services des fournisseurs (les Pods), permettant aux Pods d'être créés, détruits, mis à jour ou déplacés sans affecter la manière dont les clients y accèdent.

Comment fonctionnent les Services : Selectors et Endpoints

Le fonctionnement des Services repose sur les Labels et Selectors que nous avons déjà étudiés :

1. Définition du Service avec un Selector : Lorsque vous créez un Service, vous définissez dans sa spécification (`spec.selector`) un ensemble de labels. Ce sélecteur détermine quels Pods sont considérés comme faisant partie de ce Service.
2. Surveillance des Pods par Kubernetes : Le Control Plane de Kubernetes (plus précisément, le contrôleur d'Endpoints ou EndpointSlices) surveille en permanence les Pods dans le cluster.
3. Création/Mise à jour des Endpoints/EndpointSlices : Pour chaque Service, le contrôleur identifie tous les Pods en cours d'exécution et prêts (`Ready`) qui correspondent au `selector` du Service. Il collecte leurs adresses IP et ports et les stocke dans un objet associé appelé Endpoints (ou le plus récent et plus scalable EndpointSlice). Cet objet est une liste dynamique des backends valides pour le Service.
4. Attribution d'une IP/DNS stable : Le Service lui-même se voit attribuer une adresse IP virtuelle stable (appelée ClusterIP, par défaut, accessible uniquement depuis l'intérieur du cluster) et/ou un nom DNS interne stable.
5. Routage du trafic : Lorsqu'un client envoie une requête à l'IP ou au nom DNS du Service, des mécanismes internes à Kubernetes (principalement gérés par kube-proxy sur chaque noeud) interceptent ce trafic. En consultant les informations des Endpoints/EndpointSlices associés au Service, kube-proxy redirige la requête vers l'une des adresses IP d'un Pod backend valide et prêt, effectuant ainsi un équilibrage de charge (load balancing) simple (souvent de type round-robin ou aléatoire par défaut).

Ce processus est entièrement dynamique. Si des Pods sont ajoutés ou supprimés, ou s'ils deviennent prêts ou non prêts, l'objet Endpoints/EndpointSlices est mis à jour automatiquement, et le routage via le Service s'adapte sans que le client n'ait besoin de changer quoi que ce soit.

Bénéfices clés de l'abstraction Service

L'utilisation des Services apporte des avantages fondamentaux :

• Point d'accès stable : Fournit une adresse IP et/ou un nom DNS qui ne changent pas, même si les Pods derrière sont recréés ou déplacés.
• Découverte de services : Les applications peuvent trouver d'autres services via leur nom DNS stable fourni par le DNS interne du cluster (CoreDNS), plutôt que de dépendre d'adresses IP.
• Equilibrage de charge : Distribue automatiquement le trafic entrant entre les multiples instances (Pods) saines d'une application, améliorant la performance et la disponibilité.
• Découplage : Sépare la logique réseau de la logique applicative et du cycle de vie des Pods. Les développeurs d'applications clientes n'ont pas besoin de se soucier de la localisation ou du nombre d'instances du service qu'ils consomment.
• Flexibilité d'exposition : Différents types de Services permettent d'exposer les applications uniquement à l'intérieur du cluster, ou à l'extérieur via les noeuds ou des équilibreurs de charge cloud.

Structure de base d'un manifeste de Service

Voici un exemple simple de manifeste YAML pour un Service de type ClusterIP :

apiVersion: v1
kind: Service
metadata:
  name: mon-app-service # Nom du Service
spec:
  selector:           # Sélectionne les Pods avec ce(s) label(s)
    app: mon-app
  ports:
  - protocol: TCP
    port: 80            # Port sur lequel le Service écoute
    targetPort: 8080      # Port sur lequel les Pods cibles écoutent
  type: ClusterIP     # Type de Service (par défaut)

Ici, ce Service nommé `mon-app-service` écoutera sur le port 80 (au sein du réseau du cluster, sur son ClusterIP). Il sélectionnera tous les Pods ayant le label `app=mon-app`. Le trafic reçu sur le port 80 du Service sera redirigé vers le port `8080` de l'un des Pods correspondants.

Maintenant que nous avons compris le concept général et les bénéfices des Services, nous allons explorer plus en détail les différents types de Services disponibles et leurs cas d'usage spécifiques dans la section suivante.