Projektübergreifende Netzwerk-Endpunktgruppe einrichten

Hinweis :In diesem Leitfaden wird nur Cloud Service Mesh mit Google Cloud APIs unterstützt. Istio APIs werden nicht unterstützt. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

Vorabversion

Dieses Produkt oder diese Funktion ist den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen unterworfen. Pre-GA-Produkte und ‑Funktionen sind „wie gesehen“ verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Mit der projektübergreifenden Netzwerk-Endpunktgruppenfunktion (NEG) können Kunden NEGs aus einem anderen Projekt an eine BackendService von Traffic Director/Cloud Service Mesh anhängen. Dies ermöglicht die folgenden Anwendungsfälle:

• Bei einer Bereitstellung mit mehreren Projekten werden BackendServices zusammen mit den zugehörigen Routing- und Trafficrichtlinien in einem zentralen Projekt mit Backend-Endpunkten aus verschiedenen Projekten bereitgestellt.

• Bei einer Bereitstellung mit mehreren Projekten können Sie alle Ihre Computeressourcen (Compute Engine-VMs, GKE-NEGs usw.) in einem zentralenGoogle Cloud -Projekt verwalten, während die Serviceteams ihre eigenen Google Cloud -Dienstprojekte besitzen, in denen sie Dienstrichtlinien definieren, die in BackendServices und Dienstrouting-Routen in ihrem jeweiligen Dienstprojekt ausgedrückt werden. Dadurch wird die Verwaltung ihrer Dienste delegiert, während sie die Rechenressourcen, die möglicherweise von verschiedenen Serviceteams gemeinsam genutzt werden, weiterhin genau im Blick behalten.

Auf dieser Seite erfahren Sie, wie Sie eine Baseline-Einrichtung mit zwei Projekten erstellen, bei der die NEG in Projekt A (dem Arbeitslastprojekt) an die BackendService in Projekt B (dem Richtlinienprojekt) angehängt wird. Im folgenden Beispiel werden Arbeitslast-VMs im Standard-VPC-Netzwerk im Arbeitslastprojekt eingerichtet. Außerdem wird gezeigt, dass der Client basierend auf den Konfigurationen im Richtlinienprojekt an das Arbeitslastprojekt weitergeleitet werden kann.

In einer komplexeren Einrichtung ist eine Lösung wie die freigegebene VPC für einen verbundenen Datenebene über mehrere Projekte hinweg erforderlich. Das bedeutet auch, dass NEG-Endpunkte eindeutige IP-Adressen haben. Diese Beispielkonfiguration kann auf komplexere Szenarien ausgeweitet werden, in denen sich Arbeitslasten in einem freigegebenen VPC-Netzwerk befinden, das sich über mehrere Projekte erstreckt.

Beschränkungen

Es gelten die allgemeinen Einschränkungen für Traffic Director und Einschränkungen für BackendService/NetworkEndpointGroup.

Die folgenden Einschränkungen gelten ebenfalls, sind aber möglicherweise nicht spezifisch für eine Einrichtung mit mehreren Projekten:

• Ein einzelner BackendService kann nur bis zu 50 Backends(einschließlich NEGs und MIGs) unterstützen.
• Nur zonale NEGs vom Typ GCP_VM_IP_PORT werden unterstützt.
• Projektübergreifende BackendServices-Verweise auf Instanzgruppen (verwaltet oder nicht verwaltet) werden nicht unterstützt.
• Das Auflisten von projektübergreifenden NEGs, die an einen bestimmten BackendService angehängt werden können, wird nicht unterstützt.
• Das Auflisten von BackendServices, die projektübergreifend eine bestimmte NEG verwenden, wird nicht unterstützt.

Hinweise

Sie müssen die folgenden Voraussetzungen erfüllen, bevor Sie projektübergreifende NEGs einrichten können.

Erforderliche APIs aktivieren

Für diese Anleitung sind die folgenden APIs erforderlich:

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

Führen Sie den folgenden Befehl aus, um die erforderlichen APIs sowohl im Arbeitslastprojekt als auch im Richtlinienprojekt zu aktivieren:

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

Erforderliche IAM-Berechtigungen gewähren

Sie benötigen ausreichende IAM-Berechtigungen (Identity and Access Management), um diese Anleitung durcharbeiten zu können. Wenn Sie die Rolle Projektinhaber oder Projektbearbeiter (roles/owner oder roles/editor) für das Projekt haben, in dem Sie Cloud Service Mesh aktivieren, haben Sie automatisch die erforderlichen Berechtigungen.

Andernfalls müssen Sie alle folgenden IAM-Rollen zuweisen. Mit diesen Rollen haben Sie auch über die zugehörigen Berechtigungen, wie in der Compute Engine IAM-Dokumentation beschrieben.

Die folgenden Rollen sind sowohl im Arbeitslast- als auch im Richtlinienprojekt erforderlich:

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

Die folgenden Rollen sind nur im Arbeitslastprojekt erforderlich:

• roles/compute.securityAdmin
• roles/container.admin
• Jede Rolle, die die folgenden Berechtigungen enthält. Die vordefinierte Rolle mit der höchsten Granularität, die alle erforderlichen Berechtigungen zum Anhängen eines NEG an einen BackendService enthält, ist roles/compute.loadBalancerServiceUser.
  • compute.networkEndpointGroups.get
  • compute.networkEndpointGroups.use

