Kubernetes 027 – TP Dockercoin : ConfigMaps et Services

TL;DR

Dans une application multi-composants, les noms de Services et les parametres doivent etre externalises. Les ConfigMaps permettent d’eviter de reconstruire les images pour changer une URL, un mode ou un niveau de log.

La video de reference

Video: https://www.youtube.com/watch?v=sM_Rz_fiO84

Elle applique ConfigMap et Services au fil rouge Dockercoin.

Pourquoi ajouter des ConfigMaps ?

Dockercoin contient plusieurs composants qui doivent se connaitre. Dans Kubernetes, l’adresse stable d’un composant est souvent le nom de son Service.

Plutot que coder ces noms dans l’image, on les injecte via configuration.

Exemple ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: dockercoin-config
data:
  REDIS_HOST: redis
  HASHER_HOST: hasher
  LOG_LEVEL: info

Injection dans un Deployment

containers:
  - name: worker
    image: <image-worker>
    envFrom:
      - configMapRef:
          name: dockercoin-config

Le composant lit ensuite ses variables comme dans un environnement classique.

Services internes

Chaque composant joint par d’autres doit avoir un Service stable:

kubectl get svc
kubectl get endpoints
kubectl run curl --image=curlimages/curl -it --rm --restart=Never -- curl http://hasher

Les noms de Services doivent correspondre a ce que les variables de configuration indiquent.

Ordre de debug

• verifier les pods;
• verifier les Services;
• verifier les endpoints;
• verifier les variables d’environnement;
• lire les logs applicatifs.

kubectl exec deploy/worker -- env
kubectl logs deploy/worker
kubectl describe svc hasher

Liens utiles

• Video: https://www.youtube.com/watch?v=sM_Rz_fiO84
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• ConfigMaps: https://kubernetes.io/docs/concepts/configuration/configmap/
• Services: https://kubernetes.io/docs/concepts/services-networking/service/

FAQ

Pourquoi ne pas mettre les URLs directement dans le code ?

Parce que l’environnement change. La configuration doit pouvoir varier sans rebuild.

Une ConfigMap peut-elle contenir un fichier complet ?

Oui. Chaque cle peut contenir le contenu d’un fichier.

Quand utiliser un Secret ?

Pour les mots de passe, tokens et donnees sensibles.

Erreurs frequentes

• Modifier la ConfigMap sans redemarrer les pods qui lisent les variables au demarrage.
• Utiliser un nom de Service different du nom attendu par l’application.
• Ne pas verifier les endpoints.
• Mettre des secrets dans une ConfigMap.

Pour pratiquer

Changez une variable de ConfigMap, appliquez le fichier, puis redemarrez le Deployment concerne:

kubectl apply -f configmap.yaml
kubectl rollout restart deployment/worker
kubectl logs deploy/worker

Notions et definitions

• Service: point d’entree stable devant un ensemble de pods.
• Endpoint ou EndpointSlice: liste des backends reels selectionnes par le Service.
• kube-proxy: composant qui programme les regles reseau necessaires sur chaque noeud.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un Deployment web expose par un Service web-svc permet a un client de viser une IP stable, meme si les pods web sont recrees avec de nouvelles adresses IP.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Creer un Deployment avec un label clair, par exemple app=web.
• Creer un Service dont le selecteur cible ce label.
• Verifier que les endpoints apparaissent et correspondent aux pods attendus.
• Tester depuis un pod de debug plutot que depuis uniquement votre machine locale.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le chemin reseau complet entre un client, un Service, kube-proxy et les pods cibles. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get svc,endpoints,endpointslices -o wide
• kubectl describe svc <service> pour verifier le selecteur, les ports et les endpoints
• kubectl logs -n kube-system -l k8s-app=kube-proxy pour confirmer le mode et les erreurs reseau

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• confondre Service, Pod IP et endpoint reel
• oublier qu’un Service sans endpoint ne peut pas router de trafic applicatif
• diagnostiquer le CNI alors que le probleme vient du selecteur ou du port du Service

Exercice conseille

Creez deux Deployments nginx avec des labels differents, exposez-en un avec un Service, puis modifiez volontairement le selecteur pour observer la disparition des endpoints.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 028 – Volumes : principes et emptyDir.

Conclusion

Ce TP montre que Kubernetes n’est pas seulement une collection de pods. Une application fonctionne quand execution, reseau et configuration sont alignes.