Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Configurer un groupe de points de terminaison du réseau inter-projets

La fonctionnalité de groupe de points de terminaison du réseau (NEG) inter-projets permet aux clients associer des NEG d'un autre projet à un cluster Traffic Director/Cloud Service Mesh BackendService, permettant les cas d'utilisation suivants:

Dans un déploiement multiprojet, BackendServices ainsi que les règles de routage et de trafic associées dans un projet centralisé, avec des points de terminaison backend de différents projets.
Dans un déploiement multiprojet, vous pouvez gérer toutes vos ressources de calcul (VM Compute Engine, NEG GKE, etc.) dans un seul projet Google Cloud centralisé, tandis que les équipes de service possèdent leurs propres projets de service Google Cloud dans lesquels elles définissent des règles de service exprimées en BackendServices et des routes de routage de service dans leur projet de service respectif. Cela délègue tout en contrôlant étroitement les ressources de calcul de ressources pouvant être partagées entre différentes équipes de service.

Cette page vous explique comment créer une configuration de référence à deux projets dans lequel le NEG dans le projet A (appelé "projet de charge de travail") est associé au BackendService dans le projet B (appelé projet de stratégie). L'exemple suivant configure les VM de charge de travail dans le réseau VPC par défaut du projet de charge de travail et montre que le client peut acheminer vers le projet de charge de travail en fonction des configurations du projet de règles.

Exemple de NEG inter-projets de référence

Dans une configuration plus sophistiquée, une solution telle que le VPC partagé est requise pour un plan de données interconnecté entre plusieurs projets. Cela implique également que les points de terminaison NEG ont des adresses IP uniques. Cet exemple de configuration peut être étendu à des scénarios plus complexes où les charges de travail se trouvent dans un réseau VPC partagé couvrant plusieurs projets.

Limites

Limites générales de Traffic Director et les limites de BackendService/NetworkEndpointGroup s'appliquent.

Les limites suivantes s'appliquent également, mais ne sont pas nécessairement spécifiques à une configuration multiprojet :

Un objet BackendService ne peut accepter qu'un maximum de 50 backends(NEG et MIG compris).
Seuls les NEG zonaux de type GCP_VM_IP_PORT sont acceptés.
Le référencement interprojet des BackendServices aux groupes d'instances (gérés ou non gérés) n'est pas accepté.
La liste des NEG interprojets pouvant être associés à un BackendService donné n'est pas prise en charge.
Répertorier les BackendServices inter-projets qui utilisent un NEG spécifique n'est pas compatibles.

Avant de commencer

Vous devez remplir les conditions préalables suivantes avant de pouvoir configurer des NEG multiprojets.

Activer les API requises

Les API suivantes sont nécessaires pour terminer ce guide:

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

Exécutez la commande suivante pour activer les API requises dans la charge de travail et le projet de stratégie:

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

Accorder les autorisations Cloud IAM requises

Vous devez disposer des autorisations IAM (Identity and Access Management) suffisantes pour effectuer cette opération . Si vous disposez du rôle de propriétaire ou d'éditeur (roles/owner ou roles/editor) pour le projet dans lequel vous activez Cloud Service Mesh, vous disposez automatiquement des autorisations appropriées.

Sinon, vous devez attribuer tous les rôles IAM suivants. Si vous disposent de ces rôles, vous disposez également des autorisations qui leur sont associées, comme décrit dans la Documentation IAM de Compute Engine

Les rôles suivants sont requis à la fois dans les projets de charge de travail et de stratégie:

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

Les rôles suivants ne sont requis que dans le projet de charge de travail:

roles/compute.securityAdmin
roles/container.admin
Tout rôle comprenant les autorisations suivantes Le rôle prédéfini le plus précis qui inclut toutes les autorisations requises pour associer un NEG à un BackendService est roles/compute.loadBalancerServiceUser.
- compute.networkEndpointGroups.get
- compute.networkEndpointGroups.use

