De la périphérie au réseau : Exposer les applications de maillage de services via GKE Ingress

Ce tutoriel explique comment combiner Anthos Service Mesh à Cloud Load Balancing pour exposer les applications d'un maillage de services à des clients Internet.

Anthos Service Mesh est un maillage de services géré, basé sur Istio, qui fournit une couche de communication observable, standardisée et à la sécurité renforcée pour les applications. Que vous utilisiez Anthos Service Mesh, Traffic Director ou Istio, un maillage de services fournit une plate-forme de communication globale pour les clients qui communiquent via le maillage. Toutefois, il reste un défi à relever pour connecter des clients situés en dehors du maillage à des applications hébergées dans le maillage.

Vous pouvez exposer une application à des clients de différentes manières selon l'emplacement des clients. Ce tutoriel explique comment exposer une application à des clients en associant Cloud Load Balancing à Anthos Service Mesh afin d'intégrer des équilibreurs de charge à un maillage de services. Ce tutoriel s'adresse aux professionnels avancés qui utilisent Anthos Service Mesh, mais il fonctionne également pour Istio sur Google Kubernetes Engine.

Passerelle d'entrée du réseau maillé

Istio 0.8 a introduit la passerelle d'entrée du maillage, qui fournit un ensemble dédié de proxys dont les ports sont exposés au trafic provenant de l'extérieur du maillage de services. Ces proxys d'entrée du maillage vous permettent de contrôler le comportement d'exposition de la couche 4 séparément du comportement de routage des applications. Les proxys vous permettent également d'appliquer le routage et la règle au trafic externe au réseau maillé avant qu'il n'atteigne un side-car d'application. L'entrée de réseau maillé définit le traitement du trafic lorsqu'il atteint un nœud du maillage, mais les composants externes doivent définir la façon dont le trafic arrive au maillage.

Pour gérer ce trafic externe, vous avez besoin d'un équilibreur de charge externe au maillage. Ce tutoriel utilise Google Cloud Load Balancing provisionné via des ressources GKE Ingress afin d'automatiser le déploiement. L'exemple canonique de cette configuration est un service d'équilibrage de charge externe qui, dans le cas de Google Cloud, déploie un équilibreur de charge TCP/UDP public. Cet équilibreur de charge pointe vers les NodePorts d'un cluster GKE. Ces NodePorts exposent les pods de passerelle d'entrée Istio, qui acheminent le trafic vers les proxys side-car du réseau maillé en aval. Le schéma suivant illustre cette topologie. L'équilibrage de charge pour le trafic privé interne ressemble à cette architecture, à la différence que vous déployez un équilibreur de charge TCP/UDP interne à la place.

Un équilibreur de charge externe achemine les clients externes vers le maillage via des proxys de passerelle d'entrée.

L'utilisation de l'équilibrage de charge transparent de couche 4 avec une passerelle d'entrée du réseau maillé offre les avantages suivants :

  • Cette configuration simplifie le déploiement de l'équilibreur de charge.
  • L'équilibreur de charge fournit une adresse IP virtuelle (VIP) stable, une vérification d'état et une répartition du trafic fiable en cas de modifications du cluster, d'interruptions de nœud ou de pannes de processus.
  • Toutes les règles de routage, l'arrêt TLS et la règle de trafic sont gérés de façon centralisée dans la passerelle d'entrée du maillage.

GKE Ingress et services

Il existe de nombreuses façons d'accorder l'accès aux applications aux clients situés en dehors du cluster. Le tableau suivant répertorie les primitives Kubernetes disponibles pour le déploiement d'équilibreurs de charge sur Google Cloud. Le type d'équilibreur de charge que vous utilisez pour exposer les applications aux clients dépend principalement du type de client externe ou interne, du type de compatibilité de protocole requis et de la disponibilité du maillage de services sur plusieurs clusters GKE ou sur un seul cluster.

Tous les types d'équilibreurs de charge figurant dans le tableau suivant peuvent exposer les applications hébergées sur un réseau maillé, en fonction du cas d'utilisation.

Ressource GKE Équilibreur de charge basé sur le cloud Caractéristiques
Ingress pour l'équilibrage de charge HTTP(S) externe Équilibreur de charge HTTP(S) externe

Proxys de couche 7 dans les points de présence périphériques (PoP) de Google

Adresse IP virtuelle publique

À l'échelle globale

Cluster unique

Ingress pour l'équilibrage de charge HTTP(S) interne Équilibreur de charge HTTP(S) interne

Proxys de couche 7 dans un réseau de cloud privé virtuel (VPC)

Adresse IP virtuelle privée

À l'échelle de la région

Cluster unique

Service externe LoadBalancer Équilibreur de charge TCP/UDP externe

Direct de la couche 4 aux PoP de Google

Adresse IP virtuelle publique

À l'échelle de la région

Cluster unique

Service LoadBalancer interne Équilibreur de charge TCP/UDP interne

Direct de la couche 4 au réseau de routage VPC

Adresse IP virtuelle privée

À l'échelle de la région

Cluster unique

Ingress multicluster (entrée multicluster externe) Équilibreur de charge HTTP(S) externe

Proxys de couche 7 dans les PoP de Google

Adresse IP virtuelle publique

À l'échelle globale

Multicluster

