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) interprojets permet aux clients d'associer des NEG d'un autre projet à un BackendService Traffic Director/Cloud Service Mesh, ce qui permet 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 projetGoogle Cloud centralisé, tandis que les équipes de service possèdent leurs propres projets de service Google Cloud dans lesquels elles définissent des stratégies de service exprimées en BackendServices et des routes de routage de service dans leur projet de service respectif. Cela permet de déléguer la gestion de leurs services tout en maintenant un contrôle strict sur les ressources de calcul pouvant être partagées entre différentes équipes de services.

Cette page explique comment créer une configuration de référence à deux projets dans laquelle le NEG du projet A (appelé projet de charge de travail) est associé au BackendService du projet B (appelé projet de règles). 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

Pour 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

Les 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 seul BackendService ne peut prendre en charge que 50 backends(y compris les NEG et les MIG).
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.
Il n'est pas possible de lister les BackendServices interprojets qui utilisent un NEG spécifique.

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 requises pour suivre 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 le projet de charge de travail et le projet de règles:

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 d'autorisations IAM (Identity and Access Management) suffisantes pour suivre ce guide. 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. Avec ces rôles, vous disposez alors également des autorisations associées, comme décrit dans la documentation IAM de Compute Engine.

Les rôles suivants sont requis à la fois pour les projets de charge de travail et de règles:

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

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

roles/compute.securityAdmin
roles/container.admin
Tout rôle incluant 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 disposer des autorisations sous roles/trafficdirector.client. À des fins 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 règles.
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 stratégie 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 correspond à l'ID du projet de charge de travail.
- ZONE correspond à la zone du cluster GKE, par exemple us-central1.
créer un cluster GKE ; À des fins de démonstration, la commande suivante 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 des sondes de vérification de l'état'état aux 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: 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

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 de chaque zone. Dans cet exemple, le nom du NEG est example-neg. Le stocker en tant que variable sera utile lors de la prochaine session lorsque vous attacherez 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 l'annotation 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 stratégie

Pointez votre Google Cloud CLI vers le projet de stratégie:
```
gcloud config set project POLICY_PROJECT_ID
```
Configure une ressource de maillage:
```
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 une 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 règles.

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 IP virtuelle 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, comme tout le trafic sortant des pods est intercepté par un sidecar Envoy dans un maillage de services, et que l'objet HTTPRoute précédent est configuré pour envoyer tout le trafic au service Kubernetes "whereami" uniquement en fonction de l'attribut L7 (en-tête d'hôte). À des fins d'exemple, l'adresse VIP de cette commande est 10.0.0.1, mais elle peut être n'importe quelle adresse IP.

Le proxy side-car doit demander les configurations associées à la ressource de maillage dans le projet de stratégie. Pour ce faire, assurez-vous que l'ID de nœud est défini au format suivant:

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

Étape suivante

Configurer un routage de réseau maillé interprojets