Cloud Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Configurer un équilibreur de charge d'application classique pour Cloud Service Mesh

Présentation

Ce document s'adresse aux utilisateurs existants de Cloud Service Mesh qui disposent du plan de contrôle géré Istiod et qui souhaitent configurer l'équilibreur de charge d'application classique comme passerelle d'entrée. L'équilibreur de charge d'application classique est également appelé équilibreur de charge d'application externe classique.

N'utilisez pas ce document si vous êtes un nouvel utilisateur de Cloud Service Mesh. Les nouveaux utilisateurs sont automatiquement configurés avec le plan de contrôle géré Cloud Service Mesh. Vous ne pouvez pas utiliser la configuration décrite dans ce document avec le plan de contrôle géré Cloud Service Mesh.

Cloud Load Balancing offre de nombreuses fonctionnalités de périphérie gérées dans le cloud, y compris l'équilibrage de charge Anycast mondial, les certificats gérés par Google, Identity and Access Management, Cloud Next Generation Firewall et Cloud Intrusion Detection System. Cloud Service Mesh peut intégrer de manière fluide ces fonctionnalités de périphérie dans le modèle d'entrée de maillage suivant. La passerelle cloud de maillage de services offre un moyen unifié de configurer la passerelle d'entrée Cloud Service Mesh avec Cloud Load Balancing simultanément via l'API Kubernetes Gateway.

Schéma illustrant un équilibreur de charge avec Cloud Service Mesh

Par rapport à notre guide de l'utilisateur précédent, De la périphérie au réseau : exposer les applications de maillage de services via GKE Ingress, avec la passerelle cloud de maillage de services, ce modèle peut désormais être déployé via une ressource Kubernetes Gateway, ce qui simplifie le processus de déploiement de l'équilibrage de charge cloud et hébergé dans un cluster.

Limites de l'aperçu

Les limites suivantes s'appliquent à la version Preview de cette fonctionnalité :

Les passerelles multicluster ne sont pas prises en charge.
Les clusters Autopilot ne sont pas compatibles.
Seul l'équilibreur de charge d'application classique est compatible. L'équilibreur de charge d'application externe global (parfois appelé "équilibreur de charge avancé") et l'équilibreur de charge d'application interne ne sont pas compatibles.
Le trafic entre l'équilibreur de charge d'application classique et la passerelle d'entrée Cloud Service Mesh est chiffré à l'aide de TLS. Toutefois, l'équilibreur de charge d'application classique ne validera pas le certificat fourni par la passerelle d'entrée Cloud Service Mesh. Cette limite s'applique à tous les utilisateurs de l'équilibreur de charge HTTP(S) Google Cloud .
Si les GatewayClasses Cloud Service Mesh sont supprimés d'un cluster, ils ne seront pas réinstallés automatiquement. Toutefois, cela n'aura aucune incidence sur la facilité d'utilisation de la fonctionnalité.
La logique de correspondance des routes ne suit pas les spécifications de l'API Gateway et correspond plutôt à l'ordre de HTTPRoute. Cette valeur changera dans les prochaines versions pour respecter les spécifications de l'API Gateway.

Conditions requises

Managed Cloud Service Mesh installé sur un cluster Google Kubernetes Engine (GKE) exécutant la version 1.24 ou ultérieure. Les autres clusters GKE Enterprise ne sont pas acceptés.
Version v1beta1 de l'API Kubernetes Gateway uniquement.

Prérequis

Activez les API suivantes dans votre projet :

compute.googleapis.com
container.googleapis.com
certificatemanager.googleapis.com
serviceusage.googleapis.com

gcloud services enable \
   compute.googleapis.com \
   container.googleapis.com \
   certificatemanager.googleapis.com \
   serviceusage.googleapis.com

Déployer une passerelle cloud de maillage de services pour un maillage à un seul cluster

Cette section vous explique comment déployer une ressource de passerelle Kubernetes qui déploie un équilibreur de charge d'application classique et une passerelle d'entrée Cloud Service Mesh.

Activer l'API Gateway avec Cloud Service Mesh géré

Activez l'API Gateway dans votre cluster. Le cluster GKE doit être à la version 1.24 ou ultérieure.
Installez Managed Cloud Service Mesh avec rapid ou regular comme canal de publication.

Déployer la ressource Gateway

Lors du déploiement d'une passerelle cloud de maillage de services, les ressources Kubernetes Gateway sont utilisées pour déployer à la fois Cloud Load Balancing et la passerelle d'entrée Cloud Service Mesh en une seule étape. Notez que les ressources Kubernetes Gateway sont différentes des ressources Istio Gateway.

