Configurer l'équilibrage de charge HTTP(S) avec la ressource d'entrée

Ce tutoriel explique comment exécuter une application Web derrière un équilibreur de charge HTTP(S) externe en configurant la ressource d'entrée (Ingress).

Contexte

Google Kubernetes Engine (GKE) propose deux types d'équilibrage Cloud Load Balancing intégrés pour une application accessible au public :

  • Vous pouvez demander à GKE de créer un service de type LoadBalancer en spécifiant type:LoadBalancer sur le fichier manifeste de la ressource. GKE effectue les appels d'API Google Cloud requis pour créer un équilibreur de charge réseau externe ou un équilibreur de charge TCP/UDP interne. GKE crée un équilibreur de charge TCP/UDP interne si vous ajoutez l'annotation cloud.google.com/load-balancer-type: "Internal". Sinon, il crée un équilibreur de charge réseau externe.

    Bien que ces deux types d'équilibrage de charge fonctionnent avec le trafic HTTP(S), ils opèrent dans les couches 3 et 4 du modèle OSI et ne sont pas informés des connexions HTTP ou des requêtes et réponses HTTP individuelles. En outre, notez bien que les requêtes ne sont pas transmises par proxy à la destination.

  • Vous pouvez demander à GKE de créer une ressource Ingress en spécifiant kind:Ingress sur le fichier manifeste de la ressource. Si vous incluez des annotations, des charges de travail d'accompagnement et des services, vous pouvez créer un contrôleur d'entrée personnalisé. Sinon, GKE effectue les appels d'API Google Cloud requis pour créer un équilibreur de charge externe HTTP(S). Les règles d'hôte et les outils de mise en correspondance des chemins d'accès du mappage d'URL pour le répartiteur de charges font référence à un ou plusieurs services de backend, où chaque service de backend correspond à un service GKE de type NodePort, comme indiqué dans le Ingress. Les backends de chaque service de backend sont des groupes d'instances ou des groupes de points de terminaison de réseau (NEG). Les NEG sont créés lorsque vous configurez l'équilibrage de charge natif en conteneurs dans le cadre de la configuration de votre ressource Ingress. Pour chaque service de backend, GKE crée une vérification de l'état Google Cloud, qui dépend des paramètres de vérification de l'aptitude de la charge de travail auxquels le service GKE correspondant fait référence.

    Si vous exposez un service HTTP(S) hébergé sur GKE, l'équilibrage de charge HTTP(S) est la méthode d'équilibrage de charge recommandée.

Objectifs

  • Créer un cluster GKE
  • Déployer l'exemple d'application Web sur le cluster.
  • Exposer l'exemple d'application sur Internet derrière un équilibreur de charge HTTP(S) externe.

Avant de commencer

Pour activer l'API Kubernetes Engine, procédez comme suit :
  1. Accédez à la page Kubernetes Engine dans Google Cloud Console.
  2. Créez ou sélectionnez un projet.
  3. Patientez le temps de l'activation de l'API et des services associés. Cette opération peut prendre plusieurs minutes.
  4. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

Installez les outils de ligne de commande suivants utilisés dans ce tutoriel :

  • gcloud permet de créer et de supprimer des clusters Kubernetes Engine. gcloud est inclus dans le SDK Google Cloud.
  • kubectl permet de gérer Kubernetes, le système d'orchestration de clusters utilisé par Kubernetes Engine. Vous pouvez installer kubectl avec gcloud :
    gcloud components install kubectl

Clonez l'exemple de code depuis GitHub :

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd kubernetes-engine-samples/load-balancing

Définir des valeurs par défaut pour l'outil de ligne de commande gcloud

Pour gagner du temps lors de la saisie de vos options d'ID de projet et de zone Compute Engine dans l'outil de ligne de commande gcloud, vous pouvez définir les valeurs par défaut suivantes :
gcloud config set project project-id
gcloud config set compute/zone compute-zone

Créer un cluster de conteneur

Créez un cluster de conteneurs nommé loadbalancedcluster en exécutant la commande suivante :

gcloud container clusters create loadbalancedcluster

Déployer une application Web

Le fichier manifeste suivant décrit un déploiement qui exécute l'exemple d'image de conteneur d'application Web sur un serveur HTTP sur le port 8080 :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
spec:
  selector:
    matchLabels:
      run: web
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:1.0
        imagePullPolicy: IfNotPresent
        name: web
        ports:
        - containerPort: 8080
          protocol: TCP

Appliquez la ressource au cluster :

kubectl apply -f web-deployment.yaml

