Kubernetes 020 – Services : ClusterIP, principes, schema et demo

TL;DR

Un Service ClusterIP est accessible uniquement dans le cluster. Il possede une IP virtuelle, un nom DNS et une liste de endpoints correspondant aux pods selectionnes. C’est le mode normal pour faire communiquer des applications entre elles.

La video de reference

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

Elle detaille le cas le plus courant des Services Kubernetes.

Le chemin logique

Un client appelle http://web. Le DNS Kubernetes resout le nom vers la ClusterIP du Service. Le trafic est ensuite dirige vers un des endpoints, donc vers un pod selectionne.

Ce mecanisme permet de remplacer les pods sans changer l’adresse utilisee par les clients.

Manifest ClusterIP

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - name: http
      port: 80
      targetPort: 80

Le type peut etre omis car ClusterIP est la valeur par defaut.

Demo rapide

kubectl create deployment web --image=nginx
kubectl expose deployment web --port=80 --target-port=80
kubectl get svc web
kubectl get endpoints web
kubectl run curl --image=curlimages/curl -it --rm --restart=Never -- curl http://web

Endpoints

Les endpoints representent les IP et ports reels des pods cibles. Si un pod disparait, la liste evolue. Si aucun pod ne correspond au selector, elle est vide.

kubectl describe service web
kubectl get endpoints web -o yaml

ClusterIP et DNS

Le nom court fonctionne dans le meme namespace. Le nom complet suit la forme:

web.default.svc.cluster.local

Cette resolution est fournie par le DNS du cluster, generalement CoreDNS.

Liens utiles

• Video: https://www.youtube.com/watch?v=ZGIfWYnodJQ
• Services: https://kubernetes.io/docs/concepts/services-networking/service/
• DNS: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
• EndpointSlices: https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/

FAQ

ClusterIP est-il stable ?

Oui pendant la vie du Service. Si le Service est supprime et recree, l’IP peut changer.

Peut-on choisir la ClusterIP ?

Oui avec clusterIP, mais ce n’est pas necessaire dans la plupart des cas.

Pourquoi tester depuis un pod ?

Parce que ClusterIP est interne au cluster. Un test depuis le poste local ne represente pas le meme chemin reseau.

Erreurs frequentes

• Tester une ClusterIP depuis l’exterieur du cluster.
• Oublier que les endpoints dependent des labels et de l’etat des pods.
• Melanger port et targetPort.
• Supprimer et recreer un Service en pensant garder la meme IP.

Pour pratiquer

Scalez le Deployment et observez les endpoints:

kubectl scale deployment web --replicas=3
kubectl get endpoints web -w
kubectl delete pod -l app=web

Les endpoints changent, mais le Service reste stable.

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 021 – Services : NodePort, LoadBalancer, ExternalName et Endpoints.

Conclusion

ClusterIP est la base du reseau applicatif interne. Il faut le maitriser avant NodePort, LoadBalancer, Ingress ou les sujets avances de proxy.