Pour en savoir plus sur les différences, consultez Kubernetes Gateway et Istio Gateway. Chaque passerelle Kubernetes possède une GatewayClass qui indique son type et ses capacités inhérentes. La passerelle cloud de maillage de services possède une GatewayClass qui permet de déployer à la fois l'équilibreur de charge cloud et la passerelle d'entrée Cloud Service Mesh.

Enregistrez le fichier manifeste GatewayClass suivant dans un fichier nommé l7-gateway-class.yaml :

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: asm-l7-gxlb
spec:
  controllerName: mesh.cloud.google.com/gateway

Déployez la ressource GatewayClass dans votre cluster :
```
kubectl apply -f l7-gateway-class.yaml
```
Vérifiez que la GatewayClass est présente après l'installation :
```
kubectl get gatewayclasses.gateway.networking.k8s.io
```
Le résultat est semblable à :
```
NAME          CONTROLLER
asm-l7-gxlb   mesh.cloud.google.com/gateway
gke-l7-rilb   networking.gke.io/gateway
gke-l7-gxlb   networking.gke.io/gateway
```
Le déploiement de toutes les ressources peut prendre quelques minutes. Si vous n'obtenez pas le résultat attendu, vérifiez que vous avez correctement rempli les conditions préalables.

La GatewayClass suivante s'affiche également :
```
gke-l7-gxlb   networking.gke.io/gateway
```
Il permet de déployer l'équilibreur de charge d'application classique Google Cloud sous-jacent.
Créez un espace de noms dédié pour votre passerelle cloud de maillage de services :
```
kubectl create namespace istio-ingress
```

Enregistrez le fichier de manifeste de passerelle suivant dans un fichier nommé gateway.yaml :

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: servicemesh-cloud-gw
  namespace: istio-ingress
spec:
  gatewayClassName: asm-l7-gxlb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

Déployez la ressource Gateway dans votre cluster dans l'espace de noms istio-ingress :
```
kubectl apply -f gateway.yaml
```

Vérifiez que les objets de l'API Kubernetes Gateway sont créés :

kubectl get gateways.gateway.networking.k8s.io -n istio-ingress

Le résultat est semblable à :

NAME                                CLASS         ADDRESS         READY   AGE
asm-gw-gke-servicemesh-cloud-gw     gke-l7-gxlb   34.111.114.64   True    9m40s
asm-gw-istio-servicemesh-cloud-gw   istio                                 9m44s
servicemesh-cloud-gw                asm-l7-gxlb                           9m44s

Voici ce qui se passera lorsque cet objet de l'API Kubernetes Gateway sera déployé :

Un équilibreur de charge HTTP(S) externe est déployé et configuré. L'affichage peut prendre quelques minutes, mais une fois la passerelle opérationnelle, elle indique l'adresse IP et est annotée avec les noms des ressources d'équilibreur de charge Compute Engine qui ont été créées.
Un déploiement de passerelle d'entrée Cloud Service Mesh est créé dans l'espace de noms istio-ingress. Cela crée les instances de proxy Envoy qui recevront le trafic de l'équilibreur de charge.
L'équilibreur de charge chiffre et achemine tout le trafic vers la passerelle d'entrée Cloud Service Mesh.

Vous disposez désormais de l'infrastructure complète nécessaire pour accepter le trafic Internet dans votre maillage. Notez qu'il s'agit du déploiement de passerelle le plus simple possible. Dans les sections suivantes, vous allez ajouter des règles et des fonctionnalités supplémentaires pour le rendre prêt pour la production.

Déploiement de l'application et du routage

Pour illustrer pleinement les fonctionnalités, vous allez déployer une application sur Cloud Service Mesh et recevoir du trafic Internet via votre passerelle à titre d'exemple.

Ajoutez un libellé à l'espace de noms default pour activer l'injection side-car.

kubectl label namespace default istio-injection=enabled istio.io/rev- --overwrite

Enregistrez le fichier de manifeste de passerelle suivant dans un fichier nommé whereami.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whereami-v1
  template:
    metadata:
      labels:
        app: whereami-v1
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
          - containerPort: 8080
        env:
        - name: METADATA
          value: "whereami-v1"
---
apiVersion: v1
kind: Service
metadata:
  name: whereami-v1
spec:
  selector:
    app: whereami-v1
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami-v2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whereami-v2
  template:
    metadata:
      labels:
        app: whereami-v2
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
          - containerPort: 8080
        env:
        - name: METADATA
          value: "whereami-v2"
