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:...