Introduction
Dans les labs précédents, vous avez appris que les Pods apparaissent et disparaissent. Si un Pod s’arrête et qu’un nouveau le remplace, ce nouveau Pod reçoit une adresse IP complètement différente. Imaginez que vous essayiez d’appeler un ami dont le numéro de téléphone changerait chaque fois qu’il raccroche !
Pour résoudre ce problème, Kubernetes utilise un Service.
Un Service fournit une identité réseau stable à une charge de travail, même si les Pods qui la prennent en charge peuvent changer. Cette séparation entre le cycle de vie des Pods et le point de terminaison du Service est une idée fondamentale de la mise en réseau Kubernetes.
Il s’agit de l’un des modèles mentaux les plus importants de la mise en réseau Kubernetes : les Pods sont conçus pour être remplaçables, mais les clients ont toujours besoin d’une adresse fiable. Un Service résout cette incompatibilité en se plaçant devant des Pods qui changent et en présentant un nom et une adresse IP virtuelle stables.
Dans ce lab, vous allez :
- Créer un Service pour fournir une adresse stable à votre application.
- Découvrir comment le Service sait vers quels Pods acheminer le trafic, grâce aux Selectors.
- Accéder à votre application depuis l’extérieur du cluster à l’aide d’un type de Service spécifique appelé NodePort.
Créer le fichier YAML du Service
Dans cette étape, vous allez créer un fichier de configuration pour un Service. Nous utiliserons un type particulier appelé NodePort.
Un Service NodePort ouvre un port précis sur chaque Node (serveur) du cluster. C’est comme si vous ouvriez une porte précise de votre maison pour laisser entrer le monde extérieur.
NodePort est facile à comprendre, car il correspond directement à un port sur chaque Node. Cependant, ce n’est généralement pas la solution finale en production pour exposer du trafic public. Dans les environnements plus importants, NodePort est souvent placé derrière un équilibreur de charge cloud ou une couche d’ingress. Ici, il est utile, car il rend le chemin réseau visible pour les débutants.
Créez un fichier nommé service.yaml dans le répertoire de votre projet :
nano service.yaml
Collez le contenu suivant. Remarquez la section selector : nous laissons volontairement app: unknown pour le moment afin de vous montrer son fonctionnement.
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
ports:
- port: 80 ## The port the Service exposes internally
targetPort: 80 ## The port the container is listening on
nodePort: 30008 ## The static door we are opening to the outside
selector:
app: unknown ## This needs to match your Pod's label
Enregistrez le fichier, puis quittez (Ctrl+X, Y, Enter).
Ce fichier définit un Service nommé my-service. Il écoute sur le port 30008 (le nodePort). Tout trafic arrivant sur ce port sera transféré vers les Pods portant le label app: unknown — or, ces Pods n’existent pas actuellement !
Corriger le Selector
Un Service utilise un Selector pour trouver les Pods vers lesquels il doit acheminer le trafic. Il fonctionne comme une adresse postale. Si l’adresse inscrite sur l’enveloppe (le Selector du Service) ne correspond pas à l’adresse de la maison (le label du Pod), le courrier n’arrive jamais à destination.
Les labels et les selectors sont utilisés partout dans Kubernetes, et pas uniquement avec les Services. Ils constituent l’un des mécanismes fondamentaux de regroupement de la plateforme. Au lieu d’utiliser des noms de Pods exacts inscrits en dur, les ressources Kubernetes trouvent généralement les objets associés en faisant correspondre leurs labels. Le système reste ainsi flexible lorsque les Pods sont recréés.
Lors de l’étape Setup, nous avons démarré automatiquement une application web pour vous. Trouvons son « label d’adresse ».
Exécutez cette commande pour afficher les labels de vos Pods en cours d’exécution :
kubectl get pods --show-labels
Vous devriez voir quelque chose comme : web-app-xxxxx ... app=web-app
Le label est app=web-app. Cependant, notre Service recherche app: unknown. Corrigeons cela.
Modifiez votre fichier service.yaml :
nano service.yaml
Modifiez la section selector pour qu’elle corresponde au label de votre Pod :
selector:
app: web-app
Enregistrez le fichier, puis quittez. Le Service sait maintenant exactement où envoyer le trafic.
Appliquer la configuration et vérifier
Maintenant que l’adresse est correcte, activons le Service.
Lorsque vous appliquez ce manifeste, Kubernetes crée un objet Service et configure les règles réseau internes afin que les requêtes arrivant au Service puissent être transférées vers les points de terminaison des Pods correspondants. L’idée importante à retenir est que le Service n’exécute pas lui-même votre application. Il s’agit d’une abstraction réseau placée devant les Pods de l’application.
Appliquez la configuration au cluster :
kubectl apply -f service.yaml
Vous devriez voir : service/my-service created.
Pour confirmer que le Service est actif et fonctionne, affichez la liste des Services :
kubectl get svc my-service
Vous verrez :
- NAME: my-service
- TYPE: NodePort
- PORT(S): 80:30008/TCP
Cela confirme que votre « numéro de téléphone » est actif et attend des appels sur le port 30008.
Accéder à l’application
Passons maintenant au moment de vérité. Pouvons-nous accéder à l’application depuis « l’extérieur », c’est-à-dire depuis votre terminal ?
L’application est exposée sur le port 30008 du Node Kubernetes.
Trois ports interviennent ici, et les débutants les confondent souvent. Le nodePort est le port ouvert vers l’extérieur sur le Node, le port est le port exposé par l’abstraction Service et le targetPort est le port à l’intérieur du conteneur qui sert réellement l’application. Distinguer clairement ces rôles vous évitera des confusions par la suite.
Commencez par récupérer l’adresse IP du Node Minikube :
minikube ip
Supposons qu’il s’agisse de 192.168.49.2. L’adresse complète de votre application est http://192.168.49.2:30008.
Nous pouvons utiliser curl pour accéder à cette adresse et vérifier que l’application répond :
curl http://$(minikube ip):30008
Vous devriez voir le code HTML de la page « Welcome to nginx! ».
Cela confirme le parcours complet de la requête :
- Vous avez appelé le port externe du Node (
30008). - Le Service a reçu l’appel.
- Il a vérifié son Selector (
app: web-app). - Il a transféré l’appel vers l’un des Pods correspondant à ce label.
- Le Pod a répondu avec la page web.
Résumé
Dans ce lab, vous avez résolu le problème des adresses IP de Pods qui disparaissent grâce à un Service.
Vous avez réussi à :
- Créer un Service NodePort (
service.yaml) pour ouvrir une passerelle vers votre application. - Configurer un Selector afin d’indiquer au Service quels Pods gérer.
- Accéder à votre application en cours d’exécution depuis l’extérieur grâce à son adresse stable.
Les Services sont le lien qui permet aux applications Kubernetes de fonctionner ensemble. Ils permettent aux différentes parties de votre système de communiquer de manière fiable.