---
apiVersion: v1
kind: Service
metadata:
  name: whereami-v2
spec:
  selector:
    app: whereami-v2
  ports:
  - port: 8080
    targetPort: 8080

Ce fichier manifeste crée Service/whereami-v1, Service/whereami-v2, Deployment/whereami-v1 et Deployment/whereami-v2 pour whereami, une application simple qui génère du code JSON pour indiquer son identité et son emplacement. Vous allez déployer deux versions différentes de cette application.

Créez les services et les déploiements :
```
kubectl apply -f whereami.yaml
```
Une fois qu'il est opérationnel, quatre pods "whereami" s'exécutent dans votre cluster.

Vérifiez que les quatre pods sont en cours d'exécution :

kubectl get pods

Le résultat est semblable à :

whereami-v1-7c76d89d55-qg6vs       2/2     Running   0          28s
whereami-v1-7c76d89d55-vx9nm       2/2     Running   0          28s
whereami-v2-67f6b9c987-p9kqm       2/2     Running   0          27s
whereami-v2-67f6b9c987-qhj76       2/2     Running   0          27s

Enregistrez le fichier manifeste HTTPRoute suivant dans un fichier nommé http-route.yaml :

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: where-route
spec:
 parentRefs:
 - kind: Gateway
   name: servicemesh-cloud-gw
   namespace: istio-ingress
 hostnames:
 - "where.example.com"
 rules:
 - matches:
   - headers:
     - name: version
       value: v2
   backendRefs:
   - name: whereami-v2
     port: 8080
 - backendRefs:
   - name: whereami-v1
     port: 8080

Déployez http-route.yaml sur votre cluster :
```
kubectl apply -f http-route.yaml
```
Cette HTTPRoute fait référence à servicemesh-cloud-gw, ce qui signifie qu'elle configurera la passerelle cloud du maillage de services afin qu'elle configure la passerelle d'entrée Cloud Service Mesh sous-jacente avec ces règles de routage. HTTPRoute remplit la même fonction que VirtualService d'Istio, mais utilise l'API Kubernetes Gateway pour ce faire. Étant donné que l'API Gateway est une spécification OSS avec de nombreuses implémentations sous-jacentes, il s'agit de la meilleure API pour définir le routage sur une combinaison de différents équilibreurs de charge (tels que les proxys et les équilibreurs de charge Cloud Service Mesh).

Récupérez l'adresse IP à partir de la passerelle afin de pouvoir envoyer du trafic vers votre application :

VIP=$(kubectl get gateways.gateway.networking.k8s.io asm-gw-gke-servicemesh-cloud-gw -o=jsonpath="{.status.addresses[0].value}" -n istio-ingress)

Le résultat est une adresse IP.

echo $VIP

34.111.61.135

Envoyez du trafic vers l'adresse IP de la passerelle pour vérifier que cette configuration fonctionne correctement. Envoyez une requête avec l'en-tête version: v2 et une autre sans pour vérifier que le routage est effectué correctement dans les deux versions de l'application.

curl ${VIP} -H "host: where.example.com"

{
  "cluster_name": "gke1",
  "host_header": "where.example.com",
  "metadata": "whereami-v1",
  "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
  "pod_name": "whereami-v1-67d9c5d48b-zhr4l",
  "pod_name_emoji": "⚒",
  "project_id": "church-243723",
  "timestamp": "2021-02-08T18:55:01",
  "zone": "us-central1-a"
}

curl ${VIP} -H "host: where.example.com" -H "version: v2"

{
  "cluster_name": "gke1",
  "host_header": "where.example.com",
  "metadata": "whereami-v2",
  "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
  "pod_name": "whereami-v2-67d9c5d48b-zhr4l",
  "pod_name_emoji": "⚒",
  "project_id": "church-243723",
  "timestamp": "2021-02-08T18:55:01",
  "zone": "us-central1-a"
}

Déploiement de passerelle de production

La section précédente présentait un exemple très simple de passerelle cloud de maillage de services. Les étapes suivantes s'appuient sur l'exemple simple pour montrer une configuration prête pour la production qui illustre les avantages de la délégation d'une partie de la fonctionnalité de routage Ingress à l'équilibreur de charge.

Dans l'exemple suivant, vous allez prendre le servicemesh-cloud-gw de la section précédente et ajouter les fonctionnalités suivantes pour créer une passerelle plus sécurisée et plus facile à gérer :

Déployez la passerelle avec une adresse IP statique qui sera conservée même si l'infrastructure sous-jacente change.
Convertissez la passerelle pour qu'elle reçoive le trafic HTTPS avec un certificat autosigné.

