Configura un grupo de extremos de red entre proyectos

Nota: Esta guía solo admite Cloud Service Mesh con APIs de Google Cloud y no admite APIs de Istio. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Vista previa

Este producto o función se encuentra sujeto a las "Condiciones de la Oferta de la Fase Previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles "sin modificaciones" y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

La función de grupo de extremos de red (NEG) entre proyectos permite a los clientes adjuntar NEG de un proyecto diferente a un BackendService de Traffic Director o Cloud Service Mesh, lo que habilita los siguientes casos de uso:

• En una implementación de varios proyectos, BackendServices junto con sus políticas de enrutamiento y tráfico asociadas en un proyecto centralizado, con extremos de backend de diferentes proyectos.

• En una implementación de varios proyectos, puedes administrar todos tus recursos de procesamiento (VMs de Compute Engine, NEG de GKE, etcétera) en un solo proyecto central deGoogle Cloud , mientras que los equipos de servicio son propietarios de sus propios proyectos de servicio de Google Cloud , en los que definen políticas de servicio expresadas en BackendServices y rutas de enrutamiento de servicio en sus respectivos proyectos de servicio. Esto delega la administración de sus servicios y, al mismo tiempo, mantiene un control estricto sobre los recursos de procesamiento que pueden compartirse entre diferentes equipos de servicio.

En esta página, se muestra cómo crear una configuración básica de 2 proyectos en la que el NEG del proyecto A (denominado proyecto de carga de trabajo) se adjunta al BackendService del proyecto B (denominado proyecto de política). En el siguiente ejemplo, se configuran VMs de carga de trabajo en la red de VPC predeterminada del proyecto de carga de trabajo y se demuestra que el cliente puede enrutar al proyecto de carga de trabajo en función de las configuraciones del proyecto de política.

En una configuración más sofisticada, se requiere una solución como la VPC compartida para un plano de datos interconectado en varios proyectos. Esto también implica que los extremos del NEG tienen IPs únicas. Este ejemplo de configuración se puede extender a situaciones más complicadas en las que las cargas de trabajo se encuentran en una red de VPC compartida que abarca varios proyectos.

Limitaciones

Se aplican las limitaciones generales de Traffic Director y las limitaciones de BackendService/NetworkEndpointGroup.

También se aplican las siguientes limitaciones, pero es posible que no sean específicas para una configuración de varios proyectos:

• Un solo BackendService solo puede admitir hasta 50 backends(incluidos los NEG y los MIG).
• Solo se admiten los NEG zonales de tipo GCP_VM_IP_PORT.
• No se admite la referencia entre proyectos de BackendServices a grupos de instancias (administrados o no administrados).
• No se admite la enumeración de los NEG entre proyectos que se pueden conectar a un BackendService determinado.
• No se admite la enumeración de BackendServices entre proyectos que usan un NEG específico.

Antes de comenzar

Debes completar los siguientes requisitos previos antes de configurar los NEG entre proyectos.

Habilite las API necesarias

Para completar esta guía, se requieren las siguientes APIs:

• osconfig.googleapis.com
• trafficdirector.googleapis.com
• compute.googleapis.com
• networkservices.googleapis.com

Ejecuta el siguiente comando para habilitar las APIs requeridas en el proyecto de la carga de trabajo y en el proyecto de la política:

gcloud services enable --project PROJECT_ID \
    osconfig.googleapis.com \
    trafficdirector.googleapis.com \
    compute.googleapis.com \
    networkservices.googleapis.com

Otorga los permisos de IAM necesarios

Debes tener suficientes permisos de Identity and Access Management (IAM) para completar esta guía. Si tienes el rol de propietario o editor (roles/owner o roles/editor) en el proyecto en el que habilitarás Cloud Service Mesh, obtendrás automáticamente los permisos correctos.

De lo contrario, debes otorgar todos los siguientes roles de IAM. Si tienes estos roles, también tienes sus permisos asociados, como se describe en la documentación de IAM de Compute Engine.

Se requieren los siguientes roles en ambos proyectos de política y carga de trabajo:

• roles/iam.serviceAccountAdmin
• roles/serviceusage.serviceUsageAdmin
• roles/compute.networkAdmin

Los siguientes roles solo son obligatorios en el proyecto de carga de trabajo:

• roles/compute.securityAdmin
• roles/container.admin
• Cualquier rol que incluya los siguientes permisos El rol predefinido más detallado que incluye todos los permisos necesarios para adjuntar un NEG a un BackendService es roles/compute.loadBalancerServiceUser.
  • compute.networkEndpointGroups.get
  • compute.networkEndpointGroups.use

Además, los clientes xDS administrados por Traffic Director (como el proxy de Envoy) deben tener los permisos que se indican en roles/trafficdirector.client. A modo de demostración, puedes usar el siguiente comando para otorgar este permiso en el proyecto de política a la cuenta de servicio predeterminada de Compute del proyecto de carga de trabajo:

gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member "serviceAccount:[e-mail]" \
    --role "roles/trafficdirector.client"

donde

• POLICY_PROJECT_ID es el ID del proyecto de la política.
• WORKLOAD_PROJECT_NUMBER es el número del proyecto de la carga de trabajo.

Configura un backend de servicio en el proyecto de la carga de trabajo

