Kubernetes services
| Fiche express | |
|---|---|
| Type | Abstraction réseau stable devant un ensemble de Pods |
| Types | ClusterIP · NodePort · LoadBalancer · ExternalName |
| Modèle détaillé | voir Réseau Kubernetes — Modèle et primitives |
| Voir aussi | Kubernetes deployments · Ingress et Gateway API · Kubectl |
Un Service fournit une adresse réseau stable devant un ensemble de Pods sélectionnés par labels, indépendamment de leur position sur les nœuds ou de leur cycle de vie individuel (les IP de Pods sont éphémères). Cette page se concentre sur l'usage pratique côté Kubectl ; pour le modèle réseau sous-jacent (kube-proxy, CoreDNS, comportement de chaque type de Service) voir Réseau Kubernetes — Modèle et primitives.
Pour rappel, les quatre types de Service :
| Type | Exposition |
|---|---|
| ClusterIP (par défaut) | IP interne au cluster uniquement |
| NodePort | Port ouvert sur chaque nœud, accessible depuis l'extérieur du cluster |
| LoadBalancer | IP externe fournie par un load-balancer (cloud, ou MetalLB/Cilium on-prem) |
| ExternalName | Alias DNS (CNAME) vers un nom externe au cluster |
Créer et vérifier un Service ClusterIP
# créer un Deployment applicatif
kubectl create -f deployment-svc-example.yml
# exposer ses Pods dans le réseau du cluster via un Service ClusterIP
kubectl create -f svc-clusterip.yml
# lister les endpoints réels rattachés au Service
kubectl get endpoints svc-clusterip
# tester depuis un pod de debug
kubectl create -f pod-svc-test.yml
kubectl exec pod-svc-test -- curl svc-clusterip:80
Exposer un Service en dehors du cluster (NodePort)
kubectl create -f svc-nodeport.yml
# depuis une machine ayant accès au nœud, sur le port exposé
curl localhost:30080
Résolution DNS d'un Service
kubectl get service svc-clusterip
# résolution DNS depuis un pod du même namespace
kubectl exec pod-svc-test -- nslookup <IP_du_Service>
kubectl exec pod-svc-test -- curl svc-clusterip
kubectl exec pod-svc-test -- curl svc-clusterip.default.svc.cluster.local
Depuis un Pod situé dans un autre namespace, le nom court du Service ne résout plus : il faut son nom pleinement qualifié.
kubectl create namespace new-namespace
kubectl create -f pod-svc-test-new-namespace.yml -n new-namespace
# échoue : le nom court n'est résolu que dans le namespace d'origine du Service
kubectl exec -n new-namespace pod-svc-test-new-namespace -- curl svc-clusterip
# fonctionne : nom pleinement qualifié
kubectl exec -n new-namespace pod-svc-test-new-namespace -- curl svc-clusterip.default.svc.cluster.local
Exposition HTTP mutualisée : Ingress
Multiplier les Services de type LoadBalancer ne passe pas à l'échelle pour exposer de nombreuses applications HTTP ; un contrôleur Ingress (à installer séparément dans le cluster) permet de router plusieurs noms/chemins HTTP vers différents Services derrière une entrée unique. Voir Ingress et Gateway API pour le détail des objets et des contrôleurs disponibles.
kubectl create -f my-ingress.yml
kubectl describe ingress my-ingress
Le nom du port du Service ciblé par l'Ingress doit être explicite dans le manifeste du Service (et pas seulement le numéro) pour certains contrôleurs :
kubectl apply -f svc-clusterip.yml
kubectl apply -f my-ingress.yml
kubectl describe ingress my-ingress