Accéder à l'application via le Service

L'étape finale : interagir avec votre application déployée

Après avoir écrit votre manifeste, l'avoir appliqué avec `kubectl apply`, et vérifié que vos Pods et votre Deployment sont dans un état sain (`Running` et `READY`), l'étape logique suivante est d'interagir réellement avec l'application. Que ce soit pour tester une API, afficher une page web ou utiliser une fonctionnalité, vous devez pouvoir atteindre les Pods qui exécutent votre code. Cependant, les adresses IP des Pods sont éphémères et peuvent changer; y accéder directement n'est pas une solution fiable ou pratique.

C'est là que l'objet Kubernetes `Service` entre en jeu. Comme nous l'avons brièvement introduit, un Service fournit une abstraction stable pour accéder à un ensemble logique de Pods (généralement sélectionnés par des labels). Il offre une adresse IP interne stable (ClusterIP), un nom DNS au sein du cluster, et peut équilibrer la charge entre les Pods correspondants. Pour accéder à l'application depuis l'extérieur du cluster ou même depuis votre machine locale lors du développement, des types de Services spécifiques ou des outils comme `kubectl port-forward` sont nécessaires.

Ce sous-chapitre explore les méthodes courantes pour accéder à une application déployée, en se concentrant sur celles particulièrement pertinentes dans un environnement de développement local (comme Minikube ou Kind) où l'on utilise souvent les types de Service `NodePort` ou la commande `kubectl port-forward`.

Accès via le type de service `NodePort`

Le type de Service `NodePort` est une méthode simple pour exposer votre application sur un port statique sur l'adresse IP de chaque noeud (Node) de votre cluster. Lorsque vous créez un Service de type `NodePort`, Kubernetes alloue automatiquement un port dans une plage spécifique (par défaut 30000-32767) sur tous les noeuds. Tout trafic arrivant sur ce port sur n'importe quel noeud est ensuite acheminé vers le port approprié (`targetPort`) des Pods ciblés par le Service.

Pour utiliser cette méthode, vous devez d'abord connaître deux informations : l'adresse IP d'un des noeuds de votre cluster et le NodePort qui a été alloué à votre Service. Si vous utilisez un cluster local comme Minikube, vous pouvez obtenir l'IP du noeud avec la commande :

minikube ip

Ensuite, pour trouver le NodePort alloué, utilisez la commande `kubectl get svc` (comme vu précédemment) et repérez le mappage dans la colonne `PORT(S)`. Par exemple, pour notre `nginx-service` :

$ kubectl get svc nginx-service
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
nginx-service   NodePort   10.100.50.20           80:30080/TCP   15m

Le mappage `80:30080/TCP` nous indique que le NodePort est `30080`. En supposant que `minikube ip` retourne `192.168.49.2`, vous pouvez accéder à votre application Nginx via un navigateur ou `curl` à l'adresse : `http://192.168.49.2:30080`.

Cette méthode est pratique pour des tests rapides ou dans des environnements où vous contrôlez l'accès réseau aux noeuds, mais elle est moins courante pour exposer des applications en production sur internet (où des `LoadBalancer` ou des `Ingress` sont préférés).

Accès via le type de service `LoadBalancer`

Le type de Service `LoadBalancer` est la méthode standard pour exposer une application sur internet lorsqu'on utilise un fournisseur de cloud géré (comme AWS, GCP, Azure). Lorsque vous créez un Service de ce type, le cloud provider provisionne automatiquement un équilibreur de charge externe (un ELB, un Google Cloud Load Balancer, etc.) avec une adresse IP publique et configure les règles pour acheminer le trafic vers les NodePorts appropriés de votre cluster.

Dans un environnement local comme Minikube, le comportement peut varier. Parfois, `minikube` peut simuler un LoadBalancer en utilisant l'IP du noeud, ou il peut nécessiter une commande supplémentaire comme `minikube tunnel` pour s'exécuter dans un terminal séparé afin d'allouer une adresse IP externe simulée.

Pour vérifier si une IP externe a été attribuée, utilisez `kubectl get svc` :

$ kubectl get svc mon-service-lb
NAME             TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)        AGE
mon-service-lb   LoadBalancer   10.101.30.45   198.51.100.1   80:31000/TCP   5m

Si une `EXTERNAL-IP` est affichée (ici `198.51.100.1`), vous pouvez accéder à votre application directement via cette IP sur le port spécifié (ici, le port 80). Si elle reste en état ``, c'est qu'aucun équilibreur de charge n'a pu être provisionné (typique en local sans `minikube tunnel` ou équivalent).

L'outil pratique pour le développement : `kubectl port-forward`

Une méthode extrêmement utile, surtout pendant le développement et le débogage, est la commande `kubectl port-forward`. Elle permet de créer un tunnel sécurisé directement depuis votre machine locale vers un Pod spécifique ou vers un Service à l'intérieur du cluster, sans avoir besoin d'exposer un NodePort ou un LoadBalancer.

Pour transférer le port local `8080` vers le port `80` de notre `nginx-service`, la commande serait :

kubectl port-forward svc/nginx-service 8080:80

Après avoir lancé cette commande, elle restera active dans votre terminal, indiquant qu'elle transfère les connexions :

Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80

Tant que cette commande s'exécute, vous pouvez accéder à votre application Nginx en vous connectant à `http://localhost:8080` ou `http://127.0.0.1:8080` depuis votre machine locale. `kubectl` se charge d'acheminer le trafic via l'API Server jusqu'au Service, qui le distribue ensuite aux Pods sous-jacents.

Vous pouvez également faire un port-forward directement vers un Pod spécifique si nécessaire (par exemple, pour déboguer une instance particulière). Obtenez d'abord le nom exact du Pod avec `kubectl get pods`, puis exécutez :

kubectl port-forward pod/nginx-deployment-6799fc88d8-abcde 9090:80

Cela transférerait le port local `9090` directement vers le port `80` du conteneur dans le Pod `nginx-deployment-6799fc88d8-abcde`. C'est très utile pour isoler et tester un Pod spécifique.

`kubectl port-forward` est idéal pour un accès rapide et temporaire pendant le développement, mais n'est pas destiné à exposer des services de manière permanente ou en production. Il faut laisser le terminal ouvert, et la connexion s'arrête dès que vous interrompez la commande (Ctrl+C).

Choisir la bonne méthode

Le choix de la méthode d'accès dépend fortement de votre cas d'usage :

• Pour un accès rapide et temporaire depuis votre machine locale pendant le développement ou le débogage : `kubectl port-forward` est souvent le plus simple et le plus direct.
• Pour un accès depuis l'extérieur du cluster dans un environnement de test local (Minikube, Kind) ou un cluster sur site où vous gérez les IP des noeuds : `NodePort` est une option viable.
• Pour exposer une application de manière fiable et évolutive sur internet via un fournisseur cloud : `LoadBalancer` est la solution standard.
• Pour une communication interne au cluster (par exemple, un microservice backend appelé par un frontend) : le type par défaut `ClusterIP` est suffisant et n'expose rien à l'extérieur.

Une fois que vous parvenez à accéder à votre application (par exemple, en voyant la page d'accueil Nginx dans votre navigateur via `http://:` ou `http://localhost:8080` après un port-forward), vous avez validé avec succès l'ensemble de la chaîne de déploiement : du manifeste YAML à l'application fonctionnelle et accessible.