Exposer votre déploiement dans votre cluster

Le fichier manifeste suivant décrit un service qui rend le déploiement web accessible depuis votre cluster de conteneurs :

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web
  type: NodePort
  1. Appliquez la ressource au cluster :

    kubectl apply -f web-service.yaml
    

    Lorsque vous créez un service de type NodePort avec cette commande, GKE le lance sur un port aléatoire élevé (par exemple, 32640), et ce, sur tous les nœuds du cluster.

  2. Vérifiez que le service est créé et qu'un port de nœud est attribué :

    kubectl get service web
    
    Sortie :
    NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
    web       NodePort   10.35.245.219   <none>        8080:32640/TCP   5m
    

    Dans l'exemple de résultat ci-dessus, le port de nœud du service web est 32640. Notez également qu’aucune adresse IP externe n’est attribuée à ce service. Les nœuds GKE n'étant pas accessibles en externe par défaut, la création de ce service ne rend pas votre application accessible depuis Internet.

Pour rendre votre application de serveur Web HTTP(S) publiquement accessible, vous devez créer une ressource Ingress.

Créer une ressource Ingress

Entrée est une ressource Kubernetes qui regroupe tout un ensemble de règles et de configurations servant à rediriger le trafic HTTP(S) externe vers des services internes.

Sur GKE, la ressource Entrée est intégrée à l'aide de Cloud Load Balancing. Lorsque vous créez une ressource Ingress dans votre cluster, GKE crée un équilibreur de charge HTTP(S) et le configure pour acheminer le trafic vers votre application.

L'objet Kubernetes Entrée est une ressource bêta, ce qui signifie que sa description est susceptible d'évoluer. Les équilibreurs de charge cloud, quant à eux, sont définis dans GKE pour intégrer la ressource Ingress et sont prêts pour la production.

Le fichier manifeste suivant décrit une ressource Ingress qui dirige le trafic vers votre service web :

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  backend:
    serviceName: web
    servicePort: 8080

Appliquez la ressource au cluster :

kubectl apply -f basic-ingress.yaml

Lorsque vous déployez ce fichier manifeste, Kubernetes crée une ressource Ingress sur votre cluster. Le contrôleur d'entrée GKE crée et configure un équilibreur de charge HTTP(S) en fonction des informations de la ressource Ingress, en acheminant tout le trafic HTTP externe (sur le port 80) vers le service NodePort web que vous avez exposé.

Accéder à votre application

Trouvez l'adresse IP externe de l'équilibreur de charge desservant votre application en exécutant la commande suivante :

kubectl get ingress basic-ingress
Sortie :
NAME            HOSTS     ADDRESS         PORTS     AGE
basic-ingress   *         203.0.113.12    80        2m

Ouvrez l'adresse IP externe de votre application dans un navigateur et affichez une réponse HTTP en texte brut comme suit :

Hello, world!
Version: 1.0.0
Hostname: web-6498765b79-fq5q5

Vous pouvez accéder à l'équilibrage de charge sur Cloud Console pour inspecter les ressources réseau créées par le contrôleur GKE Ingress.

(Facultatif) Configurer une adresse IP statique

Lorsque vous exposez un serveur Web sur un nom de domaine, l'adresse IP externe d'une application doit être une adresse IP statique qui ne change pas.

Par défaut, GKE attribue des adresses IP externes éphémères aux applications HTTP exposées via une ressource Ingress. Les adresses éphémères sont susceptibles de changer. Si vous prévoyez d'exécuter votre application pendant une longue période, vous devez utiliser une adresse IP statique externe.

Notez qu'une fois que vous avez configuré une adresse IP statique pour la ressource Ingress, la suppression de cette dernière ne supprime pas l'adresse IP statique qui lui est associée. Assurez-vous d'effectuer un nettoyage des adresses IP statiques que vous avez configurées lorsque vous ne prévoyez plus de les réutiliser.