De plus, les clients xDS gérés par Traffic Director (comme le proxy Envoy) doivent avoir les autorisations sous roles/trafficdirector.client. À titre de démonstration, vous pouvez utiliser la commande suivante pour accorder cette autorisation dans le projet de stratégie au compte de service Compute par défaut du projet de charge de travail:

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

Où :

POLICY_PROJECT_ID est l'ID du projet de stratégie.
WORKLOAD_PROJECT_NUMBER est le numéro du projet de la charge de travail.

Configurer un backend de service dans le projet de charge de travail

Exécutez la commande suivante pour diriger votre Google Cloud CLI vers le projet de règles et définir la zone de calcul Google Cloud préférée :
```
gcloud config set project WORKLOAD_PROJECT_ID
gcloud config set compute/zone ZONE
```
Où :
- WORKLOAD_PROJECT_ID est l'ID du projet de charge de travail.
- ZONE est la zone du cluster GKE, Exemple : us-central1.
créer un cluster GKE ; À des fins de démonstration, crée un cluster GKE zonal. Toutefois, cette fonctionnalité fonctionne également sur les clusters GKE régionaux.
```
gcloud container clusters create test-cluster \
    --scopes=https://www.googleapis.com/auth/cloud-platform
    --zone=ZONE
```

Créez une règle de pare-feu :

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

Une règle de pare-feu permet au plan de contrôle Google Cloud d'envoyer la vérification de l'état sur les backends du réseau VPC par défaut.

Remplacez le contexte actuel de kubectl par le cluster que vous venez de créer:

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

Créez et déployez l'exemple d'application "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

Exécutez la commande suivante pour stocker la référence au NEG dans une variable:
```
NEG_LINK=$(gcloud compute network-endpoint-groups describe example-neg --format="value(selfLink)")
```
Le contrôleur NEG crée automatiquement un NetworkEndpointGroup zonal pour les backends de service dans chaque zone. Dans cet exemple, le nom du NEG est example-neg. L'enregistrer en tant que variable sera utile lors de la prochaine session lorsque vous associerez ce NEG à un BackendService dans le projet de règles.

Si vous utilisez $NEG_LINK, il doit ressembler à ceci :
```
$ echo ${NEG_LINK}
https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
```
Vous pouvez également récupérer l'URL du NEG en lisant la colonne neg-status sur le service:
```
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"
```

Configurer les ressources réseau Google Cloud dans le projet de règles

Faites pointer votre Google Cloud CLI vers le projet de stratégie:
```
gcloud config set project POLICY_PROJECT_ID
```
Configure une ressource de réseau maillé:
```
gcloud network-services meshes import example-mesh --source=- --location=global << EOF
name: example-mesh
EOF
```
Le nom de la ressource de maillage est la clé utilisée par les proxy side-car pour demander la configuration du service de maillage.

Configurez un BackendService de référence avec une vérification de l'état:

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

Associe le NetworkEndpointGroup créé dans la section précédente au BackendService :

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

Créez un HTTPRoute pour rediriger toutes les requêtes HTTP avec l'en-tête d'hôte example-service vers le serveur du projet de charge de travail :

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

où POLICY_PROJECT_NUMBER est le numéro du projet de stratégie.

Valider la configuration

Vous pouvez vérifier la configuration en envoyant une requête HTTP avec l'en-tête HOST défini sur example-service à une adresse VIP derrière un proxy side-car géré par Traffic Director :

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

Le résultat est semblable à :

{"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"}

Notez que, puisque tout le trafic sortant des pods est intercepté par un nœud Envoy, dans un maillage de services, et que l'instance HTTPRoute précédente est configurée pour envoyer tout le trafic vers "whereami" un service Kubernetes entièrement basé sur (en-tête host). Par exemple, l'adresse IP virtuelle dans cette commande est 10.0.0.1, mais l'IPV peut être n'importe quelle adresse IP.

Le proxy side-car doit demander les configurations associées au réseau maillé dans le projet de stratégie. Pour cela, assurez-vous que l'ID du nœud est défini dans le le format suivant:

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

Étape suivante

Configurer une route maillée inter-projets