Enruta el tráfico de las cargas de trabajo de Cloud Service Mesh a la VM de Compute Engine
En esta página, se muestra cómo enrutar de forma segura el tráfico de red de las cargas de trabajo de Cloud Service Mesh en GKE a la VM de Compute Engine con un BackendService.
Ten en cuenta que, cuando enrutas el tráfico de GKE a una VM de Compute Engine, no es necesario que la VM de Compute Engine o BackendService se unan a la malla de servicios de Cloud. Sin embargo, la VM de Compute Engine y BackendService deben estar en el mismo proyecto que el clúster de GKE de Service Mesh de Cloud. Esta limitación existe mientras la función está disponible en la versión preliminar pública. MTLS no es compatible con las VMs de Compute Engine
Antes de comenzar
En las siguientes secciones, se da por sentado que ya hiciste lo siguiente:
- Un clúster de GKE con Cloud Service Mesh habilitado
- Implementaste una VM de Compute Engine que tiene un BackendService.
Como alternativa, puedes ejecutar los siguientes comandos para implementar una VM de Compute Engine de muestra con un BackendService como proxy.
Implementa una VM de Compute Engine y BackendService de muestra:
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
Aquí:
- VM_ZONE es la zona en la que deseas que se implemente tu VM de Compute Engine.
Configura una VM de Compute Engine como GCPBackend
En esta sección, expones la VM de Compute Engine a las cargas de trabajo de GKE con GCPBackend. GCPBackend consta de lo siguiente:
- Información del frontend, específicamente, el nombre de host y el puerto que usaría GKE Workloads para llamar a este GCPBackend.
- Información del backend: los detalles de BackendService, como el nombre del servicio, la ubicación y el número de proyecto
GCPBackend contiene los detalles del nombre de host y el puerto, así como los detalles de BackendService (nombre del servicio, ubicación y número de proyecto). Las cargas de trabajo de GKE deben usar el nombre de host y el puerto de GCPBackend en sus solicitudes HTTP para acceder a la VM de Compute Engine.
Para que el DNS del nombre de host se pueda resolver dentro del clúster (de forma predeterminada, no se puede resolver), debes configurar el DNS de Google Cloud para que resuelva todos los hosts de un nombre de host elegido en una dirección IP arbitraria. La solicitud fallará hasta que configures esta entrada de DNS. La Google Cloud configuración de DNS es una configuración única por dominio personalizado.
Crea una zona administrada:
gcloud dns managed-zones create prod \ --description="zone for gcpbackend" \ --dns-name=gcpbackend \ --visibility=private \ --networks=default
En este ejemplo, el nombre de DNS es gcpbackend y la red de VPC es default.
Configura el registro para que el dominio se pueda resolver:
gcloud beta dns record-sets create *.gcpbackend \ --ttl=3600 --type=A --zone=prod \ --rrdatas=10.0.0.1
Crea GCPBackend con un nombre de host en el dominio anterior:
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
En este ejemplo, GCP_BACKEND_NAME es
vm-gcp-backend
.Crea un pod de prueba para verificar la conectividad de GKE a la VM de 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
Ahora, tus cargas de trabajo de GKE pueden acceder a la VM de Compute Engine enviando solicitudes HTTP a hello-world.gcpbackend:80.
Debes usar nombres distintos para GCPBackend para evitar conflictos con los servicios existentes de Kubernetes o las entradas de servicio de Istio. Si hay un conflicto, el orden de prioridad (de alto a bajo) es el servicio de Kubernetes, ServiceEntry de Istio y GCPBackend.
Ten en cuenta que el servicio virtual y GCPBackend deben estar en el mismo espacio de nombres, y la VM de Compute Engine debe estar en el mismo proyecto que el clúster de GKE de Cloud Service Mesh.