Bien que l'équilibreur de charge par défaut pour Anthos Service Mesh soit l'équilibreur de charge TCP/UDP externe, ce tutoriel se concentre sur l'équilibreur de charge HTTP(S) externe que vous déployez à l'aide de l'équilibrage de charge HTTP(S) externe. L'équilibreur de charge HTTP(S) externe fournit une intégration avec des services de périphérie tels que Identity-Aware Proxy (IAP), Google Cloud Armor et Cloud CDN, ainsi qu'un réseau distribué de proxys de périphérie à l'échelle mondiale. La section suivante décrit l'architecture et les avantages liés à l'utilisation de deux couches d'équilibrage de charge HTTP.

Entrée cloud et entrée du réseau maillé

Le déploiement de l'équilibrage de charge de couche 7 externe en dehors du maillage avec une couche d'entrée du maillage offre des avantages considérables, en particulier pour le trafic Internet. Même si Anthos Service Mesh et les passerelles d'entrée Istio fournissent un routage et une gestion de trafic avancés dans le maillage, certaines fonctions sont mieux adaptées à la périphérie du réseau. L'utilisation de la mise en réseau en périphérie d'Internet via l'équilibrage de charge HTTP(S) externe de Google Cloud peut offrir des avantages significatifs en termes de performances, de fiabilité ou de sécurité par rapport à une entrée basée sur le maillage. En voici quelques exemples :

Cette couche externe de l'équilibrage de charge de couche 7 est appelée entrée cloud, car elle est basée sur des équilibreurs de charge gérés par le cloud et non sur les proxys auto-hébergés utilisés par l'entrée de maillage. La combinaison de l'entrée cloud et de l'entrée de maillage utilise les fonctionnalités complémentaires de l'infrastructure Google Cloud et du maillage. Le schéma suivant montre comment associer l'entrée cloud et l'entrée de maillage afin de créer deux couches d'équilibrage de charge pour le trafic Internet.

L'entrée cloud fait office de passerelle pour le trafic externe vers le maillage via le réseau VPC.

Dans cette topologie, la couche d'entrée cloud récupère le trafic depuis l'extérieur du maillage de services et le dirige vers la couche d'entrée du maillage. La couche d'entrée du maillage dirige ensuite le trafic vers les backends d'application hébergés par le maillage.

Topologie d'entrée dans le cloud et dans le réseau maillé

Cette section décrit les rôles complémentaires de chaque couche d'entrée lorsque vous les utilisez conjointement. Ces rôles ne constituent pas des règles concrètes mais plutôt des consignes qui permettent d'exploiter au mieux les avantages de chaque couche. Il existe probablement des variantes de ce modèle, en fonction de votre cas d'utilisation.

  • Entrée cloud. Lorsqu'elle est associée à une entrée de maillage, la couche d'entrée cloud est mieux adaptée à la sécurité périphérique et à l'équilibrage de charge global. Étant donné que la couche d'entrée cloud bénéficie de fonctions intégrées pour la protection contre les attaques DDoS, les pare-feu cloud, l'authentification et les produits de chiffrement en périphérie, cette couche excelle dans l'exécution de ces services en dehors du maillage. La logique de routage est généralement simple à ce niveau, mais elle peut devenir plus complexe pour les environnements multicluster et multirégionaux. En raison de la fonction essentielle des équilibreurs de charge Internet, la couche d'entrée cloud est souvent gérée par une équipe chargée de l'infrastructure qui dispose d'un contrôle exclusif sur l'exposition et la sécurité des applications sur Internet. Ce contrôle rend cette couche moins flexible et dynamique qu'une infrastructure axée sur le développeur, ce qui peut influer sur les personnes auxquelles vous choisissez d'accorder un accès administrateur et sur la manière dont vous procédez pour accorder un tel accès.
  • Entrée de réseau maillé Lorsqu'elle est associée à un objet d'entrée cloud, la couche d'entrée du maillage permet un routage flexible proche de l'application. En raison de sa flexibilité, l'entrée de maillage est préférable à l'entrée cloud pour une logique de routage complexe et pour une visibilité au niveau de l'application. La séparation entre les couches d'entrée permet également aux propriétaires d'applications de contrôler directement cette couche sans affecter les autres équipes. Lorsque vous exposez des applications de maillage de services via un équilibreur de charge de niveau 4 au lieu d'un équilibreur de charge de niveau 7, vous devez interrompre le protocole TLS client sur la couche d'entrée du maillage au sein du maillage afin de sécuriser les applications.

Vérification de l'état

La vérification de l'état peut être compliquée lorsque vous utilisez deux couches d'équilibrage de charge de couche 7. Vous devez configurer chaque équilibreur de charge pour qu'il vérifie l'état de la couche suivante afin de garantir la réception du trafic. La topologie du schéma suivant montre comment l'entrée cloud vérifie l'état des proxys d'entrée du maillage et comment le maillage, en retour, vérifie l'état des backends d'application.

Le contrôleur d'entrée cloud vérifie l'état de l'entrée du maillage, tandis que l'entrée de maillage vérifie l'état des backends de l'application.

Cette topologie implique les considérations suivantes :

  • Entrée cloud. Dans ce tutoriel, vous allez configurer l'équilibreur de charge Google Cloud via une entrée pour qu'il vérifie l'état des proxys d'entrée du maillage sur leurs ports de vérification d'état exposés. Si un proxy de réseau maillé est indisponible, ou si le cluster, le maillage ou la région n'est pas disponible, l'équilibreur de charge de Google Cloud détecte cette condition et n'envoie pas de trafic au proxy de réseau maillé.
  • Entrée de réseau maillé Dans l'application de maillage, vous effectuez directement les vérifications de l'état des backends afin de pouvoir exécuter l'équilibrage de charge et gérer le trafic localement.

