Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Déployer des services LoadBalancer multiréseaux

Autopilot Standard

Ce document explique comment exposer des pods multiréseaux à des clients internes ou externes en créant Google Cloud des ressources d'équilibreur de charge réseau passthrough externe et d'équilibreur de charge réseau passthrough interne dans GKE. Il décrit la configuration, les fonctionnalités et les limites requises des services LoadBalancer multiréseaux.

Si vous connectez des charges de travail à plusieurs réseaux VPC, utilisez un service Kubernetes de type LoadBalancer pour acheminer le trafic vers des pods sur un réseau secondaire spécifique. Lorsque vous créez le service, GKE crée un équilibreur de charge réseau passthrough pour gérer ce trafic.

Pour en savoir plus sur la mise en réseau multiple dans GKE, consultez À propos de la compatibilité multiréseau pour les pods.

Fonctionnement des services LoadBalancer multiréseaux

Pour exposer une charge de travail multiréseau, créez un Service de type: LoadBalancer. Le service doit inclure un sélecteur spécial qui cible les pods en fonction du réseau de leur interface secondaire. Ajoutez une annotation pour spécifier si vous souhaitez créer un équilibreur de charge interne ou externe.

Le libellé networking.gke.io/network du sélecteur filtre les points de terminaison par réseau. Ce libellé garantit que l'équilibreur de charge n'envoie le trafic qu'aux interfaces de pod connectées au réseau spécifié.

Limites

Les équilibreurs de charge multiréseaux présentent les limites suivantes :

Les services qui utilisent externalTrafficPolicy: Cluster ne sont pas compatibles.
Les services qui ciblent les pods hostNetwork ne sont pas compatibles.
La mise en réseau IPv6 et à double pile n'est pas compatible.
Vous ne pouvez pas modifier le réseau d'un service existant.
Seuls les réseaux de couche 3 sont compatibles.
Les équilibreurs de charge basés sur des pools cibles ou des backends de groupe d'instances ne sont pas compatibles.
Les services ClusterIP et NodePort ne sont pas compatibles sur les réseaux secondaires (non par défaut).

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Suivez la procédure décrite dans Configurer la compatibilité multiréseau pour les pods afin de préparer vos réseaux VPC et de créer un cluster GKE avec un réseau supplémentaire.
Assurez-vous que le sous-paramètre des équilibreurs de charge internes de couche 4 est activé pour votre cluster. Pour activer cette fonctionnalité, utilisez l'indicateur --enable-l4-ilb-subsetting lorsque vous créez ou mettez à jour le cluster.
Assurez-vous que votre cluster exécute GKE version 1.37 ou ultérieure.

Déployer des pods multiréseaux

Pour associer des pods à un réseau supplémentaire, créez un déploiement avec l'annotation networking.gke.io/interfaces. Cette annotation spécifie les réseaux et les interfaces des pods.

Enregistrez le manifeste suivant sous le nom web-app-deployment.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
      annotations:
        networking.gke.io/default-interface: 'eth1'
        networking.gke.io/interfaces: '[
          {"interfaceName":"eth0","network":"default"},
          {"interfaceName": "eth1","network": "dmz"}
        ]'
spec:
  containers:
  - name: whereami
    image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
    ports:
    - containerPort: 8080

Ce fichier manifeste crée un déploiement nommé web-app avec trois pods. Les pods comportent deux interfaces : eth0 connectée au réseau default et eth1 connectée au réseau dmz. L'annotation networking.gke.io/default-interface définit eth1 comme interface par défaut pour les pods.

Appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f web-app-deployment.yaml
```

Si vous utilisez une interface non par défaut pour votre service, vous devez configurer le routage dans le pod. Pour configurer le routage, ajoutez un initContainer à la spécification de votre pod avec la fonctionnalité NET_ADMIN.

L'exemple suivant montre un initContainer qui ajoute une route par défaut pour l'interface eth1 :

initContainers:
      - name: init-routes-busybox
        image: busybox
        command: ['sh', '-c', 'ip route add default dev eth1 table 200 && ip rule add from 172.16.1.0/24 table 200']
        securityContext:
          capabilities:
            add: ["NET_ADMIN"]

Dans la commande initContainer, remplacez 172.16.1.0/24 par la plage d'adresses IP secondaire de votre réseau de pods.

Déployer un service LoadBalancer interne

Pour exposer le déploiement web-app sur le réseau dmz, créez un service LoadBalancer interne.

Enregistrez le manifeste suivant sous le nom internal-lb-service.yaml :

apiVersion: v1
kind: Service
metadata:
  name: web-app-internal-lb
  namespace: default
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  externalTrafficPolicy: Local
  ports:
  -   port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    networking.gke.io/network: dmz
    app: web-app
  type: LoadBalancer

Ce fichier manifeste crée un service avec les propriétés suivantes :

networking.gke.io/load-balancer-type: "Internal" : spécifie un équilibreur de charge réseau passthrough interne.
selector: sélectionne les pods avec le libellé app: web-app qui sont connectés au réseau dmz.

Appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f internal-lb-service.yaml
```

Déployer un service LoadBalancer externe

Pour exposer le déploiement web-app à des clients externes, créez un service LoadBalancer externe.

Enregistrez le manifeste suivant sous le nom external-lb-service.yaml :

apiVersion: v1
kind: Service
metadata:
  name: web-app-external-lb
  namespace: default
  annotations:
    cloud.google.com/l4-rbs: "enabled"
