Configurer Ingress pour l'équilibrage de charge externe

Cette page explique comment configurer un équilibreur de charge HTTP(S) externe en créant un objet Kubernetes Ingress (Entrée). Un objet Entrée doit être associé à un ou plusieurs objets Service, chacun étant associé à un ensemble de pods.

Un objet Service possède une ou plusieurs structures servicePort. Chaque servicePort ciblé par un objet Entrée est associé à une ressource du service de backend de Google Cloud.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

  • Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
  • Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

  1. Exécutez gcloud init et suivez les instructions :

    gcloud init

    Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

    gcloud init --console-only
  2. Suivez les instructions pour autoriser gcloud à utiliser votre compte Google Cloud.
  3. Créez ou sélectionnez une configuration.
  4. Choisissez un projet Google Cloud.
  5. Choisissez une zone Compute Engine par défaut pour les clusters zonaux ou une région pour les clusters régionaux ou Autopilot.

Utiliser gcloud config

  • Définissez votre ID de projet par défaut :
    gcloud config set project PROJECT_ID
  • Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut :
    gcloud config set compute/zone COMPUTE_ZONE
  • Si vous utilisez des clusters Autopilot ou régionaux, définissez votre région de calcul par défaut :
    gcloud config set compute/region COMPUTE_REGION
  • Mettez à jour gcloud vers la dernière version :
    gcloud components update

Vous devez disposer d'un cluster GKE dans votre projet avec le module complémentaire d'équilibrage de charge HTTP(S) activé :

Console

  1. Accédez à la page Google Kubernetes Engine dans 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

cluster-name correspond au nom de votre cluster.

Créer un équilibreur de charge HTTP(S) externe

Un équilibreur de charge HTTP(S) externe fournit une adresse IP stable pour l'acheminement des requêtes vers divers services de backend. Pour obtenir une adresse IP permanente, vous devez réserver une adresse IP externe statique globale.

Dans cet exercice, vous allez configurer un équilibreur de charge HTTP(S) externe afin d'acheminer les requêtes vers différents services de backend en fonction du chemin de l'URL. Les requêtes dont le chemin est / sont routées vers un certain service de backend et celles dont le chemin est /kube sont routées vers un autre service de backend.

Voici les principales étapes à suivre dans cet exercice :

  1. Créez un objet Déploiement que vous exposez avec un service nommé hello-world.
  2. Créez un deuxième objet Déploiement que vous exposez avec un service nommé hello-kubernetes.
  3. Créez un objet Entrée qui spécifie les règles de routage des requêtes vers un objet Service ou un autre, en fonction du chemin de l'URL spécifié dans la requête. Lorsque vous créez l'objet Entrée, le contrôleur d'entrée GKE crée et configure un équilibreur de charge HTTP(S) externe.
  4. Testez l'équilibreur de charge HTTP(S) externe.

Créer un déploiement

Le fichier manifeste du premier objet Déploiement se présente comme suit :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
      department: world
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        department: world
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"
        env:
        - name: "PORT"
          value: "50000"

Copiez le fichier manifeste dans un fichier nommé hello-world-deployment.yaml, puis créez le déploiement :

kubectl apply -f hello-world-deployment.yaml

Créer un service

Le fichier manifeste de l'objet Service qui expose votre premier objet Déploiement est semblable à ceci :

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

Pour les besoins de cet exercice, voici les points importants à noter à propos de l'objet Service :

  • Tous les pods comportant les étiquettes greeting: hello et department: world sont membres du service.

  • Lorsqu'une requête est envoyée à l'objet Service sur le port TCP 60000, elle est transmise à l'un des pods membres sur le port TCP 50000.

Copiez le fichier manifeste dans un fichier nommé hello-world-service.yaml, puis créez le service :

kubectl apply -f hello-world-service.yaml

Créer un deuxième déploiement

Voici un fichier manifeste pour un deuxième objet Déploiement :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-kubernetes-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
      department: kubernetes
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        department: kubernetes
    spec:
      containers:
      - name: hello-again
        image: "gcr.io/google-samples/node-hello:1.0"
        env:
        - name: "PORT"
          value: "8080"

