Acheminer le trafic des charges de travail Cloud Service Mesh vers une VM Compute Engine

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Remarque : Ce guide n'est compatible qu'avec Cloud Service Mesh et les API Istio. Il n'est pas compatible avec les API Google Cloud . Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cloud Service Mesh vous permet d'acheminer le trafic des charges de travail GKE vers des machines virtuelles (VM) Compute Engine précédées d'un BackendService. Vous pouvez envoyer des requêtes à ces ressources autonomes sans ajouter la VM ou le BackendService au maillage de services.

Ce document ne s'applique qu'aux implémentations de Cloud Service Mesh utilisant les API Istio et n'est pas compatible avec les API Google Cloud . mTLS n'est pas compatible avec les VM Compute Engine.

Avant de commencer

Les sections suivantes supposent que vous avez :

1. Un cluster GKE avec Cloud Service Mesh activé.
2. Déployé une VM Compute Engine précédée d'un BackendService.

Vous pouvez également exécuter les commandes suivantes pour déployer un exemple de VM Compute Engine précédée d'un BackendService.

1. Déployez un exemple de VM Compute Engine et de BackendService :

   gcloud compute instance-templates create td-httpd-vm-template \
     --scopes=https://www.googleapis.com/auth/cloud-platform \
     --tags=http-td-server \
     --image-family=debian-11 \
     --image-project=debian-cloud \
     --metadata=startup-script="#! /bin/bash
   sudo apt-get update -y
   sudo apt-get install apache2 -y
   sudo service apache2 restart
   echo '<!doctype <html><body><h1>'\`$(/bin/hostname)\`'</h1></body></html>' | sudo tee /var/www/html/index.html"
   
   gcloud compute instance-groups managed create http-td-mig-us-east1 \
     --zone=VM_ZONE   \
     --size=2 \
     --template=td-httpd-vm-template
   
   gcloud compute health-checks create http http-helloworld-health-check
   
   gcloud compute firewall-rules create http-vm-allow-health-checks \
     --network=default \
     --action=ALLOW \
     --direction=INGRESS \
     --source-ranges=0.0.0.0/0 \
     --target-tags=http-td-server \
     --rules=tcp:80
   
   gcloud compute backend-services create helloworld \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --protocol=HTTP \
     --health-checks http-helloworld-health-check
   
   gcloud compute backend-services add-backend helloworld \
     --instance-group=http-td-mig-us-east1 \
     --instance-group-zone=VM_ZONE  \
     --global
   

   Où :

   • VM_ZONE est la zone dans laquelle vous souhaitez déployer votre VM Compute Engine.

Configurer une VM Compute Engine en tant que GCPBackend

Dans cette section, vous allez exposer la VM Compute Engine aux charges de travail GKE à l'aide de GCPBackend. Le GCPBackend se compose des éléments suivants :

1. Informations sur l'interface, en particulier le nom d'hôte et le port que les charges de travail GKE utiliseraient pour appeler ce GCPBackend.
2. Informations sur le backend : détails du BackendService, tels que le nom du service, l'emplacement et le numéro de projet.

Le GCPBackend contient les détails du nom d'hôte et du port, ainsi que les détails du BackendService (nom du service, emplacement et numéro de projet). Les charges de travail GKE doivent utiliser le nom d'hôte et le port GCPBackend dans leurs requêtes HTTP pour accéder à la VM Compute Engine.

Pour que le nom d'hôte DNS puisse être résolu dans le cluster (par défaut, il n'est pas résolu), vous devez configurer Google Cloud DNS pour qu'il résolve tous les hôtes sous un nom d'hôte choisi en une adresse IP arbitraire. Tant que vous n'avez pas configuré cette entrée DNS, la requête échoue. La configuration DNS Google Cloud est une configuration unique par domaine personnalisé.

1. Créez une zone gérée :

   gcloud dns managed-zones create prod \
       --description="zone for gcpbackend" \
       --dns-name=gcpbackend \
       --visibility=private \
       --networks=default
   

   Dans cet exemple, le nom DNS est gcpbackend et le réseau VPC est default.

2. Configurez l'enregistrement pour que le domaine puisse être résolu :

   gcloud beta dns record-sets create *.gcpbackend \
     --ttl=3600 --type=A --zone=prod \
     --rrdatas=10.0.0.1
   

3. Créez le GCPBackend avec un nom d'hôte sous le domaine précédent :

   cat <<EOF > gcp-backend.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPBackend
   metadata:
     name: vm-gcp-backend
     namespace: NAMESPACE
   spec:
     type: "BackendService"
     hostname: hello-world.gcpbackend
     backendservice:
       name: helloworld
       location: global
   EOF
   kubectl apply -f gcp-backend.yaml
   

   Dans cet exemple, GCP_BACKEND_NAME est vm-gcp-backend.

4. Créez un pod de test pour vérifier la connectivité entre GKE et la VM Compute Engine :

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: testcurl
     namespace: default
   spec:
     containers:
     - name: curl
       image: curlimages/curl
       command: ["sleep", "3000"]
   EOF
   
   kubectl exec testcurl -c curl -- curl http://hello-world.gcpbackend:80
   

   Vos charges de travail GKE peuvent désormais accéder à la VM Compute Engine en envoyant des requêtes HTTP à hello-world.gcpbackend:80.

Vous devez utiliser des noms distincts pour GCPBackend afin d'éviter tout conflit avec les services Kubernetes ou les entrées de service Istio existants. En cas de conflit, l'ordre de priorité (du plus élevé au plus faible) est le suivant : service Kubernetes, ServiceEntry Istio et GCPBackend.

Notez que le service virtuel et le GCPBackend doivent se trouver dans le même espace de noms.