Sécurité

La topologie précédente implique plusieurs éléments de sécurité. L'un des éléments les plus critiques concerne la configuration du chiffrement et du déploiement des certificats. Ingress pour l'équilibrage de charge HTTP(S) externe s'intègre parfaitement aux certificats gérés par Google. Cette intégration provisionne automatiquement les certificats publics, les associe à un équilibreur de charge, puis renouvelle et effectue la rotation des certificats via l'interface GKE Ingress déclarative. Les clients Internet s'authentifient auprès des certificats publics et se connectent à l'équilibreur de charge externe en tant que premier saut dans le cloud privé virtuel (VPC).

Le saut suivant, situé entre Google Front End (GFE) et le proxy d'entrée du maillage, est chiffré par défaut. Le chiffrement au niveau du réseau entre les GFE et leurs backends est appliqué automatiquement. Toutefois, si vos exigences de sécurité impliquent que le propriétaire de la plate-forme conserve la propriété des clés de chiffrement, vous pouvez activer HTTPS/2 avec chiffrement TLS entre l'entrée du cluster (GFE) et l'entrée de maillage (l'instance de proxy Envoy). Lorsque vous activez HTTP/2 avec le chiffrement TLS pour ce chemin d'accès, vous pouvez utiliser un certificat autosigné ou public pour chiffrer le trafic, car le GFE ne s'authentifie pas auprès de celui-ci. Cette couche de chiffrement supplémentaire est décrite dans ce guide. Pour éviter une mauvaise gestion des certificats, ne réutilisez pas le certificat public de l'équilibreur de charge public à un autre endroit. Nous vous recommandons plutôt d'utiliser des certificats distincts dans le maillage de services.

Si le maillage de services exige l'utilisation du protocole TLS, tout le trafic est chiffré entre les proxys side-car et l'entrée de maillage. Le schéma suivant illustre le chiffrement HTTPS du client vers l'équilibreur de charge Google Cloud, de l'équilibreur de charge vers le proxy d'entrée du maillage, et du proxy d'entrée vers le proxy side-car.

La sécurité est mise en œuvre à l'aide de certificats gérés en dehors du réseau maillé et de certificats internes à l'intérieur du maillage.

Objectifs

  • Déployer un cluster Google Kubernetes Engine (GKE) sur Google Cloud.
  • Déployer un service Anthos Service Mesh basé sur Istio sur votre cluster GKE.
  • Configurer GKE Ingress pour arrêter le trafic HTTPS public et le diriger vers des applications hébergées par le maillage de services.
  • Déployer l'application Boutique en ligne sur le cluster GKE que vous exposez à des clients sur Internet.

Coûts

Ce tutoriel utilise les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

  1. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  2. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier si la facturation est activée sur un projet.

  3. Dans Cloud Console, activez Cloud Shell.

    Activer Cloud Shell

    Vous exécutez toutes les commandes de terminal de ce tutoriel depuis Cloud Shell.

  4. Passez à la dernière version de Google Cloud CLI :

    gcloud components update
    
  5. Définissez votre projet Google Cloud par défaut :

    export PROJECT=$(gcloud info --format='value(config.project)')
    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
    gcloud config set project ${PROJECT}
    
  6. Créez un répertoire de travail :

    mkdir -p ${HOME}/edge-to-mesh
    cd ${HOME}/edge-to-mesh
    export WORKDIR=`pwd`
    

    Une fois le tutoriel terminé, vous pouvez supprimer le répertoire de travail.

Créer des clusters GKE

Les fonctionnalités décrites dans ce tutoriel nécessitent un cluster GKE version 1.16 ou ultérieure.

  1. Dans Cloud Shell, créez un fichier kubeconfig. Cette étape vous permet de ne pas créer de conflit avec votre fichier kubeconfig (par défaut) existant.

    touch edge2mesh_kubeconfig
    export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig
    
  2. Définissez des variables d'environnement pour le cluster GKE :

    export CLUSTER_NAME=edge-to-mesh
    export CLUSTER_LOCATION=us-west1-a
    
  3. Activez l'API Google Kubernetes Engine.

    gcloud services enable container.googleapis.com
    
  4. Créer un cluster GKE

    gcloud container clusters create ${CLUSTER_NAME} \
        --machine-type=e2-standard-4 \
        --num-nodes=4 \
        --zone ${CLUSTER_LOCATION} \
        --enable-ip-alias \
        --workload-pool=${PROJECT}.svc.id.goog \
        --release-channel rapid \
        --addons HttpLoadBalancing \
        --labels mesh_id=proj-${PROJECT_NUMBER}
    

    Pour utiliser une entrée cloud, vous devez activer le module complémentaire d'équilibrage de charge HTTP. L'équilibrage de charge HTTP est activé par défaut sur les clusters GKE. Vous ne devez pas le désactiver.

    Pour utiliser Anthos Service Mesh géré, vous devez appliquer le libellé mesh_id sur le cluster.

  5. Assurez-vous que le cluster est en cours d'exécution :

    gcloud container clusters list
    

    Le résultat ressemble à ce qui suit :

    NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
    edge-to-mesh  us-west1-a  v1.22.6-gke.300   35.233.195.59  e2-standard-4  v1.22.6-gke.300   4          RUNNING
    
  6. Connectez-vous au cluster :

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
        --zone ${CLUSTER_LOCATION} \
        --project ${PROJECT}
    

Installer un maillage de services

