Dirigir el tráfico de cargas de trabajo de Cloud Service Mesh a una máquina virtual de Compute Engine
En esta página se muestra cómo enrutar de forma segura el tráfico de red desde cargas de trabajo de Cloud Service Mesh en GKE a una VM de Compute Engine protegida por un BackendService.
Ten en cuenta que, al enrutar el tráfico de GKE a una VM de Compute Engine, no es necesario que la VM de Compute Engine ni BackendService se unan a Cloud Service Mesh. Sin embargo, la VM de Compute Engine y el BackendService deben estar en el mismo proyecto que el clúster de GKE de Cloud Service Mesh. Esta limitación se aplica mientras esta función está disponible en la versión preliminar pública. MTLS no es compatible con las VMs de Compute Engine
Antes de empezar
En las siguientes secciones se presupone que tienes lo siguiente:
- Un clúster de GKE con Cloud Service Mesh habilitado.
- Has desplegado una VM de Compute Engine que tiene un BackendService delante.
También puedes ejecutar los siguientes comandos para desplegar una VM de Compute Engine de ejemplo con un BackendService.
Despliega una VM de Compute Engine y un 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
Donde:
- VM_ZONE es la zona en la que quieres que se implemente tu VM de Compute Engine.
Configurar una VM de Compute Engine como GCPBackend
En esta sección, expondrás la VM de Compute Engine a las cargas de trabajo de GKE mediante GCPBackend. GCPBackend consta de lo siguiente:
- Información del frontend, concretamente el nombre de host y el puerto que usarían las cargas de trabajo de GKE para llamar a este GCPBackend.
- Información de backend: 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 del 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 en el clúster (de forma predeterminada, no se puede), debes configurar el DNS para que resuelva todos los hosts con un nombre de host elegido en una dirección IP arbitraria. Google Cloud Hasta que no configures esta entrada DNS, la solicitud fallará. La configuración de DNS es un proceso que se realiza una sola vez por cada dominio personalizado. Google Cloud
Crea una zona gestionada:
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 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 el 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 de Kubernetes o las entradas de servicio de Istio. Si hay un conflicto, el orden de precedencia (de mayor a menor) es Kubernetes Service, Istio ServiceEntry y GCPBackend.
Ten en cuenta que el servicio virtual y el GCPBackend deben estar en el mismo espacio de nombres, y que la VM de Compute Engine debe estar en el mismo proyecto que el clúster de GKE de Cloud Service Mesh.