Configurer Ingress pour les équilibreurs de charge d'application externes

Cette page vous explique comment configurer un équilibreur de charge d'application externe en créant un objet Ingress Kubernetes.

Avant de lire cette page, vous devez connaître les concepts de mise en réseau GKE.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Activez le module complémentaire HttpLoadBalancing.

Le module complémentaire HttpLoadBalancing doit être activé sur votre cluster. Ce module complémentaire est activé par défaut. Dans les clusters Autopilot, vous ne pouvez pas désactiver ce module complémentaire.

Vous pouvez activer le module complémentaire HttpLoadBalancing à l'aide de la console Google Cloud ou de Google Cloud CLI.

Console

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur le nom du cluster que vous souhaitez modifier.

  3. Sous Mise en réseau, dans le champ Équilibrage de charge HTTP, cliquez sur Modifier l'équilibrage de charge HTTP.

  4. Cochez la case Activer l'équilibrage de charge HTTP.

  5. Cliquez sur Save Changes (Enregistrer les modifications).

gcloud

gcloud container clusters update CLUSTER_NAME --update-addons=HttpLoadBalancing=ENABLED

Remplacez CLUSTER_NAME par le nom de votre cluster.

Créer une adresse IP statique

Un équilibreur de charge d'application externe fournit une adresse IP stable pour l'acheminement des requêtes vers un ou plusieurs services. Si vous souhaitez obtenir une adresse IP permanente, vous devez réserver une adresse IP externe statique globale avant de créer un objet Ingress.

Si vous modifiez un objet Ingress existant pour utiliser une adresse IP statique au lieu d'une adresse IP éphémère, GKE peut modifier l'adresse IP de l'équilibreur de charge lorsque GKE recrée la règle de transfert de l'équilibreur de charge.

Créer un équilibreur de charge d'application externe

Dans cet exercice, vous allez configurer un équilibreur de charge d'application externe afin d'acheminer les requêtes vers différents services en fonction du chemin de l'URL.

Pour obtenir des instructions détaillées sur cette tâche directement dans la console Google Cloud, cliquez sur Visite guidée :

Visite guidée

Créer des déploiements et des services

Créez deux déploiements avec des services nommés hello-world-1 et hello-world-2 :

  1. Enregistrez le manifeste suivant sous le nom hello-world-deployment-1.yaml :

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world-deployment-1
spec:
  selector:
    matchLabels:
      greeting: hello
      version: one
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        version: one
    spec:
      containers:
      - name: hello-app-1
        image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0"
        env:
        - name: "PORT"
          value: "50000"

    Ce fichier manifeste décrit un exemple de déploiement comportant trois instances répliquées.

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f hello-world-deployment-1.yaml

  3. Enregistrez le manifeste suivant sous le nom hello-world-service-1.yaml :

    apiVersion: v1
kind: Service
metadata:
  name: hello-world-1
spec:
  type: NodePort
  selector:
    greeting: hello
    version: one
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

    Ce fichier manifeste décrit un service avec les propriétés suivantes :

    • Tous les pods comportant les étiquettes greeting: hello et version: one sont membres du service.
    • GKE transfère les requêtes envoyées au service sur le port TCP 60000 à l'un des pods membres sur le port TCP 50000.
    • Le type du service doit obligatoirement être NodePort, sauf si vous utilisez l'équilibrage de charge natif en conteneurs, auquel cas aucune restriction n'est imposée sur le type de service. Nous vous recommandons de définir le type comme suit : type: ClusterIP.

  4. Appliquez le fichier manifeste au cluster :

    kubectl apply -f hello-world-service-1.yaml

  5. Enregistrez le manifeste suivant sous le nom hello-world-deployment-2.yaml :

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world-deployment-2
spec:
  selector:
    matchLabels:
      greeting: hello
      version: two
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        version: two
    spec:
      containers:
      - name: hello-app-2
        image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0"
        env:
        - name: "PORT"
          value: "8080"

    Ce fichier manifeste décrit un exemple de déploiement comportant trois instances répliquées.

  6. Appliquez le fichier manifeste au cluster :

    kubectl apply -f hello-world-deployment-2.yaml

  7. Enregistrez le manifeste suivant sous le nom hello-world-service-2.yaml :

    apiVersion: v1
kind: Service
metadata:
  name: hello-world-2
spec:
  type: NodePort
  selector:
    greeting: hello
    version: two
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

    Ce fichier manifeste décrit un service avec les propriétés suivantes :

    • Tous les pods comportant les étiquettes greeting: hello et version: two sont membres du service.
    • GKE transfère les requêtes envoyées au service sur le port TCP 80 à l'un des pods membres sur le port TCP 8080.

  8. Appliquez le fichier manifeste au cluster :

    kubectl apply -f hello-world-service-2.yaml

Créer un objet Ingress

