Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la información general sobre Cloud Service Mesh.

Esta página se ha traducido con Cloud Translation API.

Configurar un grupo de endpoints de red entre proyectos

La función de grupo de puntos finales de red (NEG) entre proyectos permite a los clientes adjuntar NEGs de un proyecto diferente a Traffic Director o Cloud Service MeshBackendService, lo que habilita los siguientes casos prácticos:

En un despliegue de varios proyectos, BackendServices junto con sus políticas de enrutamiento y tráfico asociadas en un proyecto centralizado, con endpoints de backend de diferentes proyectos.
En una implementación de varios proyectos, puedes gestionar todos tus recursos de computación (VMs de Compute Engine, NEGs de GKE, etc.) en un único proyecto centralGoogle Cloud mientras que los equipos de servicio tienen sus propios proyectos de servicio Google Cloud , donde definen las políticas de servicio expresadas en BackendServices y las rutas de enrutamiento de servicio en sus respectivos proyectos de servicio. De esta forma, se delega la gestión de sus servicios y, al mismo tiempo, se mantiene un control estricto sobre los recursos de computación, que pueden compartirse entre diferentes equipos de servicio.

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

Ejemplo de NEG entre proyectos de referencia

En una configuración más sofisticada, se necesita una solución como la VPC compartida para un plano de datos interconectado en varios proyectos. Esto también implica que los puntos finales de NEG tienen IPs únicas. Esta configuración de ejemplo se puede ampliar a escenarios más complejos en los 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 o NetworkEndpointGroup.

También se aplican las siguientes limitaciones, aunque no sean específicas de una configuración de varios proyectos:

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

Antes de empezar

Debes completar los siguientes requisitos previos para poder configurar NEGs entre proyectos.

Habilitar las APIs necesarias

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

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

Ejecuta el siguiente comando para habilitar las APIs necesarias tanto en el proyecto de carga de trabajo como en el proyecto de política:

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

Conceder los permisos de gestión de identidades y accesos necesarios

Debes tener permisos de gestión de identidades y accesos (IAM) suficientes para completar esta guía. Si tienes el rol de propietario o editor (roles/owner o roles/editor) del proyecto en el que vas a habilitar Cloud Service Mesh, tendrás automáticamente los permisos correctos.

De lo contrario, debes conceder todos los roles de gestión de identidades y accesos siguientes. Si tienes estos roles, también tienes los permisos asociados, tal como se describe en la documentación de gestión de identidades y accesos de Compute Engine.

Los siguientes roles son obligatorios tanto en los proyectos de cargas de trabajo como en los de políticas:

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

Solo se necesitan los siguientes roles 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 granular que incluye todos los permisos necesarios para asociar un NEG a un BackendService es roles/compute.loadBalancerServiceUser.
- compute.networkEndpointGroups.get
- compute.networkEndpointGroups.use

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

gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member "serviceAccount:WORKLOAD_PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role "roles/trafficdirector.client"

donde

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

Configurar un backend de servicio en el proyecto de carga de trabajo

Ejecuta el siguiente comando para dirigir la CLI de Google Cloud al proyecto de carga de trabajo y definir la Google Cloud zona de cálculo preferida:
```
gcloud config set project WORKLOAD_PROJECT_ID
gcloud config set compute/zone ZONE
```
donde
- WORKLOAD_PROJECT_ID es el ID del proyecto de carga de trabajo.
- ZONE es la zona del clúster de GKE, por ejemplo, us-central1.
Crea un clúster de GKE. Para hacer una demostración, el siguiente comando crea un clúster de GKE de zona. Sin embargo, esta función también funciona en clústeres de GKE regionales.
```
gcloud container clusters create test-cluster \
    --scopes=https://www.googleapis.com/auth/cloud-platform
    --zone=ZONE
```

Crea una regla de cortafuegos:

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 cortafuegos permite que el Google Cloud plano de control envíe sondeos de comprobación del estado a los backends de la red de VPC predeterminada.

Cambia el contexto actual de kubectl al clúster que acabas de crear:

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

Crea e implementa la aplicación de ejemplo 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

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 de cada zona. En este ejemplo, el nombre del NEG se ha codificado como example-neg. Almacenarlo como una variable será útil en la siguiente sesión, cuando adjunte este NEG a un BackendService en el proyecto de la política.

Si pones como ejemplo $NEG_LINK, debería tener un aspecto similar al siguiente:
```
$ echo ${NEG_LINK}
https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
```
También puedes obtener la URL del NEG leyendo la anotación neg-status del 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"
```

Configurar recursos de red en el proyecto de política Google Cloud

Dirige Google Cloud CLI al proyecto de la política:
```
gcloud config set project POLICY_PROJECT_ID
```
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 sidecar para solicitar la configuración de la malla de servicios.

Configura una línea de base BackendService con una comprobación del 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

Asigna 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

Crea un 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 de proyecto del proyecto de la política.

Verificar la configuración

Para verificar la configuración, envía una solicitud HTTP con el encabezado HOST definido como example-service a una IP virtual detrás de un proxy sidecar gestionado por Traffic Director:

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

La salida es similar a la 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, como todo el tráfico saliente de los pods se intercepta mediante un sidecar de Envoy en una malla de servicios, y la HTTPRoute anterior se ha configurado para enviar todo el tráfico al servicio de Kubernetes "whereami" basándose únicamente en el atributo de la capa 7 (encabezado Host). A modo de ejemplo, la IP virtual de este comando es 10.0.0.1, pero puede ser cualquier IP.

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

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

Siguientes pasos

Configurar una ruta de malla entre proyectos