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 à vous si vous êtes un utilisateur Cloud Service Mesh existant qui dispose du plan de contrôle géré Istiod et que vous souhaitez configurer un équilibreur de charge d'application classique en tant que 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é de Cloud Service Mesh.

Cloud Load Balancing fournit de nombreuses fonctionnalités de pointe 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, le pare-feu de nouvelle génération Cloud et Cloud Intrusion Detection System. Cloud Service Mesh peut intégrer facilement ces fonctionnalités de bord dans le modèle d'entrée en réseau maillé suivant. La passerelle cloud de service mesh offre un moyen unifié de configurer simultanément la passerelle d'entrée Cloud Service Mesh avec Cloud Load Balancing via l'API Kubernetes Gateway.

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

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

Limites de l'aperçu

Pour la version Preview de cette fonctionnalité, les limites suivantes s'appliquent:

Les passerelles multiclusters ne sont pas compatibles.
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 vérifie pas le certificat fourni par la passerelle d'entrée Cloud Service Mesh. Cette limite s'applique à tous les utilisateurs de l' Google Cloud équilibreur de charge HTTP(S).
Si des 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 l'usabilité de la fonctionnalité.
La logique de mise en correspondance des routes ne suit pas les spécifications de l'API Gateway et correspond plutôt dans l'ordre de l'HTTPRoute. Cela changera dans les prochaines versions pour suivre les spécifications de l'API Gateway.

Conditions requises

Cloud Service Mesh géré 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 compatibles.
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 service mesh pour un maillage à un seul cluster

Cette section 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 Cloud Service Mesh géré avec rapid ou regular comme version disponible.

Déployer la ressource Gateway

Lorsque vous déployez la passerelle cloud du service mesh, les ressources de passerelle Kubernetes 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 la section Kubernetes Gateway et Istio Gateway. Chaque passerelle Kubernetes dispose d'une classe de passerelle qui indique son type et ses fonctionnalités inhérentes. La passerelle cloud de service mesh dispose d'une classe de passerelle qui permet de déployer à la fois l'Cloud Load Balancing 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 ne voyez pas le résultat attendu, vérifiez que vous avez bien rempli les conditions préalables.

Vous verrez également la GatewayClass suivante:
```
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 service mesh:
```
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

Les événements suivants se produisent lorsque cet objet de l'API Kubernetes Gateway est déployé:

Un équilibreur de charge HTTP(S) externe est déployé et configuré. Son affichage peut prendre quelques minutes, mais une fois qu'il est opérationnel, la passerelle indique l'adresse IP et est annotée avec les noms des ressources d'équilibreur de charge Compute Engine 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 de Cloud Service Mesh.

Vous disposez désormais de l'infrastructure complète nécessaire pour accepter le trafic Internet dans votre réseau maillé. 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 qui le rendront 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 dans Cloud Service Mesh et recevoir du trafic Internet via votre passerelle à des fins 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 en déployer deux versions différentes.

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 service mesh 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 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, elle est 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 ressource Gateway 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 à 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 déterminer que le routage est effectué correctement entre 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 la passerelle de production

La section précédente présentait un exemple très simple de passerelle cloud de service mesh. Les étapes suivantes s'appuient sur l'exemple simple pour présenter une configuration prête à la production qui illustre les avantages de déléguer certaines des fonctionnalités de routage d'entrée à l'équilibreur de charge.

Dans l'exemple suivant, vous allez utiliser 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, générés à l'aide de certificats gérés par Google, ou générés 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 des services publics, ils démontrent plus facilement ces concepts.

Pour en savoir plus sur la création d'un certificat autosigné via un secret Kubernetes, consultez la section 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 en 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"
}

La sortie détaillée 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 classe GatewayClass asm-l7-gxlb ont extrait certains composants d'infrastructure internes pour simplifier l'expérience utilisateur. Cloud Load Balancing interrompt le trafic TLS à l'aide d'un certificat interne et vérifie également l'état de la couche proxy de la passerelle d'entrée Cloud Service Mesh. Le whereami-route déployé dans App & Routing Deployment configure les proxys de la 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
```