Kubernetes 021 – Services : NodePort, LoadBalancer, ExternalName et Endpoints

TL;DR

NodePort expose un port sur chaque noeud. LoadBalancer demande un load balancer externe quand l’infrastructure le supporte. ExternalName cree un alias DNS vers un nom externe. Les endpoints representent les cibles reelles du Service.

La video de reference

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

Elle compare les types de Services les plus courants.

NodePort

apiVersion: v1
kind: Service
metadata:
  name: web-nodeport
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

Le Service est accessible via l’IP d’un noeud et le port 30080. C’est pratique en lab, moins ideal comme exposition finale en production.

LoadBalancer

spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80

Dans un cloud, Kubernetes demande souvent la creation d’un load balancer externe. En local, il faut parfois un composant comme MetalLB.

ExternalName

apiVersion: v1
kind: Service
metadata:
  name: database
spec:
  type: ExternalName
  externalName: db.example.org

Ici, le Service ne cree pas de proxy vers des pods. Il cree une abstraction DNS vers un nom externe.

Endpoints et EndpointSlices

Les endpoints sont les cibles reelles d’un Service. Kubernetes utilise aujourd’hui aussi les EndpointSlices pour mieux passer a l’echelle.

kubectl get endpoints
kubectl get endpointslices
kubectl describe service web

Commandes de test

kubectl get svc
kubectl describe svc web-nodeport
kubectl get nodes -o wide
curl http://<node-ip>:30080

Liens utiles

• Video: https://www.youtube.com/watch?v=tF28iwTco9A
• Services: https://kubernetes.io/docs/concepts/services-networking/service/
• Service type NodePort: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport
• Service type LoadBalancer: https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer
• ExternalName: https://kubernetes.io/docs/concepts/services-networking/service/#externalname

FAQ

NodePort est-il obligatoire pour LoadBalancer ?

Historiquement, un LoadBalancer s’appuie souvent sur un NodePort, meme si les implementations evoluent.

ExternalName verifie-t-il que la cible existe ?

Non. Il fournit un alias DNS, pas une verification applicative.

Quel type choisir pour une application interne ?

ClusterIP dans la majorite des cas.

Erreurs frequentes

• Utiliser NodePort comme solution d’exposition propre en production sans reflexion.
• Attendre une IP externe LoadBalancer sur un cluster local non equipe.
• Croire qu’ExternalName cree des endpoints de pods.
• Oublier les firewalls des noeuds.

Pour pratiquer

kubectl create deployment web --image=nginx
kubectl expose deployment web --type=NodePort --port=80
kubectl get svc web
kubectl describe svc web

Comparez ensuite avec un Service ClusterIP et observez les differences de champs.

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 022 – Services : kube-proxy, modes et iptables.

Conclusion

Les types de Services repondent a des besoins differents. Le bon choix depend du chemin reseau voulu: interne, via les noeuds, via un load balancer ou vers un nom externe.