Copiez le fichier manifeste dans un fichier nommé hello-kubernetes-deployment.yaml, puis créez le déploiement :

kubectl apply -f hello-kubernetes-deployment.yaml

Créer un deuxième service

Voici un manifeste pour un objet Service qui expose votre deuxième objet Déploiement :

apiVersion: v1
kind: Service
metadata:
  name: hello-kubernetes
spec:
  type: NodePort
  selector:
    greeting: hello
    department: kubernetes
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Pour les besoins de cet exercice, voici les points importants à noter à propos de l'objet Service :

  • Tous les pods comportant les étiquettes greeting: hello et department: kubernetes sont membres du service.

  • Lorsqu'une requête est envoyée à l'objet Service sur le port TCP 80, elle est transférée à l'un des pods membres sur le port TCP 8080.

Copiez le fichier manifeste dans un fichier nommé hello-kubernetes-service.yaml, puis créez le service :

kubectl apply -f hello-kubernetes-service.yaml

Créer une Entrée

Voici un fichier manifeste d'Entrée :

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
            port:
              number: 60000
      - path: /kube
        pathType: ImplementationSpecific
        backend:
          service:
            name: hello-kubernetes
            port:
              number: 80

Pour les besoins de cet exercice, voici les points importants à retenir à propos du fichier manifeste d'Entrée :

  • Deux classes Ingress sont disponibles pour GKE Ingress. La classe gce déploie un équilibreur de charge externe et la classe gce-internal déploie un équilibreur de charge interne. Les ressources Ingress sans classe spécifiée ont par défaut la classe gce.

  • 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.

  • Le fichier manifeste de l'entrée possède deux paires (serviceName, servicePort). Chacune d'entre elles (serviceName, servicePort) est associée à un service de backend de Google Cloud.

  • Les seuls types de chemins compatibles avec le champ pathType sont ImplementationSpecific.

Copiez le manifeste dans un fichier nommé my-ingress.yaml et créez l'Ingress :

kubectl apply -f my-ingress.yaml

Lorsque vous créez l'entrée, le contrôleur d'entrée GKE crée un équilibreur de charge HTTP(S) externe et le configure comme suit :

  • Lorsqu'un client envoie une requête à l'équilibreur de charge avec le chemin d'URL /, la requête est transmise au service hello-world sur le port 60000.

  • Lorsqu'un client envoie une requête à l'équilibreur de charge à l'aide du chemin d'URL /kube, la requête est transmise au service hello-kubernetes sur le port 80.

Attendez environ cinq minutes que l'équilibreur de charge soit configuré.

Tester l'équilibreur de charge HTTP(S) externe

Pour tester l'équilibreur de charge HTTP(S) externe, procédez comme suit :

  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 HTTP(S) externe :

    status:
      loadBalancer:
        ingress:
        - ip: 203.0.113.1
    
  2. Testez le chemin / :

    curl load-balancer-ip/
    

    Remplacez load-balancer-ip par l'adresse IP externe de votre équilibreur de charge.

    Le résultat affiche un message Hello, world! :

    Hello, world!
    Version: 2.0.0
    Hostname: ...
    
  3. Testez le chemin /kube :

    curl load-balancer-ip/kube
    

    Le résultat affiche un message Hello Kubernetes! :

    Hello Kubernetes!
    

HTTPS entre le client et l'équilibreur de charge

Un équilibreur de charge HTTP(S) 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 :

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 Vous pouvez importer des certificats et des clés dans votre projet Google Cloud. Utilisez cette annotation pour référencer les certificats et les clés. Voir Utiliser plusieurs certificats SSL dans l'équilibrage de charge HTTP(S).
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 Fonctionnalités Ingress.
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
service.alpha.kubernetes.io/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 HTTP/2. Consultez les sections HTTPS entre l'équilibreur de charge et votre application et HTTP/2 pour l'équilibrage de charge avec l'objet Ingress.
beta.cloud.google.com/backend-config Utilisez cette annotation pour configurer le service de backend associé à un servicePort. Pour en savoir plus, consultez la page Fonctionnalités Ingress.
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.

Étape suivante