1. Ejecuta el siguiente comando para dirigir tu Google Cloud CLI al proyecto de política y establecer la zona de procesamiento Google Cloud preferida:

   gcloud config set project WORKLOAD_PROJECT_ID
   gcloud config set compute/zone ZONE
   

   donde

   • WORKLOAD_PROJECT_ID es el ID del proyecto de la carga de trabajo.
   • ZONE es la zona del clúster de GKE, por ejemplo, us-central1.

2. Crear un clúster de GKE A modo de demostración, el siguiente comando crea un clúster de GKE zonal. Sin embargo, esta función también funciona en clústeres regionales de GKE.

   gcloud container clusters create test-cluster \
       --scopes=https://www.googleapis.com/auth/cloud-platform
       --zone=ZONE
   

3. Crea una regla de firewall:

   gcloud compute firewall-rules create http-allow-health-checks \
       --network=default \
       --action=ALLOW \
       --direction=INGRESS \
       --source-ranges=35.191.0.0/16,130.211.0.0/22 \
       --rules=tcp:80
   

   Una regla de firewall permite que el plano de control de Google Cloud envíe sondeos de verificación de estado a los backends en la red de VPC predeterminada.

4. Cambia el contexto actual de kubectl al clúster recién creado:

   gcloud container clusters get-credentials test-cluster \
       --zone=ZONE
   

5. Crea e implementa la app de ejemplo de Whereami:

   kubectl apply -f - <<EOF
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: whereami
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: whereami
     template:
       metadata:
         labels:
           app: whereami
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
           ports:
           - containerPort: 8080
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: whereami
     annotations:
       cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-neg"}}}'
   spec:
     selector:
       app: whereami
     ports:
     - port: 8080
       targetPort: 8080
   EOF
   

6. Ejecuta el siguiente comando para almacenar la referencia al NEG en una variable:

   NEG_LINK=$(gcloud compute network-endpoint-groups describe example-neg --format="value(selfLink)")
   

   El controlador de NEG crea automáticamente un NetworkEndpointGroup zonal para los backends de servicio en cada zona. En este ejemplo, el nombre del NEG está codificado como example-neg. Almacenarlo como una variable será útil en la próxima sesión cuando adjuntes este NEG a un BackendService en el proyecto de política.

   Si ejemplificas $NEG_LINK, debería verse similar a lo siguiente:

   $ echo ${NEG_LINK}
   https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
   

   Como alternativa, puedes recuperar la URL del NEG leyendo la anotación neg-status en el servicio:

   kubectl get service whereami -o jsonpath="{.metadata.annotations['cloud\.google\.com/neg-status']}"
   NEG_LINK="https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT_ID/zones/ZONE/networkEndpointGroups/example-neg"
   

Configura Google Cloud recursos de redes en el proyecto de política

1. Dirige tu Google Cloud CLI al proyecto de política:

   gcloud config set project POLICY_PROJECT_ID
   

2. Configura un recurso de malla:

   gcloud network-services meshes import example-mesh --source=- --location=global << EOF
   name: example-mesh
   EOF
   

   El nombre del recurso de malla es la clave que usan los proxies de sidecar para solicitar la configuración de la malla de servicios.

3. Configura un BackendService de referencia con una verificación de estado:

   gcloud compute health-checks create http http-example-health-check
   
   gcloud compute backend-services create example-service \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --protocol=HTTP \
     --health-checks http-example-health-check
   

4. Adjunta el NetworkEndpointGroup creado en la sección anterior al BackendService:

   gcloud compute backend-services add-backend example-service --global \
     --network-endpoint-group=${NEG_LINK} \
     --balancing-mode=RATE \
     --max-rate-per-endpoint=5
   

5. Crea un objeto HTTPRoute para dirigir todas las solicitudes HTTP con el encabezado de host example-service al servidor del proyecto de carga de trabajo:

   gcloud network-services http-routes import example-route --source=- --location=global << EOF
   name: example-route
   hostnames:
   - example-service
   meshes:
   - projects/POLICY_PROJECT_NUMBER/locations/global/meshes/example-mesh
   rules:
   - action:
       destinations:
       - serviceName: "projects/POLICY_PROJECT_NUMBER/locations/global/backendServices/example-service"
   EOF
   

   donde POLICY_PROJECT_NUMBER es el número del proyecto de la política.

Verifique la configuración

Para verificar la configuración, envía una solicitud HTTP con el encabezado HOST establecido en example-service a una VIP detrás de un proxy de sidecar administrado por Traffic Director:

curl -H "Host: example-service" http://10.0.0.1/

El resultado es similar al siguiente:

{"cluster_name":"test-cluster","gce_instance_id":"4879146330986909656","gce_service_account":"...","host_header":"example-service","pod_name":"whereami-7fbffd489-nhkfg","pod_name_emoji":"...","project_id":"...","timestamp":"2024-10-15T00:42:22","zone":"us-west1-a"}

Ten en cuenta que, dado que todo el tráfico saliente de los Pods es interceptado por un Envoy sidecar en una malla de servicios, y la HTTPRoute anterior está configurada para enviar todo el tráfico al servicio de Kubernetes "whereami" únicamente en función del atributo de L7 (encabezado de host). A modo de ejemplo, la VIP en este comando es 10.0.0.1, pero puede ser cualquier IP.

El proxy de sidecar debe solicitar las configuraciones asociadas con el recurso de malla en el proyecto de política. Para ello, asegúrate de que el ID del nodo esté configurado con el siguiente formato:

projects/POLICY_PROJECT_NUMBER/networks/mesh:example-mesh/nodes/UUID"

¿Qué sigue?

• Configura una ruta de malla entre proyectos