Lab 04 : Réseau, Services & Découverte DNS¶

Objectifs Pédagogiques :¶

Comprendre pourquoi les adresses IP des Pods sont volatiles et éphémères.
Créer un Service de type ClusterIP pour l'API backend et tester la résolution DNS interne (CoreDNS).
Inspecter l'anatomie des Endpoints et EndpointSlices et pratiquer la mise en quarantaine d'un Pod.
Exposer le frontend vers l'extérieur avec un Service NodePort et comprendre la dissociation des 3 ports.
Tester l'équilibrage de charge (Round-Robin) sur plusieurs réplicas.
Utiliser kubectl port-forward pour des tests de connectivité locaux sécurisés.

📌 Note Compatibilité OS :
Les commandes de cet atelier (kubectl expose, kubectl get svc, kubectl port-forward) sont rigoureusement identiques sous Windows (PowerShell), Linux (Ubuntu) et macOS (Terminal).

💡 Modalités d'exécution (Au choix) :
* Option A (Recommandée - Confort DevOps Local) : Exécutez les commandes directement depuis votre machine locale avec votre kubectl et votre kubeconfig.
* Option B (Secours - PC d'entreprise verrouillé) : Connectez-vous en SSH sur k8s-control : l'outillage et les manifests sont pré-installés dans ~/labs/.

Contexte Métier¶

Dans une architecture Kubernetes, les pods naissent, meurent et changent d'adresse IP à chaque mise à jour, incident ou redémarrage. Si le frontend essayait de contacter le backend avec une adresse IP directe de pod, la communication casserait dès la première mise à jour. Nous devons mettre en place un Service pour fournir une adresse IP virtuelle stable, un nom DNS interne pérenne et de l'équilibrage de charge automatique (Load Balancing).

Exercice 1 : Service ClusterIP & Découverte DNS CoreDNS¶

1. Identifier les pods cibles et leurs labels¶

Vérifiez que vos pods backend créés au Lab 03 sont actifs et notez leur label app=campus-backend :

kubectl get pods -l app=campus-backend --show-labels

2. Générer et appliquer le manifest du Service ClusterIP¶

Générez un manifest propre de Service pour le backend à l'aide de kubectl expose en mode --dry-run=client -o yaml : * Nom du service : campus-backend-svc * Port exposé par le service : 8080 * Port cible du conteneur (targetPort) : 8080 * Type : ClusterIP (valeur par défaut)

kubectl expose deployment campus-backend --name=campus-backend-svc --port=8080 --target-port=8080 --type=ClusterIP --dry-run=client -o yaml > service-backend.yaml
kubectl apply -f service-backend.yaml

Inspectez le service créé et notez son adresse IP virtuelle (CLUSTER-IP) :

kubectl get svc campus-backend-svc

3. Valider la résolution DNS avec un conteneur éphémère¶

Kubernetes intègre un serveur DNS interne (CoreDNS). Tout service nommé <svc> dans le namespace <ns> est joignable sous son nom court http://<svc>:<port> ou son FQDN complet http://<svc>.<ns>.svc.cluster.local:<port>.

Démarrez un pod temporaire de diagnostic équipé de curl :

kubectl run test-dns --image=curlimages/curl --rm -it --restart=Never -- sh

Depuis le terminal de ce conteneur éphémère, exécutez les vérifications suivantes :

# 1. Résolution DNS du nom court
nslookup campus-backend-svc

# 2. Requête HTTP vers le endpoint de santé Spring Boot
curl -i http://campus-backend-svc:8080/actuator/health

# 3. Requête avec le FQDN complet (Fully Qualified Domain Name)
curl -i http://campus-backend-svc.default.svc.cluster.local:8080/actuator/health

# 4. Inspection de la configuration DNS injectée par le Kubelet
cat /etc/resolv.conf

💡 Observation clé : Observez la directive search default.svc.cluster.local svc.cluster.local cluster.local dans /etc/resolv.conf. C'est elle qui permet de résoudre campus-backend-svc sans saisir le suffixe complet !

Tapez exit pour quitter et détruire le conteneur de test.

Exercice 2 : Anatomie des Endpoints, EndpointSlices & Quarantaine¶

1. Inspecter les Endpoints et EndpointSlices¶

Le Service n'est qu'une règle de routage virtuelle gérée par kube-proxy (via iptables ou IPVS). La liste réelle des adresses IP des pods sains est maintenue dans un objet séparé : Endpoints (et EndpointSlices en Kubernetes moderne) :

kubectl get endpoints campus-backend-svc
kubectl get endpointslices -l kubernetes.io/service-name=campus-backend-svc

Constatez que les adresses IP listées dans les Endpoints correspondent exactement aux IP des pods backend (kubectl get pods -l app=campus-backend -o wide).

2. Mettre un Pod en Quarantaine en Production (Cas d'Usage Réel)¶

En production, lorsqu'un pod produit des erreurs intermittentes, détruire le pod efface les preuves. La technique DevOps recommandée consiste à modifier le label du pod pour le sortir instantanément des Endpoints du Service sans l'arrêter :

Choisissez le nom d'un de vos pods backend :

POD_TARGET=$(kubectl get pods -l app=campus-backend -o jsonpath='{.items[0].metadata.name}')
echo "Pod ciblé : $POD_TARGET"

Changez son label app pour l'isoler :

kubectl label pod $POD_TARGET app=campus-backend-debug --overwrite

Observez immédiatement les Endpoints du service :
```
kubectl get endpoints campus-backend-svc
```
L'adresse IP du pod ciblé a instantanément disparu de la liste des Endpoints ! Aucun utilisateur ne sera plus dirigé vers lui.
Constatez également que le ReplicaSet du Deployment a immédiatement créé un nouveau pod de remplacement pour respecter replicas: 2 !
Remettez de l'ordre en supprimant le pod en quarantaine :
```
kubectl delete pod $POD_TARGET
```

Exercice 3 : Exposition Externe via NodePort & Détection de Pièges¶

1. Déployer le composant Frontend¶

Déployez le frontend de l'application (2 réplicas) :

kubectl create deployment campus-frontend --image=regaieg/campus:frontend-1.0.0 --replicas=2 --port=8080 --dry-run=client -o yaml > deployment-frontend.yaml
kubectl apply -f deployment-frontend.yaml

2. Créer le Service NodePort¶

Créez un fichier service-frontend.yaml :

apiVersion: v1
kind: Service
metadata:
  name: campus-frontend-svc
spec:
  type: NodePort
  selector:
    app: campus-frontend
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30088

💡 Note d'attribution de port : Nous allouons le port statique 30088 car 30080 est réservé par le contrôleur Ingress NGINX sur le cluster.

Appliquez le Service :

kubectl apply -f service-frontend.yaml
kubectl get svc campus-frontend-svc

3. Comprendre la dissociation des 3 ports réseau¶

Paramètre	Valeur dans notre lab	Rôle en architecture Kubernetes
`port`	`80`	Port virtuel interne exposé par le Service au sein du cluster (utilisé par d'autres pods).
`targetPort`	`8080`	Port sur lequel le conteneur applicatif écoute réellement à l'intérieur du Pod.
`nodePort`	`30088`	Port statique ouvert sur chaque nœud (Node Worker) du cluster dans la plage 30000-32767.

4. Accéder à l'application via le NodePort sur AWS¶

Sur votre cluster AWS multi-nœuds : 1. Récupérez l'adresse IP publique de votre nœud worker k8s-worker-1 (notée lors du Lab 00 dans votre session MobaXterm ou console AWS). 2. Ouvrez votre navigateur web à l'adresse : http://<IP_PUBLIQUE_WORKER>:30088. 3. Vous accédez directement au portail web d'accueil servi par le frontend !

Exercice 4 : Équilibrage de Charge Round-Robin & Scalabilité¶

1. Tester la répartition du trafic¶

Testons comment Kubernetes distribue les requêtes entrantes entre les différents réplicas du backend :

Montez le nombre de réplicas du backend à 3 :

kubectl scale deployment campus-backend --replicas=3
kubectl wait --for=condition=ready pod -l app=campus-backend --timeout=60s

Lancez une boucle de 6 requêtes depuis un conteneur de test pour observer les réponses :

kubectl run test-lb --image=curlimages/curl --rm -it --restart=Never -- sh -c "for i in \$(seq 1 6); do curl -s http://campus-backend-svc:8080/actuator/health ; echo ; done"

Affichez les logs combinés des 3 pods pour constater que chaque pod a traité une partie des requêtes entrantes :
```
kubectl logs -l app=campus-backend --tail=10 --prefix=true
```
L'indicateur --prefix=true permet de distinguer quel pod a reçu chaque ligne de log !

Exercice 5 : Port-Forwarding et Débogage Local Sécurisé¶

En environnement d'entreprise, ouvrir un NodePort ou un LoadBalancer public n'est pas toujours autorisé pour des raisons de conformité de sécurité. La commande kubectl port-forward permet d'établir un tunnel chiffré direct via l'API Server pour accéder à un service interne.

Lancez un tunnel de port-forwarding vers le service frontend :
```
kubectl port-forward svc/campus-frontend-svc 8081:80
```
Ouvrez un second terminal (ou votre navigateur) à l'adresse : http://localhost:8081
Vous devez voir s'afficher l'interface d'accueil du Campus Summer Portal !
Pour interrompre le tunnel, appuyez sur Ctrl + C dans le terminal où tourne la commande.

Critères de Validation (Checklist)¶

campus-backend-svc est de type ClusterIP et résolu par CoreDNS (nslookup campus-backend-svc).
Vous avez inspecté les endpoints et compris la mise en quarantaine d'un pod par son label.
campus-frontend-svc est exposé en NodePort sur le port 30088.
Vous distinguez clairement port (80), targetPort (8080) et nodePort (30088).
Le trafic est distribué en Round-Robin entre les réplicas.
Vous savez utiliser kubectl port-forward pour inspecter un service en toute sécurité.