Kubernetes 018 – What is a Service ? Objectifs, ClusterIP et expose

TL;DR

Un Service Kubernetes selectionne des pods avec des labels et leur donne un point d’acces stable. Le type par defaut est ClusterIP, accessible depuis le cluster. kubectl expose permet de creer rapidement un Service a partir d’un Deployment ou d’un pod.

La video de reference

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

Elle introduit la brique reseau indispensable apres les Deployments.

Pourquoi un Service ?

Les pods sont ephemeres. Leur IP peut changer apres une recreation. Un client ne doit donc pas dependre directement d’une IP de pod.

Le Service ajoute une abstraction stable: un nom DNS, une IP virtuelle et une selection de pods cibles.

Exemple avec Deployment

kubectl create deployment web --image=nginx
kubectl scale deployment web --replicas=3
kubectl expose deployment web --port=80 --target-port=80
kubectl get service web

Le Service web selectionne les pods du Deployment grace aux labels.

Manifest minimal

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

port est le port expose par le Service. targetPort est le port du conteneur cible.

Selection par labels

Le Service ne pointe pas vers un Deployment directement. Il pointe vers des pods qui correspondent a son selector.

kubectl get pods --show-labels
kubectl get endpoints web
kubectl describe service web

Si les labels ne correspondent pas, le Service existe mais n’a pas de endpoints.

DNS interne

Dans le meme namespace, le Service est joignable par son nom: web. Depuis un autre namespace, on peut utiliser web.default.svc.cluster.local selon le cas.

Liens utiles

• Video: https://www.youtube.com/watch?v=Z62WCbIIWyg
• Services: https://kubernetes.io/docs/concepts/services-networking/service/
• DNS for Services: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
• kubectl expose: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_expose/

FAQ

Un Service cree-t-il des pods ?

Non. Il route vers des pods existants via labels.

ClusterIP est-il accessible depuis Internet ?

Non. ClusterIP est interne au cluster.

Pourquoi mon Service n’a pas de endpoints ?

Le plus souvent parce que le selector ne correspond a aucun pod pret.

Erreurs frequentes

• Confondre port, targetPort et nodePort.
• Croire que le Service selectionne le Deployment par son nom.
• Oublier les labels sur les pods.
• Tester depuis l’exterieur alors que le Service est en ClusterIP.

Pour pratiquer

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

Ce test montre que le nom du Service devient une cible 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 019 – Debug : kubectl exec et run.

Conclusion

Le Service est la premiere brique reseau a maitriser. Il separe le cycle de vie des pods de l’adresse utilisee par les clients.