Außerdem müssen von Traffic Director verwaltete xDS-Clients (z. B. Envoy-Proxy) die Berechtigungen unter roles/trafficdirector.client haben. Zu Demonstrationszwecken können Sie mit dem folgenden Befehl dem Standard-Compute-Dienstkonto des Arbeitslastprojekts diese Berechtigung im Richtlinienprojekt gewähren:

gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member "serviceAccount:[e-mail]" \
    --role "roles/trafficdirector.client"

Dabei gilt:

• POLICY_PROJECT_ID ist die ID des Richtlinienprojekts.
• WORKLOAD_PROJECT_NUMBER ist die Projektnummer des Arbeitslastprojekts.

Dienst-Backend im Arbeitslastprojekt konfigurieren

1. Führen Sie den folgenden Befehl aus, um die Google Cloud CLI auf das Richtlinienprojekt zu verweisen und die bevorzugte Google Cloud Compute-Zone festzulegen:

   gcloud config set project WORKLOAD_PROJECT_ID
   gcloud config set compute/zone ZONE
   

   Dabei gilt:

   • WORKLOAD_PROJECT_ID ist die ID des Arbeitslastprojekts.
   • ZONE ist die Zone des GKE-Clusters, z. B. us-central1.

2. GKE-Cluster erstellen Zur Veranschaulichung wird mit dem folgenden Befehl ein zonaler GKE-Cluster erstellt. Diese Funktion funktioniert jedoch auch bei regionalen GKE-Clustern.

   gcloud container clusters create test-cluster \
       --scopes=https://www.googleapis.com/auth/cloud-platform
       --zone=ZONE
   

3. Firewallregel erstellen

   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
   

   Eine Firewallregel ermöglicht es der Google Cloud Steuerungsebene, Systemdiagnosetests an Back-Ends im Standard-VPC-Netzwerk zu senden.

4. Ändern Sie den aktuellen Kontext für kubectl in den neu erstellten Cluster:

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

5. Beispiel-App „whereami“ erstellen und bereitstellen:

   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
   

6. Führen Sie den folgenden Befehl aus, um den Verweis auf die NEG in einer Variablen zu speichern:

   NEG_LINK=$(gcloud compute network-endpoint-groups describe example-neg --format="value(selfLink)")
   

   Der NEG-Controller erstellt automatisch eine zonale NetworkEndpointGroup für die Dienst-Backends in jeder Zone. In diesem Beispiel ist der NEG-Name als „example-neg“ fest codiert. Das Speichern als Variable ist in der nächsten Sitzung nützlich, wenn Sie dieses NEG an einen BackendService im Richtlinienprojekt anhängen.

   Wenn Sie beispielsweise $NEG_LINK verwenden, sollte die Ausgabe in etwa so aussehen:

   $ echo ${NEG_LINK}
   https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
   

   Alternativ können Sie die NEG-URL abrufen, indem Sie die Annotation „neg-status“ für den Dienst lesen:

   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"
   

Google Cloud Netzwerkressourcen im Richtlinienprojekt konfigurieren

1. Richten Sie die Google Cloud CLI auf das Richtlinienprojekt aus:

   gcloud config set project POLICY_PROJECT_ID
   

2. Konfiguriert eine Mesh-Ressource:

   gcloud network-services meshes import example-mesh --source=- --location=global << EOF
   name: example-mesh
   EOF
   

   Der Name der Mesh-Ressource ist der Schlüssel, den Sidecar-Proxys zum Anfordern der Konfiguration des Service Mesh verwenden.

3. So konfigurieren Sie eine BackendService-Basislinie mit einer Systemdiagnose:

   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
   

4. Hängt die im vorherigen Abschnitt erstellte NetworkEndpointGroup an die BackendService an:

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

5. Erstellen Sie eine HTTPRoute, um alle HTTP-Anfragen mit dem Host-Header example-service an den Server im Arbeitslastprojekt weiterzuleiten:

   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
   

   Dabei ist POLICY_PROJECT_NUMBER die Projektnummer des Richtlinienprojekts.

Einrichtung prüfen

Sie können die Einrichtung prüfen, indem Sie eine HTTP-Anfrage mit dem auf example-service gesetzten HOST-Header an eine virtuelle IP-Adresse hinter einem von Traffic Director verwalteten Sidecar-Proxy senden:

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

Die Ausgabe sieht etwa so aus:

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

Da der gesamte ausgehende Traffic von Pods in einem Service Mesh von einem Envoy-Sidecar abgefangen wird und die vorherige HTTPRoute so konfiguriert ist, dass der gesamte Traffic basierend auf dem L7-Attribut (Host-Header) an den Kubernetes-Dienst „whereami“ gesendet wird, In diesem Befehl ist die VIP beispielsweise 10.0.0.1. Die VIP kann jedoch eine beliebige IP-Adresse sein.

Der Sidecar-Proxy sollte Konfigurationen anfordern, die mit der Mesh-Ressource im Richtlinienprojekt verknüpft sind. Dazu muss die Knoten-ID im folgenden Format festgelegt sein:

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

Nächste Schritte

• Projektübergreifende Mesh-Route einrichten