Créez une adresse IP externe statique. Une adresse IP statique est utile, car l'infrastructure sous-jacente peut changer à l'avenir, mais l'adresse IP peut être conservée.
```
gcloud compute addresses create whereami-ip \
    --global \
    --project PROJECT_ID
```

Créez un certificat autosigné pour le domaine where-example-com :

openssl genrsa -out key.pem 2048
cat <<EOF >ca.conf
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no
[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list
[dn_requirements]
0.organizationName        = example
commonName                = where.example.com
[sans_list]
DNS.1                     = where.example.com
EOF

openssl req -new -key key.pem \
    -out csr.pem \
    -config ca.conf

openssl x509 -req \
    -signkey key.pem \
    -in csr.pem \
    -out cert.pem \
    -extfile ca.conf \
    -extensions extension_requirements \
    -days 365

gcloud compute ssl-certificates create where-example-com \
    --certificate=cert.pem \
    --private-key=key.pem \
    --global \
    --project PROJECT_ID

Il existe de nombreuses façons de générer des certificats TLS. Ils peuvent être générés manuellement sur la ligne de commande, à l'aide de certificats gérés par Google, ou en interne par le système d'infrastructure à clé publique (PKI) de votre entreprise. Dans cet exemple, vous générez manuellement un certificat autosigné. Bien que les certificats autosignés ne soient généralement pas utilisés pour les services publics, ils permettent de mieux comprendre ces concepts.

Pour en savoir plus sur la création d'un certificat autosigné via un secret Kubernetes, consultez Sécuriser une passerelle.

Mettez à jour gateway.yaml avec le fichier manifeste suivant :

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: servicemesh-cloud-gw
  namespace: istio-ingress
spec:
  gatewayClassName: asm-l7-gxlb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All
  - name: https
    protocol: HTTPS
    port: 443
    allowedRoutes:
      namespaces:
        from: All
    tls:
      mode: Terminate
      options:
        networking.gke.io/pre-shared-certs: where-example-com
  addresses:
  - type: NamedAddress
    value: whereami-ip

Redéployez la ressource Gateway dans votre cluster :
```
kubectl apply -f gateway.yaml
```

Obtenez l'adresse IP de l'adresse IP statique :

VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")

Utilisez curl pour accéder au domaine de la ressource Gateway. Comme le DNS n'est pas configuré pour ce domaine, utilisez l'option --resolve pour indiquer à curl de résoudre le nom de domaine vers l'adresse IP de la passerelle :

curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -v

Une fois l'opération terminée, le résultat ressemble à ce qui suit :

...
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=example; CN=where.example.com
*  start date: Apr 19 15:54:50 2021 GMT
*  expire date: Apr 19 15:54:50 2022 GMT
*  common name: where.example.com (matched)
*  issuer: O=example; CN=where.example.com
*  SSL certificate verify ok.
...
{
  "cluster_name": "gke1",
  "host_header": "where.example.com",
  "metadata": "where-v1",
  "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
  "pod_name": "where-v1-84b47c7f58-tj5mn",
  "pod_name_emoji": "😍",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-04-19T16:30:08",
  "zone": "us-west1-a"
}

Le résultat détaillé inclut un handshake TLS réussi suivi d'une réponse de l'application, comme le résultat ci-dessous. Cela prouve que le protocole TLS est correctement arrêté sur la ressource Gateway et que l'application répond au client de manière sécurisée.

Vous avez déployé l'architecture suivante :

Architecture ASM

servicemesh-cloud-gw et sa GatewayClass asm-l7-gxlb ont abstrait certains composants d'infrastructure internes pour simplifier l'expérience utilisateur. Cloud Load Balancing met fin au trafic TLS à l'aide d'un certificat interne et vérifie également l'état de la couche de proxy de la passerelle d'entrée Cloud Service Mesh. Le whereami-route déployé dans Déploiement d'application et de routage configure les proxys de passerelle d'entrée Cloud Service Mesh pour acheminer le trafic vers le service hébergé sur le maillage approprié.

Déployez la passerelle avec une adresse IP statique qui sera conservée même si l'infrastructure sous-jacente change.
Convertissez la passerelle pour qu'elle reçoive le trafic HTTPS avec un certificat autosigné.

Créez une adresse IP externe statique. Une adresse IP statique est utile, car l'infrastructure sous-jacente peut changer à l'avenir, mais l'adresse IP peut être conservée.
```
gcloud compute addresses create whereami-ip \
    --global \
    --project PROJECT_ID
```