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

Se usó la API de Cloud Translation para traducir esta página.

Configura un grupo de extremos de red entre proyectos

La función de grupo de extremos de red (NEG) entre proyectos permite a los clientes vincular 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 (VM de Compute Engine, NEG de GKE, etcétera) en un solo proyecto central deGoogle Cloud , mientras que los equipos de servicios poseen sus propios proyectos de servicio Google Cloud en los que definen las políticas de servicio expresadas en BackendServices y las rutas de enrutamiento de servicios en su respectivo proyecto de servicio. Esto delega la administración de sus servicios y, al mismo tiempo, mantiene un control estricto sobre los recursos de procesamiento que se pueden compartir entre diferentes equipos de servicios.

En esta página, se muestra cómo crear una configuración de referencia 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 en el proyecto de carga de trabajo según las configuraciones del proyecto de política.

Ejemplo de NEG de varios proyectos del modelo de referencia

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. Esta configuración de ejemplo 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 NEG y MIG).
Solo se admiten NEG zonales de tipo GCP_VM_IP_PORT.
No se admite la referencia de BackendServices entre proyectos a grupos de instancias (administrados o no administrados).
No se admite la enumeración de NEG entre proyectos que se pueden adjuntar 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 para poder configurar 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 carga de trabajo y en el proyecto de políticas:

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 la función de propietario o editor (roles/owner o roles/editor) en el proyecto en el que habilitarás Cloud Service Mesh, obtendrás todos los permisos correctos automáticamente.

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íticas y cargas 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 conectar un NEG a un BackendService es roles/compute.loadBalancerServiceUser.
- compute.networkEndpointGroups.get
- compute.networkEndpointGroups.use

Además, los clientes de xDS administrados por Traffic Director (como el proxy de Envoy) deben tener los permisos de roles/trafficdirector.client. A modo de demostración, puedes usar el siguiente comando para otorgar este permiso en el proyecto de políticas a la cuenta de servicio de procesamiento 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 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 carga de trabajo

Ejecuta el siguiente comando para dirigir Google Cloud CLI al proyecto de políticas y establecer la zona de procesamiento de 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.
Crea 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 de GKE regionales.
```
gcloud container clusters create test-cluster \
    --scopes=https://www.googleapis.com/auth/cloud-platform
    --zone=ZONE
```

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 sondas de verificación de estado a los backends en la red de VPC predeterminada.

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

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

Crea y, luego, 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

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 en example-neg. Almacenarlo como una variable será útil en la próxima sesión cuando vincules este NEG a un BackendService en el proyecto de políticas.

Si usas $NEG_LINK como ejemplo, 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 leer la anotación neg-status en el servicio para recuperar la URL del NEG:
```
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 los recursos de red de Google Cloud en el proyecto de políticas

Dirige Google Cloud CLI al proyecto de políticas:
```
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 de Sidecar para solicitar la configuración de la malla de servicios.

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

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

Crea una HTTPRoute para dirigir todas las solicitudes HTTP con el encabezado de host example-service al servidor en el 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 políticas.

Verifique la configuración

Para verificar la configuración, envía una solicitud HTTP con el encabezado HOST configurado en example-service a un 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, como un contenedor lateral de Envoy intercepta todo el tráfico saliente de los Pods en una malla de servicios, y la HTTPRoute anterior está configurada para enviar todo el tráfico al servicio de Kubernetes "whereami" solo en función del atributo 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 configuraciones asociadas con el recurso de malla en el proyecto de políticas. Para ello, asegúrate de que el ID del nodo esté configurado en el siguiente formato:

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

¿Qué sigue?

Configura una ruta de malla entre proyectos