Dans cette section, vous configurez le service Anthos Service Mesh géré avec l'API Fleet.

  1. Activez les API requises :

    gcloud services enable \
        gkehub.googleapis.com \
        mesh.googleapis.com
    

    En outre, si vous souhaitez utiliser les fonctionnalités Anthos Service Mesh dans Google Cloud Console, vous devez activer l'API anthos.googleapis.com. L'activation de cette API modifie la tarification d'Anthos Service Mesh en la faisant passer de manière autonome à Anthos.

  2. Activez Anthos Service Mesh dans le parc :

    gcloud container fleet mesh enable
    
  3. Enregistrez le cluster dans le parc :

    gcloud container fleet memberships register ${CLUSTER_NAME} \
        --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME} \
        --enable-workload-identity
    
  4. Activez la gestion automatique du plan de contrôle :

    gcloud container fleet mesh update \
        --control-plane automatic \
        --memberships ${CLUSTER_NAME}
    
  5. Après quelques minutes, vérifiez que l'état du plan de contrôle est ACTIVE :

    gcloud container fleet mesh describe
    

    Le résultat ressemble à ce qui suit :

    ...
    membershipSpecs:
      projects/746296320118/locations/global/memberships/edge-to-mesh:
        mesh:
          controlPlane: AUTOMATIC
    membershipStates:
      projects/746296320118/locations/global/memberships/edge-to-mesh:
        servicemesh:
          controlPlaneManagement:
            details:
            - code: REVISION_READY
              details: 'Ready: asm-managed-rapid'
            state: ACTIVE
        state:
          code: OK
          description: |-
            Revision(s) ready for use: asm-managed-rapid.
            All Canonical Services have been reconciled successfully.
          updateTime: '2022-03-09T02:47:51.187247972Z'
    name: projects/your-project/locations/global/features/servicemesh
    resourceState:
      state: ACTIVE
    ...
    

Déployer GKE Ingress

Dans les étapes suivantes, vous allez déployer l'équilibreur de charge HTTP(S) externe via le contrôleur GKE Ingress. La ressource Ingress automatise le provisionnement de l'équilibreur de charge, de ses certificats TLS et de la vérification de l'état du backend. De plus, vous utilisez Cloud Endpoints pour provisionner automatiquement un nom DNS public pour l'application.

Installer une passerelle d'entrée