Créez un objet Ingress qui spécifie les règles de routage des requêtes en fonction du chemin de l'URL spécifié dans la requête. Lorsque vous créez l'objet Ingress, le contrôleur GKE Ingress crée et configure un équilibreur de charge d'application externe.

  1. Enregistrez le manifeste suivant sous le nom my-ingress.yaml :

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    # If the class annotation is not specified it defaults to "gce".
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: hello-world-1
            port:
              number: 60000
      - path: /v2
        pathType: ImplementationSpecific
        backend:
          service:
            name: hello-world-2
            port:
              number: 80

    Ce fichier manifeste décrit un objet Ingress avec les propriétés suivantes :

    • Il existe deux classes GKE Ingress. Pour spécifier une classe Ingress, vous devez utiliser l'annotation kubernetes.io/ingress.class. Vous ne pouvez pas spécifier le contrôleur GKE Ingress en utilisant spec.ingressClassName.

    • La classe gce déploie un équilibreur de charge d'application externe.

    • La classe gce-internal déploie un équilibreur de charge d'application interne.

    • Lorsque vous déployez une ressource Ingress sans les annotations spec.ingressClassName et kubernetes.io/ingress.class, GKE crée un équilibreur de charge d'application externe. Il s'agit du même comportement que si l'annotation kubernetes.io/ingress.class: gce était spécifiée. Pour en savoir plus, consultez la page Comportement du contrôleur GKE Ingress.

    • GKE crée un service de backend Google Cloud pour chaque backend.service.

    • Lorsqu'un client envoie une requête à l'équilibreur de charge avec le chemin d'URL /, GKE transfère la requête au service hello-world-1 sur le port 60000. Lorsqu'un client envoie une requête à l'équilibreur de charge avec le chemin d'URL /v2, GKE transfère la requête au service hello-world-2 sur le port 80. Pour en savoir plus sur les propriétés path et pathType, consultez la section Chemins d'URL.

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f my-ingress.yaml

Tester l'équilibreur de charge d'application externe

Attendez environ cinq minutes que l'équilibreur de charge soit configuré, puis testez l'équilibreur de charge d'application externe :

  1. Affichez l'objet Entrée :

    kubectl get ingress my-ingress --output yaml

    Le résultat affiche l'adresse IP de l'équilibreur de charge d'application externe :

    status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.1

  2. Testez le chemin / :

    curl LOAD_BALANCER_IP_ADDRESS/

    Remplacez LOAD_BALANCER_IP_ADDRESS par l'adresse IP externe de l'équilibreur de charge.

    Le résultat ressemble à ce qui suit :

    Hello, world!
Version: 1.0.0
Hostname: ...

    Si le résultat inclut une erreur 404, attendez quelques minutes.

  3. Testez le chemin /v2 :

    curl load-balancer-ip/v2

    Le résultat ressemble à ce qui suit :

    Hello, world!
Version: 2.0.0
Hostname: ...

Fonctionnement d'Ingress pour l'équilibrage de charge externe

Un équilibreur de charge d'application externe agit comme un proxy entre vos clients et votre application. Si vous souhaitez accepter les requêtes HTTPS de vos clients, l'équilibreur de charge doit disposer d'un certificat pour justifier son identité auprès de vos clients. L'équilibreur de charge doit également disposer d'une clé privée pour effectuer la négociation HTTPS. Pour en savoir plus, consultez les pages suivantes :

Chemins d'URL

Le seul caractère générique accepté pour le champ path d'une entrée est l'astérisque (*). Le caractère * doit être placé immédiatement après une barre oblique (/) et doit être le dernier caractère du modèle. Par exemple, /*, /foo/* et /foo/bar/* sont des modèles valides, mais ce n'est pas le cas de *, /foo/bar* et /foo/*/bar.

