Services et Endpoints

Nous sommes passés rapidement sur le besoin d’avoir plusieurs pods pour maintenir le service, mais c’est précisément cette redondance qui permet de maintenir cette haute disponibilité.

Il faut donc un mécanisme pour répartir les flux des requêtes vers les pods. C’est le rôle des objets Service. Cette abstraction est utilisée pour fournir les informations nécessaires au cluster afin de faire les configurations réseau permettant la communication dans le cluster et avec l’extérieur. Service Kubernetes:Service

Comme nous l’avons évoqué dans les chapitres précédents, les labels sont utilisés pour permettre la sélection des objets dans Kubernetes. Le mécanisme des labels est omniprésent dans un cluster. Les labels sont également utilisés pour associer (mapping) les pods à un service via l’utilisation d’un sélecteur.

1. Service de type ClusterIP ClusterIP Kubernetes:ClusterIP

Un service est donc une abstraction de Kubernetes pour permettre la résolution réseau et l’exposition des pods. Le DNS d’un service est de la forme :

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

Un Service permet également d’exposer l’application sur un port différent du port exposé par le pod, si nécessaire.

apiVersion: v1 
kind: Service 
metadata: 
  labels: 
    app:...
Pour consulter la suite, découvrez le livre suivant :
couv_EPHADIS.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Du pod aux déploiements
Suivant
Secret et ConfigMap