Pour configurer une adresse IP statique, procédez comme suit :

  1. Réservez une adresse IP externe statique nommée web-static-ip :

    gcloud

    gcloud compute addresses create web-static-ip --global
    

    Config Connector

    Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

    apiVersion: compute.cnrm.cloud.google.com/v1beta1
    kind: ComputeAddress
    metadata:
      name: web-static-ip
    spec:
      location: global
    Pour déployer ce manifeste, téléchargez le fichier sur votre ordinateur sous le nom "compute-address.yaml", puis exécutez la commande suivante :
    kubectl apply -f compute-address.yaml

  2. Le fichier manifeste basic-ingress-static.yaml ajoute une annotation sur la ressource Ingress pour utiliser la ressource d'adresse IP statique nommée web-static-ip :

    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    metadata:
      name: basic-ingress
      annotations:
        kubernetes.io/ingress.global-static-ip-name: "web-static-ip"
    spec:
      backend:
        serviceName: web
        servicePort: 8080
    

    Affichez le fichier manifeste :

    cat basic-ingress-static.yaml
    
  3. Appliquez la ressource au cluster :

    kubectl apply -f basic-ingress-static.yaml
    
  4. Vérifiez l'adresse IP externe :

    kubectl get ingress basic-ingress
    

    Attendez que l'adresse IP de votre application change pour utiliser l'adresse IP réservée de la ressource web-static-ip.

    La mise à jour de la ressource Ingress existante, la reconfiguration de l'équilibreur de charge et la propagation des règles d'équilibrage de charge dans le réseau mondial peuvent prendre quelques minutes. Une fois cette opération terminée, le GKE libère l'adresse IP éphémère précédemment attribuée à l'application.

(Facultatif) Diffuser plusieurs applications sur un équilibreur de charge

Vous pouvez exécuter plusieurs services sur un même équilibreur de charge et sur une adresse IP publique en configurant des règles de routage sur la ressource Ingress. En hébergeant plusieurs services sur la même ressource Ingress, vous évitez de créer des équilibreurs de charge supplémentaires (qui sont des ressources facturables) pour chaque service exposé à Internet.

Le fichier manifeste suivant décrit un déploiement avec la version 2.0 de la même application Web :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web2
  namespace: default
spec:
  selector:
    matchLabels:
      run: web2
  template:
    metadata:
      labels:
        run: web2
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:2.0
        imagePullPolicy: IfNotPresent
        name: web2
        ports:
        - containerPort: 8080
          protocol: TCP

Appliquez la ressource au cluster :

kubectl apply -f web-deployment-v2.yaml

Le fichier manifeste suivant décrit un service qui expose web2 en interne au cluster sur un service NodePort appelé web2 :

apiVersion: v1
kind: Service
metadata:
  name: web2
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web2
  type: NodePort

Appliquez la ressource au cluster :

kubectl apply -f web-service-v2.yaml

