Aller au contenu
TortueTech
RubriquesGlossaire

Service : Service (objet Kubernetes)

Infrastructure

Objet Kubernetes qui regroupe des Pods choisis par leurs labels derrière une adresse IP virtuelle stable et un nom DNS interne, puis répartit le trafic entre eux. Les Pods meurent et changent d'adresse ; le Service, lui, reste joignable au même endroit.

Schéma de séquence entre six acteurs : Pod client, DNS du cluster, ClusterIP, kube-proxy, Règles du nœud et Pod sélectionné. 1, le Pod client demande au DNS du cluster l'adresse du nom du Service ; 2, le DNS lui renvoie la ClusterIP stable ; 3, le Pod client envoie la connexion à la ClusterIP ; 4, les règles du nœud la redirigent vers un Pod prêt qui porte le bon label ; 5, si un Pod est recréé avec une nouvelle IP, kube-proxy met à jour la liste des destinations dans les règles du nœud.

Une adresse qui ne bouge pas : Le Service déclare un sélecteur de labels. Kubernetes tient à jour la liste des Pods prêts qui le portent, et cette liste suit chaque recréation. Les clients visent la ClusterIP ou le nom DNS, de la forme mon-service.mon-namespace.svc.cluster.local, sans jamais connaître l'adresse d'un Pod.

Trois façons d'exposer : ClusterIP, le type par défaut, n'est joignable que depuis l'intérieur du cluster. NodePort ouvre en plus le même port sur chaque nœud. LoadBalancer demande au fournisseur cloud un répartiteur externe qui renvoie vers ces ports.

Des règles réseau, pas de la magie : Sur chaque nœud, kube-proxy (en mode iptables, IPVS ou nftables) ou un équivalent comme Cilium programme la traduction de la ClusterIP vers l'un des Pods. Cette adresse n'est portée par aucune interface : aucune machine ne la possède, toutes savent la joindre, ce qui en fait l'élément le plus fiable de bien des architectures.

À ne pas confondre : Le Pod exécute les conteneurs, le Deployment crée et remplace les Pods, le Service donne l'adresse d'entrée. L'Ingress route le HTTP au niveau 7, selon l'hôte ou le chemin. Le Service, lui, répartit des connexions TCP ou UDP sans lire les requêtes.

Voir aussi :KubernetesPodDeployment

Ce qui arrive si on s'en passe

Sans Service, chaque client doit viser directement l'adresse IP d'un Pod. Or cette adresse change dès que le Pod est recréé, redémarré ou replanifié sur un autre nœud. Les connexions échouent alors jusqu'à ce que quelqu'un corrige la configuration à la main, et aucune reprise automatique n'a lieu. Une adresse libérée peut aussi être réattribuée à un autre Pod, éventuellement d'une autre application ; le trafic, avec les jetons ou les données qu'il transporte, arrive alors chez un destinataire imprévu. Il n'y a plus non plus de répartition de charge : le Pod ciblé reçoit tout, ses réplicas restent inutilisés, et sa disparition coupe l'accès. Enfin, les journaux ne contiennent que des adresses éphémères. Sans nom DNS stable pour les rattacher à une application, il devient plus difficile de recouper les événements lors d'une analyse.

Explication de la marmotte

Imagine une pizzeria très demandée. Les cuisiniers changent sans arrêt : certains partent, d'autres arrivent, et chacun a son propre téléphone. Si les clients devaient connaître le numéro de chaque cuisinier, ce serait l'enfer. La pizzeria affiche donc un seul numéro, toujours le même. Derrière, un standard reçoit chaque appel et le passe à un cuisinier disponible, en répartissant le travail pour que personne ne soit débordé. Quand un cuisinier s'en va, le standard le retire de sa liste. Quand un nouveau arrive, il l'ajoute. Ce numéro fixe et son standard, c'est le service : le client n'a jamais besoin de savoir qui cuisine ce soir.

Où ce terme est utilisé

← Tout le glossaire