spec:
  externalTrafficPolicy: Local
  ports:
  -   port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    networking.gke.io/network: dmz
    app: web-app
  type: LoadBalancer

Ce fichier manifeste crée un service avec les propriétés suivantes :

cloud.google.com/l4-rbs: "enabled" : spécifie un équilibreur de charge réseau passthrough externe basé sur un service de backend.
selector: sélectionne les pods avec le libellé app: web-app qui sont connectés au réseau dmz.

Appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f external-lb-service.yaml
```

Vérifier les services

Une fois les services déployés, vérifiez que les équilibreurs de charge sont créés et configurés correctement.

Vérifiez l'état des services :

kubectl get services

Le résultat ressemble à ce qui suit :

NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE
web-app-external-lb   LoadBalancer   10.8.47.77    35.239.57.231   80:31550/TCP   5m
web-app-internal-lb   LoadBalancer   10.8.43.251   172.16.0.43     80:32628/TCP   6m
kubernetes            ClusterIP      10.8.32.1     <none>          443/TCP        43h

L'adresse EXTERNAL-IP de l'équilibreur de charge interne appartient au réseau dmz.

Répertoriez les règles de transfert de votre projet :

gcloud compute forwarding-rules list

Le résultat ressemble à ce qui suit :

NAME                                                   REGION        IP_ADDRESS     IP_PROTOCOL  TARGET
af901673cc0f24907a6aa8c3ce4afc21                       us-central1   35.239.57.231  TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-external-lb-u4xbs4ot
k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a us-central1   172.16.0.43    TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-internal-lb-vp1x1d6a

Décrivez la règle de transfert de l'équilibreur de charge interne pour vérifier qu'elle est associée au bon réseau :

gcloud compute forwarding-rules describe k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a --region=$REGION

Remplacez REGION par la région de votre cluster.

Le résultat renvoyé ressemble à ceci. Vérifiez que les network et subnetwork champs correspondent aux détails du dmz réseau.

IPAddress: 172.16.0.43
IPProtocol: TCP
...
loadBalancingScheme: INTERNAL
name: k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a
network: https://www.googleapis.com/compute/v1/projects/projectId/global/networks/dmz-vpc
...
subnetwork: https://www.googleapis.com/compute/v1/projects/projectId/regions/us-central1/subnetworks/dmz-subnet

Tester les équilibreurs de charge

Pour tester l'équilibreur de charge externe, envoyez une requête à son adresse IP externe :
```
curl EXTERNAL_LB_IP:80
```
Remplacez EXTERNAL_LB_IP par l'adresse IP externe du service web-app-external-lb.
Pour tester l'équilibreur de charge interne, envoyez une requête à partir d'un hôte situé dans le même VPC que l'équilibreur de charge :
```
curl INTERNAL_LB_IP:80
```
Remplacez INTERNAL_LB_IP par l'adresse IP du service web-app-internal-lb.

Dépannage

Cette section explique comment résoudre les problèmes liés aux équilibreurs de charge multiréseaux.

Échec de la création de l'équilibreur de charge

En cas d'échec de la création de l'équilibreur de charge, recherchez les messages d'erreur dans les événements du service :

kubectl describe service SERVICE_NAME

Remplacez SERVICE_NAME par le nom de votre service.

Un message d'erreur tel que network some-other-network does not exist indique que le réseau spécifié dans le sélecteur de service n'est pas défini dans le cluster. Vérifiez que le réseau existe :

kubectl get networks

Si le réseau existe, vérifiez que l'objet Network fait correctement référence à une ressource GKENetworkParamSet valide. Pour examiner les erreurs de configuration, inspectez l'état de la ressource Network :

kubectl get networks NETWORK_NAME -o yaml

Remplacez NETWORK_NAME par le nom du réseau.

Dans une configuration valide, les conditions ParamsReady et Ready sont True. Si ParamsReady n'est pas True, assurez-vous que le parametersRef de la Network spécification correspond correctement au nom, au type et au groupe d'une ressource GKENetworkParamSet existante.

Si la ressource Network est correcte, mais qu'elle n'est toujours pas prête, vérifiez l'état de l'élément GKENetworkParamSet référencé pour détecter les erreurs, par exemple un sous-réseau manquant :

kubectl get gkenetworkparamsets GNP_NAME -o yaml

Remplacez GNP_NAME par le nom de votre GKENetworkParamSet.

L'équilibreur de charge ne comporte aucun backend

Si l'équilibreur de charge est provisionné, mais qu'il ne comporte aucun backend sain, procédez comme suit :

Vérifiez qu'un pool de nœuds existe avec des interfaces réseau dans le réseau utilisé par le service.
Vérifiez que les pods sélectionnés par le service sont en cours d'exécution.
Vérifiez les points de terminaison du service :
```
kubectl describe endpointslice -l kubernetes.io/service-name=SERVICE_NAME
```
Le contrôleur multinet-endpointslice-controller.gke.io crée les points de terminaison multiréseaux. Les adresses IP de pod listées dans l'EndpointSlice appartiennent au réseau utilisé par le service. Si l'EndpointSlice ne comporte aucun point de terminaison, vérifiez que les libellés du sélecteur de service correspondent aux pods en cours d'exécution et que le sélecteur de réseau correspond au réseau des pods.

Étape suivante

En savoir plus sur la compatibilité multiréseau pour les pods
En savoir plus sur les services multiréseaux.

Déployer des services LoadBalancer multiréseaux Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.