Le fichier manifeste suivant décrit une ressource Ingress qui :

  • achemine les requêtes dont le chemin d'accès commence par /v2/ vers le service web2 ;
  • achemine toutes les autres requêtes vers le service web.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: fanout-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: web
          servicePort: 8080
      - path: /v2/*
        backend:
          serviceName: web2
          servicePort: 8080

Appliquez la ressource au cluster :

kubectl create -f fanout-ingress.yaml

Une fois la ressource Ingress déployée, exécutez la commande kubectl get ingress fanout-ingress pour connaître l'adresse IP publique du cluster.

Accédez ensuite à l'adresse IP pour vérifier que les deux applications sont accessibles sur le même équilibreur de charge :

  • Accédez à http://<IP_ADDRESS>/ et vérifiez que la réponse contient Version: 1.0.0 (la requête étant acheminée vers le service web).
  • Accédez à http://<IP_ADDRESS>/v2/ et vérifiez que la réponse contient Version: 2.0.0 (la demande étant acheminée vers le service web2).

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.

(Facultatif) Surveiller la disponibilité et la latence de votre service

Les tests de disponibilité de Google Cloud surveillent les applications par boîte noire et du point de vue de l'utilisateur, en déterminant la latence et la disponibilité entre plusieurs adresses IP externes et l'adresse IP de l'équilibreur de charge. En comparaison, les vérifications d'état de Google Cloud effectuent une vérification interne des adresses IP du pod afin de déterminer la disponibilité au niveau de l'instance. Ces vérifications sont complémentaires et offrent une vue globale de l'état de l'application.

Vous pouvez créer un test de disponibilité à l'aide de Google Cloud Console, de l'API Cloud Monitoring ou des bibliothèques clientes Cloud Monitoring. Pour en savoir plus, consultez la page Gérer les tests de disponibilité. Si vous souhaitez créer un test de disponibilité à l'aide de Google Cloud Console, procédez comme suit :

  1. Dans Google Cloud Console, sélectionnez Surveillance ou cliquez sur le bouton suivant :

    Accéder à Monitoring

  2. Dans le volet de navigation Surveillance, sélectionnez Tests de disponibilité, puis cliquez sur Créer un test de disponibilité.

  3. Définissez les champs suivants de la cible de votre test de disponibilité :

    • Pour "Type de protocole", sélectionnez TCP.
    • Pour Type de ressource, sélectionnez URL.
    • Pour le champ Nom d'hôte, saisissez l'adresse IP de l'équilibreur de charge.
    • Pour le champ Port, saisissez le numéro de port de l'équilibreur de charge.

    Pour accéder à une documentation complète sur tous les champs d'un test de disponibilité, consultez la section Créer un test de disponibilité.

Pour surveiller un test de disponibilité, vous pouvez créer une règle d'alerte ou afficher le tableau de bord des tests de disponibilité. Les règles d'alerte vous permettent d'être averti par e-mail ou via un autre canal en cas d'échec de votre test de disponibilité. Pour obtenir des informations générales sur les règles d'alerte, consultez la page Présentation des alertes.

.

Remarques

Par défaut, la ressource Ingress effectue une vérification de l'état périodique à l'aide de la requête GET sur le chemin / pour déterminer l'intégrité de l'application. Elle attend une réponse HTTP 200. Utilisez un chemin de vérification de l'état personnalisé pour vérifier un chemin différent ou attendre un code de réponse différent.

L'entrée peut être utilisée dans le cadre de cas d'utilisation plus avancés, par exemple :

  • Hébergement virtuel basé sur le nom : vous pouvez utiliser la ressource Ingress afin de réutiliser l'équilibreur de charge pour plusieurs noms de domaine et sous-domaines, et pour exposer plusieurs services sur une adresse IP unique et un seul équilibreur de charge. Consultez les exemples de fan-out simple et d'hébergement virtuel basé sur le nom pour apprendre à configurer la ressource Ingress pour ces tâches.

  • Terminaison HTTPS : vous pouvez configurer la ressource Ingress pour qu'elle mette fin au trafic HTTPS à l'aide de l'équilibreur de charge Google Cloud.

Lorsqu'une ressource Ingress est supprimée, le contrôleur GKE Ingress effectue un nettoyage automatique des ressources associées (à l'exception des adresses IP statiques réservées).

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et les ressources individuelles.

  1. Supprimez toutes les règles de transfert et les proxys cibles créés manuellement et faisant référence à l'Ingress :

    Un proxy cible dingling référençant un mappage d'URL géré par le contrôleur GKE Ingress entraîne la suppression de l'entrée dans les versions GKE 1.15.4-gke.22 et ultérieures. Inspectez la ressource Ingress pour rechercher un événement avec un message d'erreur semblable à celui-ci :

     Error during GC: error running load balancer garbage collection routine: googleapi: Error 400: The url_map resource 'projects/project-id/global/urlMaps/k8s2-um-tlw9rhgp-default-my-ingress-9ifnni82' is already being used by 'projects/project-id/global/targetHttpsProxies/k8s2-um-tlw9rhgp-default-my82-target-proxy', resourceInUseByAnotherResource
     

    Dans l'exemple de message d'erreur ci-dessus, k8s2-um-tlw9rhgp-default-my82-target-proxy est un proxy HTTPS cible créé manuellement, qui référence toujours le mappage d'URL k8s2-um-tlw9rhgp-default-my-ingress-9ifnni82 qui a été créé et géré par un contrôleur Ingress.

    Ces ressources de frontend créées manuellement (la règle de transfert et le proxy cible) doivent être supprimées avant de procéder à la suppression de la ressource Ingress.

  2. Supprimer la ressource Ingress : cette étape désaffecte l'adresse IP externe éphémère et les ressources d'équilibrage de charge associées à l'application :

    kubectl delete ingress basic-ingress

    Si vous avez suivi l'étape facultative de création d'une ressource Ingress pour acheminer les requêtes par chemin, supprimez-la :

    kubectl delete ingress fanout-ingress

  3. Supprimer l'adresse IP statique : n'effectuez cette étape que si vous avez suivi l'étape facultative de création d'une adresse IP statique.

    • Si vous avez suivi l'option 1 pour convertir une adresse IP éphémère existante en une adresse IP statique, accédez à Cloud Console pour supprimer l'adresse IP statique.

    • Si vous avez suivi l'option 2 pour créer une adresse IP statique, exécutez la commande suivante pour supprimer l'adresse IP statique :

      gcloud compute addresses delete web-static-ip --global
  4. Supprimer le cluster : cette étape supprime les nœuds de calcul du cluster de conteneurs ainsi que d'autres ressources telles que les objets Déploiement situés dans le cluster :

    gcloud container clusters delete loadbalancedcluster

Étape suivante