Aller au contenu principal
TechLedger Registre technique
Sommaire de la formation

services et type de services

coolibra352 vues

Services et Types de Services

  • Service : Abstraction réseau pour exposer les applications au sein ou à l'extérieur du cluster.
  • Types de Services : ClusterIP, NodePort, LoadBalancer, et ExternalName / externalIP.
  • DNS dans Kubernetes

Dans ce chapitre, nous allons plonger dans les concepts de réseau au sein de Kubernetes. Nous allons aborder les différentes notions telles que les services, le DNS et les politiques réseau. De plus, nous allons explorer comment configurer les services pour exposer des applications à l'intérieur et à l'extérieur du cluster.

Concepts de réseau dans Kubernetes

Avant de plonger dans les détails, il est important de comprendre les fondamentaux du réseau dans Kubernetes. Nous allons explorer les trois principaux concepts qui sont les piliers de la gestion du réseau :

  • Services Kubernetes : Les services sont une abstraction qui permet d'exposer des applications aux utilisateurs ou à d'autres services au sein du cluster. Ils offrent un moyen de communication stable et fiable avec les applications, indépendamment de l'endroit où elles sont déployées.

  • DNS dans Kubernetes : Le service DNS de Kubernetes permet aux conteneurs de communiquer entre eux en utilisant des noms au lieu d'adresses IP. Cela facilite grandement la gestion des connexions entre les différents composants de l'application.

  • Politiques Réseau : Les politiques réseau définissent les règles pour contrôler les communications entre les pods. Cela permet d'assurer un niveau de sécurité et d'isolation dans l'environnement.

Configuration de services pour exposer des applications

Les services Kubernetes jouent un rôle essentiel pour exposer vos applications aux utilisateurs et aux autres services. Voici comment configurer différents types de services pour répondre à vos besoins :

  1. ClusterIP : Expose le service au sein du cluster en utilisant une adresse IP interne.

  2. NodePort : Expose le service à l'extérieur du cluster en utilisant un port spécifique sur chaque nœud.

  3. LoadBalancer : Expose le service à l'extérieur du cluster et provisionne un équilibreur de charge externe.

  4. ExternalName : Renvoie des noms DNS à l'extérieur du cluster.

  5. Headless : Renvoie directement aux IPs des pods sans kubeproxy

 

  • Le serice type ClusterIP

Le service ClusterIP permet d'exposer une application à l'intérieur du cluster en utilisant une adresse IP interne. Voici un exemple de configuration YAML pour un service ClusterIP :

apiVersion: v1
kind: Service
metadata:
  name: caddy-service-clusterip
spec:
  selector:
    app: caddy-web-app  # Sélecteur pour cibler les pods avec ces labels
  ports:
    - protocol: TCP
      port: 8080  # Port du service caddy-web-app
      targetPort: 80 # Port sur lequel caddy écoute à l'intérieur du pod
---

apiVersion: v1
kind: Pod
metadata:
  name: caddy-pod
  labels:
    app: caddy-web-app
    tier: front-end
  annotations:
    description: "This pod runs a caddy web app"
spec:
  containers:
  - name: caddy-container
    image: caddy:latest

 

# creer le ficher clusterip.yaml et appliquer le
kubectl apply -f clusterip.yaml
kubectl get pod,svc

 

Dans cet exemple, le service caddy-service-clusterip expose l'application associée aux pods sur le port 8080 avec l'étiquette app: caddy-web-app en utilisant le port 80 à l'intérieur du cluster.

Depuis un autre pode, on peut faire un curl sur le service name: caddy-service-clusterip:8080

Test avec busybox

kubectl run ubuntu-debug --rm -it --image=ubuntu -- /bin/bash

# installer les tools de debug dans le le pod ubuntu-debug
apt update && apt install -y dnsutils curl net-tools inetutils-ping

# lancer le curl depuis le pod ubuntu-debug
curl http://caddy-service-clusterip.default.svc.cluster.local:8080

 

Pour supprimer:

kubectl delete -f clusterip.yaml

 

  • Le serice type NodePort

Le service NodePort expose l'application à l'extérieur du cluster en utilisant un port spécifique entre 30000-32767 sur chaque nœud. Voici un exemple de configuration YAML pour un service NodePort :

apiVersion: v1
kind: Service
metadata:
  name: web-service-nodeport
  labels:
    app: web
    env: production
spec:
  selector:
    app: web
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort: http-web-svc
  type: NodePort  # nodePort: 30007

---

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: web
    env: production
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
      - containerPort: 80
        name: http-web-svc

 

# creer le ficher nodeport.yaml et appliquer le
kubectl apply -f nodeport.yaml
kubectl get pod,svc

 

 

On voit bien le service a pris le port aléatoire 32582

Pour acceder à l'application, on prend l'ip de n'importe quel node: http://node_ip:32582

 

Dans cet exemple, le service web-service-nodeport expose l'application associée aux pods avec l'étiquette app: web en utilisant le nodeport 32582 à l'extérieur du cluster.

On peut également fixer ce port avec ce exemple:

apiVersion: v1
kind: Service
metadata:
  name: web-service-nodeport
  labels:
    app: web
    env: production
spec:
  selector:
    app: web
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort: http-web-svc
    nodePort: 30007

 

  • Le serice type LoadBalancer

Le service LoadBalancer expose l'application à l'extérieur du cluster en provisionnant un équilibreur de charge externe. Voici un exemple de configuration YAML pour un service LoadBalancer :

apiVersion: v1
kind: Service
metadata:
  name: web-service-lb
  labels:
    app: web
    env: dev
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

---

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: web
    env: dev
spec:
  containers:
  - name: nginx-container
    image: nginx:latest

