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

Cette page explique comment acheminer de manière sécurisée le trafic réseau des charges de travail Cloud Service Mesh sur GKE vers une VM Compute Engine située devant un BackendService.

Notez que lorsque vous routez le trafic de GKE vers une VM Compute Engine, il n'est pas nécessaire que la VM Compute Engine ou le BackendService rejoignent Cloud Service Mesh. Toutefois, la VM Compute Engine et le BackendService doivent se trouver dans le même projet que le cluster GKE Cloud Service Mesh. Cette limite existe tant que cette fonctionnalité est disponible en version Preview publique. MTLS non 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. Vous avez déployé une VM Compute Engine qui est précédée d'un BackendService.

Vous pouvez également exécuter les commandes suivantes pour déployer un exemple de VM Compute Engine avec 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. GCPBackend se compose des éléments suivants :

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

GCPBackend contient le nom d'hôte et les informations sur le port, ainsi que les informations sur 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 soit résolvable par DNS dans le cluster (par défaut, il ne l'est pas), vous devez configurer Google Cloud DNS pour résoudre tous les hôtes sous un nom d'hôte choisi en une adresse IP arbitraire. Tant que vous n'aurez pas configuré cette entrée DNS, la requête échouera. 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 soit résolvable :

    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 bas) est le suivant : service Kubernetes, istio ServiceEntry et GCPBackend.

Notez que le service virtuel et le GCPBackend doivent se trouver dans le même espace de noms, et que la VM Compute Engine doit se trouver dans le même projet que le cluster GKE Cloud Service Mesh.