Un modèle plus restrictif a priorité sur un modèle moins restrictif. Si vous avez à la fois /foo/* et /foo/bar/*, alors /foo/bar/bat est considéré comme correspondant à /foo/bar/*. Pour plus d'informations sur les restrictions en matière de chemin d'accès et la correspondance de modèle, consultez la documentation relative aux mappages d'URL.

Pour les clusters GKE exécutant des versions antérieures à la version 1.21.3-gke.1600, la seule valeur acceptée pour le champ pathType est ImplementationSpecific. Pour les clusters exécutant la version 1.21.3-gke.1600 ou ultérieure, les valeurs Prefix et Exact sont également acceptées pour pathType.

Désactiver HTTP

Si vous souhaitez que tout le trafic entre le client et l'équilibreur de charge utilise HTTPS, désactivez HTTP. Pour plus d'informations, consultez la page Désactiver HTTP.

HTTPS entre l'équilibreur de charge et l'application

Si votre application, qui s'exécute dans un pod GKE, est capable de recevoir des requêtes HTTPS, configurez l'équilibreur de charge pour qu'il utilise HTTPS lorsqu'il transfère des requêtes à votre application. Pour plus d'informations, consultez la section HTTPS (TLS) entre l'équilibreur de charge et votre application.

HTTP/2 entre le client et l'équilibreur de charge

Les clients peuvent utiliser HTTP/2 pour envoyer des requêtes à l'équilibreur de charge. Aucune configuration n'est requise.

HTTP/2 entre l'équilibreur de charge et l'application

Configurez l'équilibreur de charge pour qu'il utilise HTTP/2 lorsqu'il transfère des requêtes à votre application si cette dernière, exécutée dans un pod GKE, est capable de recevoir des requêtes HTTP/2. Pour plus d'informations, consultez la section HTTP/2 pour l'équilibrage de charge avec l'objet Entrée.

Groupes de points de terminaison du réseau

Si votre cluster est compatible avec l'équilibrage de charge natif en conteneurs, il est recommandé d'utiliser des groupes de points de terminaison du réseau (NEG). Pour les clusters GKE 1.17 et les versions ultérieures, et sous certaines conditions, l'équilibrage de charge natif en conteneurs est défini par défaut. Aucune annotation de service cloud.google.com/neg: '{"ingress": true}' explicite n'est requise.

VPC partagé

Si le cluster GKE dans lequel vous déployez les ressources d'entrée se trouve dans un projet de service et que vous souhaitez que le plan de contrôle GKE gère les ressources de pare-feu dans votre projet hôte, le compte de service GKE du projet de service doit disposer des autorisations IAM appropriées sur le projet hôte, conformément à la section Gérer les ressources de pare-feu pour les clusters avec VPC partagé. Cela permet au contrôleur d'entrée de créer des règles de pare-feu afin d'autoriser le trafic entrant et le trafic pour les vérifications d'état Google Cloud.

Voici un exemple d'événement qui peut exister dans les journaux de ressources d'entrée. Cette erreur se produit lorsque le contrôleur d'entrée ne parvient pas à créer une règle de pare-feu pour autoriser le trafic entrant pour les vérifications d'état Google Cloud si les autorisations ne sont pas configurées correctement.

Firewall change required by security admin: `gcloud compute firewall-rules update <RULE_NAME> --description "GCE L7 firewall rule" --allow tcp:<PORT> --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags <TARGET_TAG> --project <HOST_PROJECT>

Si vous préférez provisionner manuellement les règles de pare-feu à partir du projet hôte, vous pouvez mettre en sourdine les événements firewallXPNError en ajoutant l'annotation networking.gke.io/suppress-firewall-xpn-error: "true" à la ressource Ingress.

Récapitulatif des annotations de l'entrée externe

Annotations de l'entrée

Annotation Description
kubernetes.io/ingress.allow-http Spécifie s'il faut autoriser le trafic HTTP entre le client et l'équilibreur de charge HTTP(S). Les valeurs possibles sont "true" et "false". La valeur par défaut est "true". Voir Désactiver HTTP.
ingress.gcp.kubernetes.io/pre-shared-cert Utilisez cette annotation pour associer des ressources de certificats à des ressources Ingress de GKE. Pour en savoir plus, consultez la page Utiliser plusieurs certificats SSL avec des équilibreurs de charge d'application externes.
kubernetes.io/ingress.global-static-ip-name Utilisez cette annotation pour indiquer que l'équilibreur de charge doit utiliser une adresse IP externe statique que vous avez créée précédemment. Voir Adresses IP statiques pour les équilibreurs de charge HTTP(S).
networking.gke.io/v1beta1.FrontendConfig Utilisez cette annotation pour personnaliser la configuration côté client de l'équilibreur de charge. Pour en savoir plus, consultez la page Configuration d'entrée.
networking.gke.io/suppress-firewall-xpn-error Pour les équilibreurs de charge d'entrée, si Kubernetes ne peut pas modifier les règles du pare-feu en raison d'autorisations insuffisantes, un événement firewallXPNError est créé régulièrement (avec un délai de quelques minutes entre les diffusions). Dans GLBC 1.4 et ses versions ultérieures, vous pouvez désactiver l'événement firewallXPNError en ajoutant l'annotation networking.gke.io/suppress-firewall-xpn-error: "true" à la ressource d'entrée. Vous pouvez supprimer cette annotation pour réactiver l'événement. Les valeurs possibles sont true et false. La valeur par défaut est false.
Annotation Description
cloud.google.com/app-protocols Utilisez cette annotation pour définir le protocole de communication entre l'équilibreur de charge et l'application. Les protocoles possibles sont HTTP, HTTPS et HTTP2. Consultez les sections HTTPS entre l'équilibreur de charge et votre application et HTTP/2 pour l'équilibrage de charge avec l'objet Ingress.
cloud.google.com/backend-config Utilisez cette annotation pour configurer le service de backend associé à un service. Pour en savoir plus, consultez la page Configuration d'entrée.
cloud.google.com/neg Utilisez cette annotation pour indiquer que l'équilibreur de charge doit utiliser des groupes de points de terminaison du réseau. Voir Utiliser l'équilibrage de charge natif en conteneurs.

Étapes suivantes