Dans cet exemple, le service web-service-lb expose l'application associée aux pods avec l'étiquette app: web en utilisant le port 80 à l'extérieur du cluster et provisionne un équilibreur de charge externe.

Pour que ça le service de type loadbalancer fonctionne, il faut installer un addons quand vous êtes on-premise. Mais si c'est le cloud votre cloud provider va piloter le composant cloud-controller-manager et fournir une ip à au service. On vera dans la suite l'utilisation on-premise.

C'est pour ces raisons que le service reste en mode pending. Mais l'application est accessible comme si c'est le service de type nodeport.

 

 

  • Le serice type ExternalName

Le service ExternalName renvoie des noms DNS à l'extérieur du cluster. Voici un exemple de configuration YAML pour un service ExternalName :

apiVersion: v1
kind: Service
metadata:
  name: mon-service-external
spec:
  type: ExternalName
  externalName: my.database.example.com

---

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 49152
  externalIPs:
    - 198.51.100.32

Dans cet exemple, le service mon-service-external renvoie les requêtes au nom DNS my.database.example.com à l'extérieur du cluster.

Ces exemples illustrent comment utiliser différents types de services pour exposer des applications dans un environnement Kubernetes. Chaque type de service offre des avantages spécifiques en fonction des besoins de déploiement et de connectivité.

 

  • Le serice type Headless

Un service "headless" (sans tête) est un type de service dans Kubernetes qui ne fournit pas de service d'équilibrage de charge (LoadBalancer) ni de service de type ClusterIP (ClusterIP service). Au lieu de cela, un service headless est utilisé pour obtenir des adresses IP directes des pods associés à une application sans introduire de proxy réseau (comme un LoadBalancer ou un ClusterIP) entre les clients et les pods.

Voici comment un service headless fonctionne :

  1. Pas de ClusterIP : Contrairement aux services normaux, un service headless n'a pas d'adresse IP ClusterIP attribuée. Cela signifie qu'il n'y a pas de proxy réseau intermédiaire entre les clients et les pods.

  2. DNS : Un service headless est associé à une entrée DNS spéciale. Par exemple, si vous avez un service headless nommé "mon-service", le DNS de ce service serait "mon-service.namespace.svc.cluster.local". Cette entrée DNS pointe vers les adresses IP directes des pods associés au service.

  3. Adresses IP directes : Lorsqu'un client résout le DNS du service headless, il obtient une liste d'adresses IP directes des pods. Les clients peuvent alors se connecter directement aux pods à l'aide de ces adresses IP.

Les services headless sont utiles dans divers scénarios, notamment :

  • StatefulSets : Les StatefulSets sont souvent utilisées pour des applications nécessitant des identifiants uniques et stables pour chaque pod (par exemple, les bases de données). Les services headless garantissent que chaque pod a une adresse IP stable et prévisible.

  • Services de découverte : Les services headless sont utilisés pour exposer des applications qui fournissent des informations de découverte aux autres parties de l'infrastructure.

  • Accès direct aux pods : Ils permettent un accès direct aux pods sans passer par un équilibrage de charge, ce qui peut être utile pour le débogage ou la communication entre des parties spécifiques de l'application.

En résumé, un service headless dans Kubernetes est un type de service qui permet d'obtenir des adresses IP directes des pods associés à une application via le DNS, sans utiliser de proxy réseau. Cela peut être très utile pour des cas d'utilisation spécifiques où une communication directe avec les pods est nécessaire.

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
  namespace: mon-espace-de-noms
spec:
  clusterIP: None   # C'est ce qui indique qu'il s'agit d'un service headless
  selector:
    app: mon-app     # Sélectionne les pods associés à ce service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

 

nslookup my-headless-service.mon-espace-de-noms.svc.cluster.local

 

  • DNS dans Kubernetes

Kubernetes offre un service de résolution de noms (DNS) intégré qui permet aux conteneurs de communiquer entre eux par le biais de noms au lieu d'adresses IP. Le service DNS permet de découvrir dynamiquement les adresses IP des pods et des services au sein du cluster. Dans cluster notre test, on utilise coredns

Exemple détaillé pour la configuration du service DNS

Pour illustrer l'utilisation du service DNS dans Kubernetes, voici un exemple de déploiement qui exécute deux pods et les expose via un service, avec utilisation du service DNS pour la communication entre les pods :

  • Créez un fichier YAML pour le déploiement :
apiVersion: v1
kind: Pod
metadata:
  name: nginx-dns
  labels:
    app: web
    env: dns
spec:
  containers:
  - name: nginx-container
    image: nginx:latest

---

apiVersion: v1
kind: Service
metadata:
  name: dns-service
  labels:
    app: web
    env: dns
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

 

  • Appliquez les fichiers YAML à votre cluster :
kubectl apply -f dns-service.yaml

 

  • Obtenez les adresses IP des pods à l'aide de la résolution DNS :

Les pods exécutés par le déploiement sont automatiquement assignés des noms de sous-domaine en fonction de leur étiquette, par exemple nom-du-pod.mon-service.default.svc.cluster.local

Vous pouvez utiliser ces noms de domaine pour communiquer entre les pods, comme illustré dans l'exemple suivant :

kubectl exec -it nginx-dns -- /bin/sh

# À l'intérieur du conteneur du pod
curl nom-du-pod-2.mon-service.default.svc.cluster.local

 

Cet exemple montre comment configurer et utiliser le service DNS intégré de Kubernetes pour la résolution des noms entre les pods. Les noms de domaine générés sont basés sur les étiquettes des pods et permettent une communication efficace à l'intérieur du cluster.

 

 

Commentaires

Connectez-vous pour rejoindre la discussion.

Aucun commentaire pour le moment.