Projektübergreifende Netzwerk-Endpunktgruppe einrichten

Hinweis: Dieser Leitfaden unterstützt nur Cloud Service Mesh mit Google Cloud APIs und keine Istio APIs. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Mit der projektübergreifenden Funktion für Netzwerk-Endpunktgruppen (NEG) können Kunden NEGs aus einem anderen Projekt an eine Traffic Director/Cloud Service Mesh-BackendService anhängen. Dadurch sind die folgenden Anwendungsfälle möglich:

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

• Bei einer Bereitstellung mit mehreren Projekten können Sie alle Ihre Computing-Ressourcen (Compute Engine-VMs, GKE-NEGs usw.) in einem einzigen zentralen Google Cloud-Projekt verwalten. Serviceteams haben eigene Google Cloud-Dienstprojekte, in denen sie Dienstrichtlinien in BackendServices und Dienst-Routing-Routen in ihrem jeweiligen Dienstprojekt definieren. So wird die Verwaltung der Dienste delegiert, während die Rechenressourcen, die von verschiedenen Serviceteams gemeinsam genutzt werden können, genau kontrolliert werden.

Auf dieser Seite erfahren Sie, wie Sie eine Baseline-Einrichtung mit zwei Projekten erstellen, bei der die NEG in Projekt A (das Arbeitslastprojekt) an die BackendService in Projekt B (das Richtlinienprojekt) angehängt ist. 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 zum Arbeitslastprojekt weiterleiten kann.

Bei einer komplexeren Einrichtung ist für eine vernetzte Datenebene über mehrere Projekte hinweg eine Lösung wie die freigegebene VPC 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 freigegebene VPC-Netzwerk befinden, das mehrere Projekte umfasst.

Beschränkungen

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

Die folgenden Einschränkungen gelten ebenfalls, sind aber nicht unbedingt auf eine Mehrfachprojektkonfiguration beschränkt:

• Ein einzelner Backend-Dienst kann nur bis zu 50 Backends unterstützen(einschließlich NEGs und MIGs).
• Es werden nur zonale NEGs vom Typ GCP_VM_IP_PORT unterstützt.
• Projektübergreifende Verweise von Backend-Diensten auf Instanzgruppen (verwaltet oder nicht verwaltet) werden nicht unterstützt.
• Das Auflisten projektübergreifender NEGs, die an einen bestimmten BackendService angehängt werden können, wird nicht unterstützt.
• Die Auflistung projektübergreifender Back-End-Dienste, die 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.

Aktivieren der erforderlichen APIs:

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 ausführen 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 für Arbeitslast- als auch für Richtlinienprojekte 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 detaillierteste vordefinierte Rolle, die alle erforderlichen Berechtigungen zum Anhängen einer NEG an einen Backend-Dienst enthält, ist roles/compute.loadBalancerServiceUser.
  • compute.networkEndpointGroups.get
  • compute.networkEndpointGroups.use

Darüber hinaus 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 diese Berechtigung im Richtlinienprojekt dem Standard-Compute-Dienstkonto des Arbeitslastprojekts 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-Rechenzone 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-Cluster, z. B. us-central1.

2. Einen GKE-Cluster installieren Der folgende Befehl erstellt zu Demonstrationszwecken einen zonalen GKE-Cluster. 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
   

   Mit einer Firewallregel kann die Google Cloud-Steuerungsebene Systemdiagnosetests an Back-Ends im Standard-VPC-Netzwerk 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: 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
   

6. Führen Sie den folgenden Befehl aus, um die Referenz 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 „beispiel-neg“ hartcodiert. Das Speichern als Variable ist in der nächsten Sitzung nützlich, wenn Sie diese NEG einem BackendService im Richtlinienprojekt anhängen.

   Wenn Sie beispielsweise $NEG_LINK verwenden, sollte das ungefähr 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 neg-status-Anmerkung zum 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. Weisen Sie die Google Cloud CLI auf das Richtlinienprojekt hin:

   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, mit dem Sidecar-Proxys die Konfiguration des Service Mesh anfordern.

3. Konfigurieren Sie eine Baseline-BackendService 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ängen Sie 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 HOST-Header example-service an eine VIP 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 von einem Envoy-Sidecar in einem Service Mesh abgefangen wird, ist die vorherige HTTPRoute so konfiguriert, dass der gesamte Traffic ausschließlich basierend auf dem L7-Attribut (Host-Header) an den Kubernetes-Dienst „whereami“ gesendet wird. In diesem Beispiel lautet die VIP 10.0.0.1, aber es kann jede IP-Adresse sein.

Der Sidecar-Proxy sollte Konfigurationen anfordern, die mit der Mesh-Ressource im Richtlinienprojekt verknüpft sind. Achten Sie dabei darauf, dass die Knoten-ID im folgenden Format festgelegt ist:

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

Nächste Schritte

• Projektübergreifende Mesh-Route einrichten