Pour des raisons de sécurité, nous vous recommandons de déployer la passerelle d'entrée dans un espace de noms différent du plan de contrôle.

  1. Dans Cloud Shell, créez un espace de noms asm-ingress dédié :

    kubectl create namespace asm-ingress
    
  2. Ajoutez un libellé d'espace de noms à l'espace de noms asm-ingress :

    kubectl label namespace asm-ingress istio-injection=enabled
    

    Le résultat ressemble à ce qui suit :

    namespace/asm-ingress labeled
    

    L'ajout d'un libellé istio-injection=enabled à l'espace de noms asm-ingress indique à Anthos Service Mesh d'injecter automatiquement des proxys side-car Envoy lors du déploiement d'une application.

  3. Exécutez la commande suivante pour créer le fichier manifeste Deployment en tant que ingress-deployment.yaml :

    cat <<EOF > ingress-deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
    spec:
      selector:
        matchLabels:
          asm: ingressgateway
      template:
        metadata:
          annotations:
            # This is required to tell Anthos Service Mesh to inject the gateway with the
            # required configuration.
            inject.istio.io/templates: gateway
          labels:
            asm: ingressgateway
        spec:
          containers:
          - name: istio-proxy
            image: auto # The image will automatically update each time the pod starts.
            resources:
              limits:
                cpu: 2000m
                memory: 1024Mi
              requests:
                cpu: 100m
                memory: 128Mi
          serviceAccountName: asm-ingressgateway
    ---
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    metadata:
      name: asm-ingressgateway
    spec:
      maxReplicas: 5
      metrics:
      - resource:
          name: cpu
          targetAverageUtilization: 80
        type: Resource
      minReplicas: 3
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: asm-ingressgateway
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: asm-ingressgateway
    subjects:
      - kind: ServiceAccount
        name: asm-ingressgateway
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
    EOF
    

    Ce Deployment possède son propre ServiceAccount avec les éléments Role et RoleBinding associés, permettant à la passerelle d'accéder aux certificats.

  4. Déployez ingress-deployment.yaml dans votre cluster pour créer la ressource Deployment :

    kubectl apply -f ingress-deployment.yaml
    

    Le résultat ressemble à ce qui suit :

    deployment.apps/asm-ingressgateway configured
    role.rbac.authorization.k8s.io/asm-ingressgateway configured
    rolebinding.rbac.authorization.k8s.io/asm-ingressgateway configured
    serviceaccount/asm-ingressgateway created
    

    Assurez-vous que tous les déploiements sont opérationnels :

    kubectl wait --for=condition=available --timeout=600s deployment --all -n asm-ingress
    

    Le résultat ressemble à ce qui suit :

    deployment.apps/asm-ingressgateway condition met
    
  5. Exécutez la commande suivante pour créer le fichier manifeste Service en tant que ingress-service.yaml :

    cat <<EOF > ingress-service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
      annotations:
        cloud.google.com/neg: '{"ingress": true}'
        cloud.google.com/backend-config: '{"default": "ingress-backendconfig"}'
        cloud.google.com/app-protocols: '{"https":"HTTP2"}' # HTTP/2 with TLS encryption
      labels:
        asm: ingressgateway
    spec:
      ports:
      # status-port exposes a /healthz/ready endpoint that can be used with GKE Ingress health checks
      - name: status-port
        port: 15021
        protocol: TCP
        targetPort: 15021
      # Any ports exposed in Gateway resources should be exposed here.
      - name: http2
        port: 80
      - name: https
        port: 443
      selector:
        asm: ingressgateway
      type: ClusterIP
    EOF
    

    Ce Service comporte les annotations suivantes, qui définissent les paramètres de l'équilibreur de charge Ingress lors de son déploiement :

    • cloud.google.com/backend-config fait référence au nom d'une ressource personnalisée appelée BackendConfig. Le contrôleur Ingress utilise BackendConfig pour définir les paramètres de la ressource Google Cloud BackendService. Utilisez cette ressource à l'étape suivante pour définir des paramètres personnalisés de la vérification d'état de Google Cloud.
    • cloud.google.com/neg: '{"ingress": true}' active les backends Ingress (les proxys d'entrée du maillage, dans ce cas) pour l'équilibrage de charge natif en conteneurs. Pour un équilibrage de charge plus efficace et stable, ces backends utilisent des groupes de points de terminaison du réseau (NEG) plutôt que des groupes d'instances.
    • cloud.google.com/app-protocols: '{"https":"HTTP2"}' demande au GFE de se connecter à la passerelle d'entrée du maillage de services à l'aide de HTTP2 avec TLS, comme décrit dans les sections Entrée pour l'équilibrage de charge HTTP(S) externe et Présentation de l'équilibrage de charge HTTP(S) externe, qui fournit une couche de chiffrement supplémentaire.
  6. Déployez ingress-service.yaml dans votre cluster pour créer la ressource Service :

    kubectl apply -f ingress-service.yaml
    

    Le résultat ressemble à ce qui suit :

    service/asm-ingressgateway created
    

Appliquer les paramètres du service de backend

  1. Dans Cloud Shell, exécutez la commande suivante pour créer le fichier manifeste BackendConfig sous le nom ingress-backendconfig.yaml :

    cat <<EOF > ingress-backendconfig.yaml
    apiVersion: cloud.google.com/v1
    kind: BackendConfig
    metadata:
      name: ingress-backendconfig
      namespace: asm-ingress
    spec:
      healthCheck:
        requestPath: /healthz/ready
        port: 15021
        type: HTTP
      securityPolicy:
        name: edge-fw-policy
    EOF
    

    BackendConfig est une définition de ressource personnalisée (CRD, Custom Resource Definition) qui définit les paramètres du backend pour l'équilibrage de charge Ingress. Pour obtenir la liste complète des paramètres de backend et de frontend que vous pouvez configurer via une GKE Ingress, consultez la page Fonctionnalités Ingress.

    Dans ce tutoriel, le fichier manifeste BackendConfig spécifie des vérifications d'état personnalisées pour les proxys d'entrée du maillage. Anthos Service Mesh et Istio exposent leurs vérifications de l'état du proxy side-car sur le port 15021 au chemin /healthz/ready. Des paramètres de vérification d'état personnalisés sont requis, car le port de diffusion (443) des proxys d'entrée du réseau maillé est différent de celui de la vérification d'état (15021). GKE Ingress utilise les paramètres de vérification d'état suivants dans BackendConfig pour configurer les vérifications de l'état de l'équilibreur de charge Google Cloud. Il existe également une règle de sécurité qui protège le trafic de l'équilibrage de charge de différents types d'attaques de réseau.

    • healthCheck.port définit le port qui reçoit une vérification de l'état par l'équilibreur de charge Google Cloud sur l'adresse IP de chaque pod.
    • healthCheck.requestPath définit le chemin HTTP qui reçoit une vérification de l'état sur le port spécifié.
    • type définit le protocole de la vérification de l'état (dans le cas présent, HTTP).
    • securityPolicy.name fait référence au nom d'une règle de sécurité Cloud Armor.
  2. Déployez ingress-backendconfig.yaml dans votre cluster pour créer la ressource BackendConfig :

    kubectl apply -f ingress-backendconfig.yaml
    

    Le résultat ressemble à ce qui suit :

    backendconfig.cloud.google.com/ingress-backendconfig created
    

    Les paramètres BackendConfig et les annotations du service asm-ingressgateway ne sont appliqués à un équilibreur de charge Google Cloud qu'une fois la ressource Ingress déployée. Le déploiement Ingress associe toutes ces ressources.

Définir des règles de sécurité

Google Cloud Armor fournit une défense contre les attaques DDoS et des règles de sécurité personnalisables que vous pouvez associer à un équilibreur de charge via des ressources Ingress. Dans les étapes suivantes, vous créez une règle de sécurité qui utilise des règles préconfigurées pour bloquer les attaques de script intersites (XSS). Cette règle bloque le trafic correspondant aux signatures d'attaque connues, mais autorise tout autre trafic. Votre environnement peut utiliser des règles différentes en fonction de votre charge de travail.

  1. Dans Cloud Shell, créez une règle de sécurité appelée edge-fw-policy :

    gcloud compute security-policies create edge-fw-policy \
        --description "Block XSS attacks"
    
  2. Créez une règle de sécurité qui utilise les filtres XSS préconfigurés :

    gcloud compute security-policies rules create 1000 \
        --security-policy edge-fw-policy \
        --expression "evaluatePreconfiguredExpr('xss-stable')" \
        --action "deny-403" \
        --description "XSS attack filtering"
    

Le edge-fw-policy a été référencé par ingress-backendconfig à la section précédente. Lorsque la ressource Ingress est déployée, elle associe cette règle de sécurité à l'équilibreur de charge pour protéger les backends du service asm-ingressgateway.

Configurer l'adressage IP et DNS

  1. Dans Cloud Shell, créez une adresse IP statique globale pour l'équilibreur de charge Google Cloud :

    gcloud compute addresses create ingress-ip --global
    

    Cette adresse IP statique est utilisée par la ressource Ingress et permet à l'adresse IP de rester identique, même si l'équilibreur de charge externe est modifié.

  2. Obtenez l'adresse IP statique :

    export GCLB_IP=$(gcloud compute addresses describe ingress-ip --global --format "value(address)")
    echo ${GCLB_IP}
    

    Pour créer un mappage stable et lisible avec votre adresse IP Ingress, vous devez disposer d'un enregistrement DNS public. Vous pouvez utiliser le fournisseur DNS de votre choix et l'automatisation de votre choix. Ce tutoriel utilise les points de terminaison au lieu de créer une zone DNS gérée. Les points de terminaison offrent un enregistrement DNS géré par Google gratuit pour une adresse IP publique.

  3. Exécutez la commande suivante pour créer le fichier de spécification YAML nommé dns-spec.yaml :

    cat <<EOF > dns-spec.yaml
    swagger: "2.0"
    info:
      description: "Cloud Endpoints DNS"
      title: "Cloud Endpoints DNS"
      version: "1.0.0"
    paths: {}
    host: "frontend.endpoints.${PROJECT}.cloud.goog"
    x-google-endpoints:
    - name: "frontend.endpoints.${PROJECT}.cloud.goog"
      target: "${GCLB_IP}"
    EOF
    

    La spécification YAML définit l'enregistrement DNS public sous la forme frontend.endpoints.${PROJECT}.cloud.goog, où ${PROJECT} est votre numéro de projet unique.

  4. Déployez le fichier dns-spec.yaml dans votre projet Cloud :

    gcloud endpoints services deploy dns-spec.yaml
    

    Le résultat ressemble à ce qui suit :

    Operation finished successfully. The following command can describe the Operation details:
     gcloud endpoints operations describe operations/rollouts.frontend.endpoints.edge2mesh.cloud.goog:442b2b38-4aee-4c60-b9fc-28731657ee08
    
    Service Configuration [2021-11-14r0] uploaded for service [frontend.endpoints.edge2mesh.cloud.goog]
    

    Maintenant que l'adresse IP et les DNS sont configurés, vous pouvez générer un certificat public pour sécuriser l'interface Ingress. GKE Ingress accepte les certificats gérés par Google en tant que ressources Kubernetes. Cela vous permet de les provisionner via des moyens déclaratifs.

Provisionner un certificat TLS

  1. Dans Cloud Shell, exécutez la commande suivante pour créer le fichier manifeste ManagedCertificate sous le nom managed-cert.yaml :

    cat <<EOF > managed-cert.yaml
    apiVersion: networking.gke.io/v1
    kind: ManagedCertificate
    metadata:
      name: gke-ingress-cert
      namespace: asm-ingress
    spec:
      domains:
        - "frontend.endpoints.${PROJECT}.cloud.goog"
    EOF
    

    Ce fichier YAML spécifie que le nom DNS créé via les points de terminaison est utilisé pour provisionner un certificat public. Étant donné que Google gère entièrement le cycle de vie de ces certificats publics, ils sont automatiquement générés et renouvelés régulièrement, sans intervention directe de l'utilisateur.

  2. Déployez le fichier managed-cert.yaml dans votre cluster GKE :

    kubectl apply -f managed-cert.yaml
    

    Le résultat ressemble à ce qui suit :

    managedcertificate.networking.gke.io/gke-ingress-cert created
    
  3. Inspectez la ressource ManagedCertificate pour vérifier la progression de la génération du certificat :

    kubectl describe managedcertificate gke-ingress-cert -n asm-ingress
    

    Le résultat ressemble à ce qui suit :

    Name:         gke-ingress-cert
    Namespace:    asm-ingress
    Labels:       <none>
    Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                    {"apiVersion":"networking.gke.io/v1","kind":"ManagedCertificate","metadata":{"annotations":{},"name":"gke-ingress-cert","namespace":"...
    API Version:  networking.gke.io/v1
    Kind:         ManagedCertificate
    Metadata:
      Creation Timestamp:  2020-08-05T20:44:49Z
      Generation:          2
      Resource Version:    1389781
      Self Link:           /apis/networking.gke.io/v1/namespaces/asm-ingress/managedcertificates/gke-ingress-cert
      UID:                 d74ec346-ced9-47a8-988a-6e6e9ddc4019
    Spec:
      Domains:
        frontend.endpoints.edge2mesh.cloud.goog
    Status:
      Certificate Name:    mcrt-306c779e-8439-408a-9634-163664ca6ced
      Certificate Status:  Provisioning
      Domain Status:
        Domain:  frontend.endpoints.edge2mesh.cloud.goog
        Status:  Provisioning
    Events:
      Type    Reason  Age   From                            Message
      ----    ------  ----  ----                            -------
      Normal  Create  44s   managed-certificate-controller  Create SslCertificate mcrt-306c779e-8439-408a-9634-163664ca6ced
    

    Lorsque le certificat est prêt, la valeur Certificate Status est définie sur Active.

Déployer la ressource Ingress

  1. Dans Cloud Shell, exécutez la commande suivante pour créer le fichier manifeste Ingress sous le nom ingress.yaml :

    cat <<EOF > ingress.yaml
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: gke-ingress
      namespace: asm-ingress
      annotations:
        kubernetes.io/ingress.allow-http: "false"
        kubernetes.io/ingress.global-static-ip-name: "ingress-ip"
        networking.gke.io/managed-certificates: "gke-ingress-cert"
        kubernetes.io/ingress.class: "gce"
    spec:
      defaultBackend:
        service:
          name: asm-ingressgateway
          port:
            number: 443
      rules:
      - http:
          paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: asm-ingressgateway
                port:
                  number: 443
    EOF
    

    Ce fichier manifeste définit une ressource Ingress qui associe toutes les ressources précédentes. Le fichier manifeste spécifie les champs suivants :

    • kubernetes.io/ingress.allow-http: "false" désactive le trafic HTTP sur le port 80 de l'équilibreur de charge Google Cloud. Cela empêche efficacement les connexions de clients avec du trafic non chiffré, car le port 443 n'écoute que le protocole HTTPS et le port 80 est désactivé.
    • kubernetes.io/ingress.global-static-ip-name: "ingress-ip" associe l'adresse IP précédemment créée à l'équilibreur de charge. Cette association permet de créer l'adresse IP séparément de l'équilibreur de charge afin de pouvoir la réutiliser séparément du cycle de vie de l'équilibreur de charge.
    • networking.gke.io/managed-certificates: "gke-ingress-cert" associe cet équilibreur de charge à la ressource de certificat SSL géré par Google créée au préalable.
  2. Déployez ingress.yaml dans votre cluster :

    kubectl apply -f ingress.yaml
    
  3. Inspectez la ressource Ingress pour vérifier la progression du déploiement de l'équilibreur de charge :

    kubectl describe ingress gke-ingress -n asm-ingress
    

    Le résultat ressemble à ce qui suit :

    ...
    Annotations:
      ingress.kubernetes.io/https-forwarding-rule:       k8s2-fs-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
      ingress.kubernetes.io/ssl-cert:                    mcrt-306c779e-8439-408a-9634-163664ca6ced
      networking.gke.io/managed-certificates:            gke-ingress-cert
      kubernetes.io/ingress.global-static-ip-name:  ingress-ip
      ingress.gcp.kubernetes.io/pre-shared-cert:    mcrt-306c779e-8439-408a-9634-163664ca6ced
      ingress.kubernetes.io/backends:               {"k8s-be-31610--07bdde06b914144a":"HEALTHY","k8s1-07bdde06-asm-ingress-asm-ingressgateway-443-228c1881":"HEALTHY"}
      ingress.kubernetes.io/forwarding-rule:        k8s2-fr-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
      ingress.kubernetes.io/https-target-proxy:     k8s2-ts-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
      ingress.kubernetes.io/target-proxy:           k8s2-tp-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
      ingress.kubernetes.io/url-map:                k8s2-um-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
    ...
    

    La ressource Ingress est prête lorsque les annotations ingress.kubernetes.io/backends indiquent que les backends sont HEALTHY. Les annotations indiquent également les noms des différentes ressources Google Cloud provisionnées, y compris les services de backend, les certificats SSL et les proxys HTTPS.

Installer le certificat de passerelle d'entrée autosigné

Dans les étapes suivantes, vous allez générer et installer un certificat (en tant que ressource secret Kubernetes) qui permet au GFE d'établir une connexion TLS à la passerelle d'entrée du maillage de services. Pour plus d'informations sur les exigences liées au certificat de passerelle d'entrée, consultez le guide sur les protocoles de backend sécurisé.

  1. Dans Cloud Shell, créez la clé privée et le certificat à l'aide de openssl :

    openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \
     -subj "/CN=frontend.endpoints.${PROJECT}.cloud.goog/O=Edge2Mesh Inc" \
     -keyout frontend.endpoints.${PROJECT}.cloud.goog.key \
     -out frontend.endpoints.${PROJECT}.cloud.goog.crt
    
  2. Créez le Secret dans l'espace de noms asm-ingress:

    kubectl -n asm-ingress create secret tls edge2mesh-credential \
     --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
     --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt
    

Configurer la passerelle d'entrée pour l'équilibrage de charge externe

Dans les étapes suivantes, vous allez créer une ressource Gateway partagée dans l'espace de noms asm-ingress. Les passerelles appartiennent généralement aux administrateurs de plate-forme ou aux administrateurs réseau. Par conséquent, la ressource Gateway est créée dans l'espace de noms asm-ingress appartenant à l'administrateur de la plate-forme et peut être utilisée dans d'autres espaces de noms via leurs propres entrées VirtualService.

  1. Dans Cloud Shell, exécutez la commande suivante pour créer le fichier manifeste Gateway sous le nom ingress-gateway.yaml :

    cat <<EOF > ingress-gateway.yaml
    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
        name: asm-ingressgateway
        namespace: asm-ingress
    spec:
      selector:
        asm: ingressgateway
      servers:
      - port:
          number: 443
          name: https
          protocol: HTTPS
        hosts:
        - "*" # IMPORTANT: Must use wildcard here when using SSL, see note below
        tls:
          mode: SIMPLE
          credentialName: edge2mesh-credential
    EOF
    

    Notez que vous devez utiliser l'entrée générique * dans le champ hosts du fichier Gateway. GCLB n'utilise pas l'extension SNI pour les backends. L'utilisation du caractère générique permet d'envoyer le paquet chiffré (depuis GCLB) vers la passerelle d'entrée ASM. La passerelle d'entrée ASM déchiffre le paquet et utilise l'en-tête HTTP de l'hôte (dans le paquet déchiffré) pour prendre des décisions de routage (en fonction des entrées VirtualService).

  2. Déployez ingress-gateway.yaml dans votre cluster :

    kubectl apply -f ingress-gateway.yaml
    

    Le résultat ressemble à ce qui suit :

    gateway.networking.istio.io/asm-ingressgateway created
    

Installer l'exemple d'application Online Boutique

  1. Dans Cloud Shell, créez un espace de noms onlineboutique dédié :

    kubectl create namespace onlineboutique
    
  2. Ajoutez un libellé d'espace de noms à l'espace de noms onlineboutique :

    kubectl label namespace onlineboutique istio-injection=enabled
    

    Le résultat ressemble à ce qui suit :

    namespace/onlineboutique labeled
    

    L'ajout d'un libellé istio-injection=enabled à l'espace de noms onlineboutique indique à Anthos Service Mesh d'injecter automatiquement des proxys side-car Envoy lors du déploiement d'une application.

  3. Téléchargez les fichiers YAML Kubernetespour l'exemple d'application Boutique en ligne :

    curl -LO \
        https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yaml
    
  4. Déployez l'application Boutique en ligne :

    kubectl apply -f kubernetes-manifests.yaml -n onlineboutique
    

    Le résultat ressemble à ce qui suit :

    deployment.apps/frontend created
    service/frontend created
    service/frontend-external created
    ...
    
  5. Assurez-vous que tous les déploiements sont opérationnels :

    kubectl get pods -n onlineboutique
    

    Le résultat ressemble à ce qui suit :

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-d854d8786-fjb7q                2/2     Running   0          3m
    cartservice-85b5d5b4ff-8qn7g             2/2     Running   0          2m59s
    checkoutservice-5f9bf659b8-sxhsq         2/2     Running   0          3m1s
    ...
    
  6. Exécutez la commande suivante pour créer le fichier manifeste VirtualService en tant que frontend-virtualservice.yaml :

    cat <<EOF > frontend-virtualservice.yaml
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: frontend-ingress
      namespace: onlineboutique
    spec:
      hosts:
      - "frontend.endpoints.${PROJECT}.cloud.goog"
      gateways:
      - asm-ingress/asm-ingressgateway
      http:
      - route:
        - destination:
            host: frontend
            port:
              number: 80
    EOF
    

    Notez que le VirtualService est créé dans l'espace de noms de l'application (onlineboutique). En règle générale, le propriétaire de l'application choisit et configure le mode de routage du trafic vers l'application frontend afin de déployer VirtualService.

  7. Déployez frontend-virtualservice.yaml dans votre cluster :

    kubectl apply -f frontend-virtualservice.yaml
    

    Le résultat ressemble à ce qui suit :

    virtualservice.networking.istio.io/frontend-virtualservice created
    
  8. Cliquez sur le lien suivant :

    echo "https://frontend.endpoints.${PROJECT}.cloud.goog"
    

    L'interface de votre boutique en ligne s'affiche.

    Produits affichés sur la page d&#39;accueil de la boutique en ligne.

  9. Pour afficher les détails de votre certificat, cliquez sur Afficher les informations sur le site dans la barre d'adresse de votre navigateur, puis cliquez sur Certificat (valide).

    La visionneuse de certificats affiche les détails du certificat géré, y compris la date d'expiration et l'auteur.

Vous disposez maintenant d'un équilibreur de charge HTTPS global servant d'interface à votre application hébergée par le maillage de services.

Nettoyer

Une fois que vous avez terminé le tutoriel, vous pouvez nettoyer les ressources que vous avez créées sur Google Cloud afin qu'elles ne vous soient plus facturées. Vous pouvez soit supprimer entièrement le projet, soit supprimer les ressources du cluster, puis le supprimer.

Supprimer le projet

  1. Dans Cloud Console, accédez à la page Gérer les ressources :

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer les ressources individuelles

Si vous souhaitez conserver le projet Cloud que vous avez utilisé dans ce tutoriel, supprimez les différentes ressources :

  1. Supprimez la ressource Ingress :

    kubectl delete -f ingress.yaml
    
  2. Supprimez le certificat géré :

    kubectl delete -f managed-cert.yaml
    
  3. Supprimez l'entrée Endpoints DNS :

    gcloud endpoints services delete "frontend.endpoints.${PROJECT}.cloud.goog"
    

    Le résultat ressemble à ce qui suit :

    Are you sure? This will set the service configuration to be deleted, along
    with all of the associated consumer information. Note: This does not
    immediately delete the service configuration or data and can be undone using
    the undelete command for 30 days. Only after 30 days will the service be
    purged from the system.
    
  4. Lorsque vous êtes invité à continuer, saisissez Y.

    Le résultat ressemble à ce qui suit :

    Waiting for async operation operations/services.frontend.endpoints.edge2mesh.cloud.goog-5 to complete...
    Operation finished successfully. The following command can describe the Operation details:
     gcloud endpoints operations describe operations/services.frontend.endpoints.edge2mesh.cloud.goog-5
    
  5. Supprimez l'adresse IP statique :

    gcloud compute addresses delete ingress-ip --global
    

    Le résultat ressemble à ce qui suit :

    The following global addresses will be deleted:
    
     - [ingress-ip]
    
  6. Lorsque vous êtes invité à continuer, saisissez Y.

    Le résultat ressemble à ce qui suit :

    Deleted
    [https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].
    
  7. Supprimez le cluster GKE :

    gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
    

Étape suivante