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 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 su y las políticas de tráfico en un proyecto centralizado. con extremos de backend en proyectos diferentes.
En una implementación de varios proyectos, puedes administrar todos tus recursos de procesamiento (VMs de Compute Engine, NEG de GKE, etc.) en una única instancia proyectos de Google Cloud, mientras que los equipos de servicios son propietarios de su propio servicio de Google Cloud proyectos en los que definen las políticas de servicio expresadas en BackendServices y las Rutas de enrutamiento de servicio en sus respectivos proyectos de servicio. Este delegado administran sus servicios mientras mantienen un control estricto sobre la recursos que pueden compartirse entre distintos equipos de servicio.

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). Lo siguiente En este ejemplo, se configuran VMs de carga de trabajo en la red de VPC predeterminada en el proyecto de carga de trabajo. y demuestra que el cliente puede enrutar en el proyecto de carga de trabajo según los parámetros de configuración en el proyecto de políticas.

Ejemplo de NEG entre proyectos 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

Las limitaciones generales de Traffic Director y Limitaciones de BackendConfig/NetworkEndpointGroup aplicar.

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 los NEG zonales del tipo GCP_VM_IP_PORT.
No se admite la referencia de BackendServices entre proyectos a grupos de instancias (administrados o no administrados).
Enumerar los NEG entre proyectos que se pueden conectar a un BackendService determinado es no es compatible.
No se enumera la lista de BackendServices entre proyectos que usan un NEG específico no es compatible.

Antes de comenzar

Debes completar los siguientes requisitos previos antes de poder configurar varios proyectos NEG de conectividad híbrida.

Habilite las API necesarias

Se requieren las siguientes APIs para completar esta guía:

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 el rol de proyecto Propietario o editor (roles/owner o roles/editor) en el proyecto en el que habilitas Cloud Service Mesh, tienes automáticamente permisos.

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 el Documentación de IAM de Compute Engine

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

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 función 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 de Traffic Director (como el proxy de Envoy) deben tener los permisos en 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. en un proyecto final.

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

Ejecuta el siguiente comando para apuntar tu Google Cloud CLI al proyecto de políticas y establece la zona de procesamiento preferida de Google Cloud:
```
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. Para los fines de la demostración, la 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 sondeos de verificación de estado a 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: gcr.io/google-samples/whereami:v1.2.20
        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 del servicio en cada zona. En este ejemplo, el nombre del NEG se codificado como 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 eliges $NEG_LINK como ejemplo, debería verse de la siguiente manera:
```
$ echo ${NEG_LINK}
https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
```
Como alternativa, puedes recuperar la URL de NEG mediante la lectura del estado 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 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 a la 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 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

En el ejemplo anterior, 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 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 parámetros de configuración asociados con la malla recurso 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 la ruta de malla entre proyectos