Kubernetes 024 – TP Dockercoin : deploiements et services

TL;DR

Pour deployer Dockercoin, on cree un Deployment par composant applicatif et un Service pour chaque composant devant etre joint par les autres. Les labels et selectors deviennent la colle de l’application.

La video de reference

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

Elle continue le lab Dockercoin commence dans l’episode precedent.

Structure cible

Une application multi-composants demande de separer les responsabilites:

• un Deployment pour executer chaque composant;
• un Service ClusterIP pour les communications internes;
• eventuellement un Service d’exposition pour l’interface utilisateur;
• des labels coherents pour relier les objets.

Exemple Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hasher
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hasher
  template:
    metadata:
      labels:
        app: hasher
    spec:
      containers:
        - name: hasher
          image: <image-hasher>
          ports:
            - containerPort: 80

Exemple Service

apiVersion: v1
kind: Service
metadata:
  name: hasher
spec:
  selector:
    app: hasher
  ports:
    - port: 80
      targetPort: 80

Le nom du Service devient le nom DNS utilise par les autres composants.

Deployer progressivement

kubectl apply -f hasher-deployment.yaml
kubectl apply -f hasher-service.yaml
kubectl get deploy,svc,pods
kubectl logs deploy/hasher

Ensuite seulement, on ajoute les autres composants.

Debug du lab

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

Un Service sans endpoint indique presque toujours un probleme de labels ou de readiness.

Liens utiles

• Video: https://www.youtube.com/watch?v=IhocwBYtYQw
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Services: https://kubernetes.io/docs/concepts/services-networking/service/
• Labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

FAQ

Pourquoi un Service par composant ?

Parce que les pods changent d’IP. Le Service donne un nom stable.

Peut-on tout mettre dans un seul pod ?

Techniquement parfois, mais ce n’est pas le modele souhaite ici. Les composants doivent rester scalables et observables.

Comment savoir si les composants communiquent ?

Avec les logs, les endpoints et des pods temporaires de test.

Erreurs frequentes

• Nommer un Service differemment de ce que l’application attend.
• Oublier un port expose dans le Service.
• Avoir un selector qui ne matche aucun pod.
• Vouloir tout exposer en NodePort.

Pour pratiquer

Ajoutez un composant, testez son Service depuis un pod curl, puis passez au suivant. Ne continuez pas tant que les endpoints ne sont pas corrects.

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 025 – Labels et Annotations : pourquoi, comment, demo.

Conclusion

Ce TP montre la combinaison la plus importante au quotidien: Deployment pour executer, Service pour joindre, labels pour relier.