De la périphérie au réseau : déployer les applications d'un maillage de services via GKE Gateway

Last reviewed 2024-01-31 UTC

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

Vous pouvez exposer une application à des clients de différentes manières selon l'emplacement des clients. Ce déploiement 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 déploiement s'adresse aux professionnels avancés qui utilisent Anthos Service Mesh, mais il fonctionne également pour Istio sur Google Kubernetes Engine.

Architecture

Le schéma suivant montre comment utiliser des passerelles d'entrée de maillage pour intégrer des équilibreurs de charge à un maillage de services :

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

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

Dans la topologie du schéma précédent, la couche d'entrée cloud, programmée via GKE Gateway, 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.

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.

La topologie précédente implique les considérations suivantes :

  • Entrée cloud : dans cette architecture de référence, vous configurez l'équilibreur de charge Google Cloud via GKE Gateway pour qu'il vérifie l'état des proxys d'entrée du maillage sur leurs ports de vérification d'état exposés.
  • Entrée de maillage : 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.

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.

Le schéma précédent 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.

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

Optimisation des coûts

Dans ce document, vous utilisez 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é les tâches décrites dans ce document, 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. Vérifiez que la facturation est activée pour votre projet Google Cloud.

  3. Dans la console Google Cloud, activez Cloud Shell.

    Activer Cloud Shell

    Vous exécutez toutes les commandes de terminal de ce déploiement 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=PROJECT
    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
    gcloud config set project ${PROJECT}
    

    Remplacez PROJECT par l'ID de projet que vous souhaitez utiliser pour ce déploiement.

  6. Créez un répertoire de travail :

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

    Une fois ce déploiement terminé, vous pouvez supprimer le répertoire de travail.

Créer des clusters GKE

Les fonctionnalités décrites dans ce déploiement 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-central1
    
  3. Activez l'API Google Kubernetes Engine :

    gcloud services enable container.googleapis.com
    
  4. Créez un cluster GKE Autopilot :

    gcloud container --project ${PROJECT} clusters create-auto
    ${CLUSTER_NAME} --region ${CLUSTER_LOCATION} --release-channel rapid
    
  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-central1  1.27.3-gke.1700   34.122.84.52  e2-medium  1.27.3-gke.1700   3          RUNNING
    

Installer un maillage de services

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

  1. Dans Cloud Shell, activez les API nécessaires :

    gcloud services enable mesh.googleapis.com
    
  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
    
  4. Appliquez le libellé mesh_id au cluster edge-to-mesh :

    gcloud container clusters update ${CLUSTER_NAME} --project ${PROJECT} --region ${CLUSTER_LOCATION} --update-labels mesh_id=proj-${PROJECT_NUMBER}
    
  5. Activez la gestion automatique du plan de contrôle et le plan de données géré :

    gcloud container fleet mesh update \
      --management automatic \
      --memberships ${CLUSTER_NAME}
    
  6. 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/892585880385/locations/us-central1/memberships/edge-to-mesh:
        mesh:
          management: MANAGEMENT_AUTOMATIC
    membershipStates:
      projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
        servicemesh:
          controlPlaneManagement:
            details:
            - code: REVISION_READY
              details: 'Ready: asm-managed-rapid'
            state: ACTIVE
          dataPlaneManagement:
            details:
            - code: OK
              details: Service is running.
            state: ACTIVE
        state:
          code: OK
          description: 'Revision(s) ready for use: asm-managed-rapid.'
          updateTime: '2023-08-04T02:54:39.495937877Z'
    name: projects/e2m-doc-01/locations/global/features/servicemesh
    resourceState:
      state: ACTIVE
    ...
    

Déployer GKE Gateway

Dans les étapes suivantes, vous allez déployer l'équilibreur de charge d'application externe via le GKE Gateway Controller. La ressource GKE Gateway automatise le provisionnement de l'équilibreur de charge et la vérification d'état du backend. De plus, vous utilisez le gestionnaire de certificats pour provisionner et gérer un certificat TLS, et les points de terminaison pour provisionner automatiquement un nom DNS public pour l'application.

Installer une passerelle d'entrée du maillage de services

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. Créez un certificat autosigné utilisé par la passerelle d'entrée pour interrompre les connexions TLS entre l'équilibreur de charge Google Cloud (à configurer ultérieurement via GKE Gateway Controller) et la passerelle d'entrée, puis stocker le certificat autosigné en tant que secret Kubernetes :

    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
    
    kubectl -n asm-ingress create secret tls edge2mesh-credential \
     --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
     --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt
    

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

  4. Exécutez les commandes suivantes pour créer le fichier YAML de ressource de passerelle d'entrée :

    mkdir -p ${WORKDIR}/asm-ig/base
    cat <<EOF > ${WORKDIR}/asm-ig/base/kustomization.yaml
    resources:
      - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base
    EOF
    
    mkdir ${WORKDIR}/asm-ig/variant
    cat <<EOF > ${WORKDIR}/asm-ig/variant/role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/rolebinding.yaml
    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
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/service-proto-type.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: asm-ingressgateway
    spec:
      ports:
      - name: status-port
        port: 15021
        protocol: TCP
        targetPort: 15021
      - name: http
        port: 80
        targetPort: 8080
      - name: https
        port: 443
        targetPort: 8443
        appProtocol: HTTP2
      type: ClusterIP
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/gateway.yaml
    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: asm-ingressgateway
    spec:
      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
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/kustomization.yaml
    namespace: asm-ingress
    resources:
    - ../base
    - role.yaml
    - rolebinding.yaml
    patches:
    - path: service-proto-type.yaml
      target:
        kind: Service
    - path: gateway.yaml
      target:
        kind: Gateway
    EOF
    
  5. Appliquez les CRD de passerelle d'entrée :

    kubectl apply -k ${WORKDIR}/asm-ig/variant
    
  6. 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
    

Appliquer une vérification d'état à la passerelle d'entrée du maillage de services

Lors de l'intégration d'une passerelle d'entrée de maillage de services à un équilibreur de charge d'application Google Cloud, celui-ci doit être configuré pour effectuer des vérifications d'état sur les pods de la passerelle d'entrée. L'objet CRD HealthCheckPolicy fournit une API permettant de configurer cette vérification d'état.

  1. Dans Cloud Shell, créez le fichier HealthCheckPolicy.yaml :

    cat <<EOF >${WORKDIR}/ingress-gateway-healthcheck.yaml
    apiVersion: networking.gke.io/v1
    kind: HealthCheckPolicy
    metadata:
      name: ingress-gateway-healthcheck
      namespace: asm-ingress
    spec:
      default:
        checkIntervalSec: 20
        timeoutSec: 5
        #healthyThreshold: HEALTHY_THRESHOLD
        #unhealthyThreshold: UNHEALTHY_THRESHOLD
        logConfig:
          enabled: True
        config:
          type: HTTP
          httpHeal