Erweiterte Trafficverwaltung mit Envoy konfigurieren

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

Die Konfiguration wird für Vorabversionen unterstützt, für neue Cloud Service Mesh-Nutzer wird sie jedoch nicht empfohlen. Weitere Informationen finden Sie in der Übersicht zum Cloud Service Mesh-Dienstrouting.

Dieses Dokument enthält Informationen zum Konfigurieren der erweiterten Traffic-Verwaltung für Cloud Service Mesh-Bereitstellungen, die Envoy verwenden.

Hinweise

Bevor Sie die erweiterte Trafficverwaltung konfigurieren, folgen Sie der Anleitung unter Einrichtung von Cloud Service Mesh mit Envoy vorbereiten. Dabei wird auch das Konfigurieren des Cloud Service Mesh und aller benötigten VM-Hosts oder Google Kubernetes Engine-Cluster (GKE) beschrieben. Erstellen Sie die benötigten Google Cloud-Ressourcen.

Die Verfügbarkeit des Features für die erweiterte Trafficverwaltung hängt vom ausgewählten Anfrageprotokoll ab. Dieses Protokoll wird konfiguriert, wenn Sie das Routing mit dem Ziel-HTTP- oder Ziel-HTTPS-Proxy, dem Ziel-gRPC-Proxy oder der Ziel-TCP-Proxy-Ressource konfigurieren:

• Mit dem Ziel-HTTP-Proxy und dem Ziel-HTTPS-Proxy sind alle in diesem Dokument beschriebenen Features verfügbar.
• Mit dem Ziel-gRPC-Proxy sind einige Features verfügbar.
• Mit dem Ziel-TCP-Proxy sind keine Features zur erweiterten Trafficverwaltung verfügbar.

Weitere Informationen finden Sie unter Cloud Service Mesh-Features und Erweiterte Traffic-Verwaltung. Eine End-to-End-Einrichtungsanleitung finden Sie unter Erweiterte Trafficverwaltung mit proxylosen gRPC-Diensten konfigurieren.

Trafficaufteilung einrichten

Bei dieser Anleitung wird Folgendes vorausgesetzt:

• Ihre Cloud Service Mesh-Bereitstellung hat eine URL-Zuordnung namens review-url-map.
• Die URL-Zuordnung sendet den gesamten Traffic an den Back-End-Dienst review1, der als Standard-Back-End-Dienst dient.
• Sie möchten 5 % des Traffics an eine neue Version eines Dienstes weiterleiten. Dieser Dienst wird auf einer Back-End-VM oder einem Endpunkt in einer Netzwerk-Endpunktgruppe (NEG) ausgeführt, die dem Back-End-Dienst review2 zugeordnet ist.
• Es werden keine Hostregeln oder Tools zum Abgleich von Pfaden verwendet.

Wenn Sie Traffic auf einen neuen Dienst aufteilen, auf den zuvor noch nicht durch die URL-Zuordnung verwiesen wurde, fügen Sie den neuen Dienst zuerst zu weightedBackendServices hinzu und weisen Sie ihm eine Gewichtung von 0 zu. Erhöhen Sie dann schrittweise die Gewichtung, die diesem Dienst zugewiesen ist.

So richten Sie die Trafficaufteilung ein:

Console

1. Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.

   Zu Cloud Service Mesh

2. Klicken Sie auf Routingregelzuordnungen.

3. Klicken Sie auf  Routingregelzuordnung erstellen.

4. Geben Sie auf der Seite Routingregelzuordnung erstellen einen Namen ein.

5. Wählen Sie im Menü Protokoll die Option HTTP aus.

6. Wählen Sie eine vorhandene Weiterleitungsregel aus.

7. Wählen Sie unter Routingregeln die Option Erweiterte Host-, Pfad- und Routeregel aus.

8. Klicken Sie unter Tools zum Abgleich von Hosts und Pfaden auf  Tool zum Abgleich von Hosts und Pfaden hinzufügen. Dies fügt einen neues Tool zum Abgleich von Pfaden hinzu, das Sie konfigurieren können, um den Traffic aufzuteilen.

9. Fügen Sie dem Feld Tool zum Abgleich von Pfaden die folgenden Einstellungen hinzu:

       - defaultService: global/backendServices/review1
         name: matcher1
         routeRules:
         - priority: 2
           matchRules:
           - prefixMatch: ''
           routeAction:
            weightedBackendServices:
            - backendService: global/backendServices/review1
              weight: 95
            - backendService: global/backendServices/review2
              weight: 5
   

10. Klicken Sie auf Fertig.

11. Klicken Sie auf Speichern.

Wenn die neue Version Ihren Anforderungen entspricht, können Sie die Gewichtung der beiden Dienste schrittweise anpassen und schließlich den gesamten Traffic an review2 senden.

gcloud

1. Führen Sie den Befehl gcloud export aus, um die Konfiguration der URL-Zuordnung abzurufen:

   gcloud compute url-maps export review-url-map \
       --destination=review-url-map-config.yaml
   

2. Fügen Sie der Datei review-url-map-config.yaml den folgenden Abschnitt hinzu:

        hostRules:
        - description: ''
         hosts:
          - '*'
        pathMatcher: matcher1
        pathMatchers:
        - defaultService: global/backendServices/review1
          name: matcher1
          routeRules:
          - priority: 2
            matchRules:
            - prefixMatch: ''
            routeAction:
             weightedBackendServices:
             - backendService: global/backendServices/review1
               weight: 95
             - backendService: global/backendServices/review2
               weight: 5
   

3. Aktualisieren Sie die URL-Zuordnung:

   gcloud compute url-maps import review-url-map \
       --source=review-url-map-config.yaml
   

Wenn die neue Version Ihren Anforderungen entspricht, können Sie die Gewichtung der beiden Dienste schrittweise anpassen und schließlich den gesamten Traffic an review2 senden.

Teilweisen Release einrichten

Verwenden Sie einen teilweisen Bereitstellungsprozess, manchmal auch als Canarying bezeichnet, um eine neue Softwareversion für einen kleinen Teil der Server freizugeben, bevor Sie die neue Version für Ihre übrigen Produktionsserver freigeben.

Ein teilweiser Release verwendet weightedBackendServices. Legen Sie einen Backend-Dienst als Test- bzw. Canary-Dienst fest und weisen Sie ihm eine geringe Gewichtung zu, z. B. 2 oder 5, um einen teilweisen Release zu aktivieren. Stellen Sie die neue Softwareversion nur auf diesen Servern bereit. Wenn Sie sich sicher sind, dass die neue Version fehlerfrei ist, stellen Sie sie für die übrigen Dienste bereit.

• Verwenden Sie das folgende YAML-Codebeispiel, um einen teilweisen Release zu aktivieren:

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_PARTIAL_URL
            weight: 2
          - backendService: BACKEND_SERVICE_URL
            weight: 98

• DEFAULT_SERVICE_URL ist die Standard-URL für Ihren Dienst.
• BACKEND_SERVICE_PARTIAL_URL ist die URL für den Backend-Dienst, der 2 % des Traffics empfängt.
• BACKEND_SERVICE_URL ist die URL für den Backend-Dienst, der 98 % des Traffics empfängt.

Blau/Grün-Bereitstellungen einrichten

Blau/Grün-Bereitstellungen sind Releasemodelle, die den Zeitbedarf für die Umstellung des Produktions-Traffics auf einen neuen Release eines Dienstes oder für ein Rollback eines vorherigen Release des Dienstes reduzieren. Diese Bereitstellungen behalten beide Versionen des Dienstes in der Produktion bei und verschieben den Traffic von einer zur anderen.

Blau/Grün-Bereitstellungen verwenden weightedBackendServices. Im folgenden YAML-Beispiel werden Back-Ends für SERVICE_BLUE_URL mit dem aktuellen Produktionsrelease vollständig bereitgestellt und die Back-Ends für SERVICE_GREEN_URL werden mit dem neuen Release vollständig bereitgestellt. In der Konfiguration im Beispiel empfängt die GREEN-Bereitstellung 100 % des Produktions-Traffics. Wenn Sie Probleme feststellen, können Sie die Gewichtungen für die beiden Bereitstellungen umkehren. Dadurch wird der defekte GREEN-Release zurückgenommen und der als funktionierend bekannte BLUE-Release wiederhergestellt. In beiden Fällen kann der Traffic schnell verlagert werden, da beide Versionen für den Empfang von Traffic zur Verfügung stehen.

• Verwenden Sie das folgende YAML-Codebeispiel, um eine Blau/Grün-Bereitstellung zu aktivieren:

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_BLUE_URL
            weight: 0
          - backendService: BACKEND_SERVICE_GREEN_URL
            weight: 100

• DEFAULT_SERVICE_URL ist die Standard-URL für Ihren Dienst.
• BACKEND_SERVICE_BLUE_URL ist die URL für den Backend-Dienst, der keinen Traffic empfängt.
• BACKEND_SERVICE_GREEN_URL ist die URL für den Backend-Dienst, der 100 % Ihres Traffics empfängt.

Trafficspiegelung einrichten

Verwenden Sie die Traffic-Spiegelung, wenn Sie Traffic zu zwei verschiedenen Backend-Diensten weiterleiten möchten, um Fehler zu beheben oder neue Dienste zu testen.

Im folgenden Beispiel werden alle Anfragen an SERVICE_URL und an MIRROR_SERVICE_URL gesendet. Nur die Antworten von SERVICE_URL werden an den Client zurückgesendet. MIRROR_SERVICE_URL hat keine Auswirkungen auf den Client.

So richten Sie die Traffic-Spiegelung ein:

Console

1. Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.

   Zu Cloud Service Mesh

2. Klicken Sie auf Routingregelzuordnungen.

3. Klicken Sie auf  Routingregelzuordnung erstellen.

4. Geben Sie auf der Seite Routingregelzuordnung erstellen einen Namen ein.

5. Wählen Sie in der Liste Protokoll die Option HTTP aus.

6. Wählen Sie eine vorhandene Weiterleitungsregel aus.

7. Wählen Sie unter Routingregeln die Option Erweiterte Host-, Pfad- und Routeregel aus.

8. Klicken Sie unter Tools zum Abgleich von Hosts und Pfaden auf  Tool zum Abgleich von Hosts und Pfaden hinzufügen. Dies fügt einen neues Tool zum Abgleich von Pfaden hinzu, das Sie konfigurieren können, um den Traffic zu spiegeln.

9. Fügen Sie dem Feld Tool zum Abgleich von Pfaden die folgenden Einstellungen hinzu:

       - defaultService: DEFAULT_SERVICE_URL
         name: matcher1
         routeRules:
         - matchRules:
           - prefixMatch: '/'
           routeAction:
            weightedBackendServices:
            - backendService: BACKEND_SERVICE_URL
              weight: 100
            requestMirrorPolicy:
              backendService: BACKEND_SERVICE_MIRROR_URL
   

   • DEFAULT_SERVICE_URL ist die Standard-URL für Ihren Dienst.
   • BACKEND_SERVICE_URL ist die URL für das gespiegelte Backend.
   • BACKEND_SERVICE_MIRROR_URL ist die URL für den Backend-Dienst, zu dem Sie spiegeln.

10. Klicken Sie auf Fertig.

11. Klicken Sie auf Speichern.

gcloud

1. Führen Sie den Befehl gcloud export aus, um die Konfiguration der URL-Zuordnung abzurufen:

   gcloud compute url-maps export review-url-map \
       --destination=review-url-map-config.yaml
   

2. Fügen Sie der Datei review-url-map-config.yaml den folgenden Abschnitt hinzu:

        hostRules:
        - description: ''
         hosts:
          - '*'
        pathMatcher: matcher1
        pathMatchers:
       - defaultService: DEFAULT_SERVICE_URL
         name: matcher1
         routeRules:
         - matchRules:
           - prefixMatch: '/'
           routeAction:
            weightedBackendServices:
            - backendService: BACKEND_SERVICE_URL
              weight: 100
            requestMirrorPolicy:
              backendService: BACKEND_SERVICE_MIRROR_URL
   

   • DEFAULT_SERVICE_URL ist die Standard-URL für Ihren Dienst.
   • BACKEND_SERVICE_URL ist die URL für das gespiegelte Backend.
   • BACKEND_SERVICE_MIRROR_URL ist die URL für den Backend-Dienst, zu dem Sie spiegeln.

3. Aktualisieren Sie die URL-Zuordnung:

   gcloud compute url-maps import review-url-map \
       --source=review-url-map-config.yaml
   

Schutzschaltung einrichten

Mit einer Schutzschaltung können Sie Fehlerschwellenwerte festlegen, damit Clientanfragen Ihre Back-Ends nicht überlasten. Wenn Anfragen ein von Ihnen festgelegtes Limit erreichen, lässt der Client keine neuen Verbindungen mehr zu und sendet keine weiteren Anfragen, damit Ihre Back-Ends Zeit erhalten, ihre Arbeitslast zu verarbeiten.

Auf diese Weise verhindern Schutzschaltungen Fehlerkaskaden. Anstatt ein Backend zu überlasten, wird ein Fehler an den Client zurückgegeben. Dadurch kann ein Teil des Traffics verarbeitet werden, während parallel Zeit zum Lösen von Überlastungsproblemen bleibt. Beispielsweise können Traffic-Spitzen durch Erhöhen der Kapazität mithilfe von Autoscaling bewältigt werden.

Im folgenden Beispiel werden die Schutzschalter so festgelegt:

• Maximale Anfragen pro Verbindung: 100
• Maximale Anzahl an Verbindungen: 1.000
• Maximale ausstehende Anfragen: 200
• Maximale Anfragen: 1.000
• Maximale Wiederholungsversuche: 3

So richten Sie eine Schutzschaltung ein:

Console

1. Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.

   Zu Cloud Service Mesh

2. Klicken Sie auf den Namen des Back-End-Dienstes, den Sie aktualisieren möchten.

3. Klicken Sie auf Bearbeiten.

4. Klicken Sie auf Erweiterte Konfigurationen.

5. Wählen Sie unter Schutzschalter das Kästchen Aktivieren aus.

6. Klicken Sie auf Bearbeiten.

   1. Geben Sie unter Maximale Anfragen pro Verbindung den Wert 100 ein.
   2. Geben Sie unter Maximale Verbindungen den Wert 1000 ein.
   3. Geben Sie unter Maximal ausstehende Anfragen den Wert 200 ein.
   4. Geben Sie unter Maximale Anfragen den Wert 1000 ein.
   5. Geben Sie unter Maximale Wiederholungsversuche den Wert 3 ein.

7. Klicken Sie auf Speichern und anschließend noch einmal auf Speichern.

gcloud

1. Führen Sie den Befehl gcloud export aus, um die Konfiguration des Back-End-Dienstes zu exportieren. Ersetzen Sie BACKEND_SERVICE_NAME durch den Namen des Back-End-Dienstes.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=BACKEND_SERVICE_NAME-config.yaml --global
   

2. Aktualisieren Sie die Datei BACKEND_SERVICE_NAME.yaml so:

    affinityCookieTtlSec: 0
    backends:
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
       group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME
      maxUtilization: 0.8
    circuitBreakers:
      maxConnections: 1000
      maxPendingRequests: 200
      maxRequests: 1000
      maxRequestsPerConnection: 100
      maxRetries: 3
    connectionDraining:
      drainingTimeoutSec: 300
    healthChecks:
      - https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME
    loadBalancingScheme: INTERNAL_SELF_MANAGED
    localityLbPolicy: ROUND_ROBIN
    name: BACKEND_SERVICE_NAME
    port: 80
    portName: http
    protocol: HTTP
    sessionAffinity: NONE
    timeoutSec: 30
   

3. Aktualisieren Sie die Konfigurationsdatei des Back-End-Dienstes:

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
       --source=BACKEND_SERVICE_NAME-config.yaml --global
   

Sitzungsaffinität anhand von HTTP_COOKIE einrichten

Mit der erweiterten Trafficverwaltung können Sie die Sitzungsaffinität anhand eines bereitgestellten Cookies konfigurieren.

Richten Sie die Sitzungsaffinität mit HTTP_COOKIE wie im Folgenden beschrieben ein:

Console

1. Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.

   Zu Cloud Service Mesh

2. Klicken Sie auf den Namen des Back-End-Dienstes, den Sie aktualisieren möchten.

3. Klicken Sie auf Bearbeiten.

4. Klicken Sie auf Erweiterte Konfigurationen.

5. Wählen Sie unter Sitzungsaffinität die Option HTTP-Cookie aus.

6. Wählen Sie unter Ort-Load-Balancing-Richtlinie die Option Schlüssel-Hash aus.

   1. Geben Sie im Feld HTTP-Cookie-Name http_cookie ein.
   2. Geben Sie im Feld HTTP-Cookie-Pfad /cookie_path ein.
   3. Geben Sie im Feld HTTP-Cookie-TTL 100 ein.
   4. Geben Sie im Feld Minimale Schlüsselbundgröße 10000 ein.

7. Klicken Sie auf Speichern.

gcloud

1. Führen Sie den Befehl gcloud export aus, um die Konfiguration des Back-End-Dienstes zu exportieren. Ersetzen Sie BACKEND_SERVICE_NAME durch den Namen des Back-End-Dienstes.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
       --destination=BACKEND_SERVICE_NAME-config.yaml --global
   

2. Aktualisieren Sie die Datei YAML so:

   sessionAffinity: 'HTTP_COOKIE'
   localityLbPolicy: 'RING_HASH'
   consistentHash:
   httpCookie:
     name: 'http_cookie'
     path: '/cookie_path'
     ttl:
       seconds: 100
       nanos: 30
   minimumRingSize: 10000
   

3. Importieren Sie die Konfigurationsdatei für den Back-End-Dienst:

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
       --source=BACKEND_SERVICE_NAME-config.yaml --global
   

Ausreißererkennung einrichten

Die Ausreißererkennung steuert das Entfernen von fehlerhaften Hosts aus dem Load-Balancing-Pool. Dazu verwendet Cloud Service Mesh eine Reihe von Richtlinien, die die Kriterien für das Entfernen fehlerhafter Back-End-VMs oder Endpunkte in NEGs sowie Kriterien dafür festlegen, wann ein Back-End oder Endpunkt als stabil genug gilt, um wieder Traffic zu empfangen.

Im folgenden Beispiel hat der Back-End-Dienst eine einzige Instanzgruppe als Back-End. Die Einstellung für die Ausreißererkennung gibt an, dass die Ausreißererkennungsanalyse jede Sekunde ausgeführt wird. Wenn ein Endpunkt fünf aufeinanderfolgende 5xx-Fehler zurückgibt, wird er beim ersten Mal 30 Sekunden lang nicht für das Load-Balancing berücksichtigt. Die reale Ausschlusszeit für denselben Endpunkt beträgt 30 Sekunden mal die Häufigkeit, mit der er ausgeschlossen wird.

Richten Sie die Ausreißererkennung für die Backend-Dienstressource wie im Folgenden beschrieben ein:

Console

1. Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.

   Zu Cloud Service Mesh

2. Klicken Sie auf den Namen eines Dienstes.

3. Klicken Sie auf Bearbeiten.

4. Klicken Sie auf Erweiterte Konfigurationen.

5. Wählen Sie das Kästchen Ausreißererkennung aus.

6. Klicken Sie auf Bearbeiten.

   1. Legen Sie für Aufeinanderfolgende Fehler den Wert 5 fest.
   2. Legen Sie für Intervall 1000 Millisekunden fest.
   3. Legen Sie für Basisausschlusszeit 30000 Millisekunden fest.

7. Klicken Sie auf Speichern und anschließend noch einmal auf Speichern.

gcloud

1. Führen Sie den Befehl gcloud export aus, um die Konfiguration des Back-End-Dienstes zu exportieren. Ersetzen Sie BACKEND_SERVICE_NAME durch den Namen des Back-End-Dienstes.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
       --destination=BACKEND_SERVICE_NAME-config.yaml --global
   

2. Aktualisieren Sie die YAML-Datei wie nachfolgend gezeigt und ersetzen Sie dabei den Namen des Back-End-Dienstes durch BACKEND_SERVICE_NAME:

   name: BACKEND_SERVICE_NAME
   loadBalancingScheme: INTERNAL_SELF_MANAGED
   backends:
   - balancingMode: UTILIZATION
    capacityScaler: 1.0
    group: $INSTANCE_GROUP_URL
   healthChecks:
   - $HEALTH_CHECK_URL
   port: 80
   portName: http
   protocol: HTTP
   outlierDetection:
    consecutiveErrors: 5,
    interval:
        seconds: 1,
        nanos: 0
    baseEjectionTime:
        seconds: 30,
        nanos: 0
   

3. Importieren Sie die Konfigurationsdatei für den Back-End-Dienst:

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
       --source=BACKEND_SERVICE_NAME-config.yaml --global
   

Ort-Load-Balancing-Richtlinie festlegen

Verwenden Sie die Standort-Load-Balancing-Richtlinie, um einen Load-Balancing-Algorithmus basierend auf der Standortgewichtung und der von Cloud Service Mesh angegebenen Priorität auszuwählen. Beispielsweise können Sie eine gewichtete Round-Robin-Verteilung an fehlerfreien Endpunkten oder ein konsistentes Hashing ausführen.

Im folgenden Beispiel hat der Back-End-Dienst eine einzige Instanzgruppe als Back-End. Die Ort-Load-Balancing-Richtlinie ist auf RING_HASH festgelegt.

Legen Sie die Ort-Load-Balancing-Richtlinie wie im Folgenden beschrieben fest:

Console

1. Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.

   Zu Cloud Service Mesh

2. Klicken Sie auf den Namen eines Dienstes.

3. Klicken Sie auf Bearbeiten.

4. Klicken Sie auf Erweiterte Konfigurationen.

5. Wählen Sie unter Trafficrichtlinie im Menü Ort-Load-Balancing-Richtlinie die Option Schlüssel-Hash aus.

6. Klicken Sie auf Speichern.

gcloud

1. Führen Sie den Befehl gcloud export aus, um die Konfiguration des Back-End-Dienstes zu exportieren. Ersetzen Sie BACKEND_SERVICE_NAME durch den Namen des Back-End-Dienstes.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
       --destination=BACKEND_SERVICE_NAME-config.yaml --global
   

2. Aktualisieren Sie die Datei BACKEND_SERVICE_NAME.yaml so:

   name: shopping-cart-service
   loadBalancingScheme: INTERNAL_SELF_MANAGED
   backends:
   - balancingMode: UTILIZATION
    capacityScaler: 1.0
    group: $INSTANCE_GROUP_URL
   healthChecks:
   - $HEALTH_CHECK_URL
   port: 80
   portName: http
   protocol: HTTP
   localityLbPolicy: RING_HASH
   

3. Importieren Sie die Konfigurationsdatei für den Back-End-Dienst:

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
       --source=BACKEND_SERVICE_NAME-config.yaml --global
   

Weitere Informationen zur Funktionsweise der Ort-Load-Balancing-Richtlinie finden Sie in der Dokumentation zur backendService-Ressource.

URL-Weiterleitung einrichten

Bei dieser Anleitung wird Folgendes vorausgesetzt:

• Ihre Cloud Service Mesh-Bereitstellung hat eine URL-Zuordnung namens review-url-map.
• Die URL-Zuordnung sendet den gesamten Traffic an den Back-End-Dienst review1, der als Standard-Back-End-Dienst dient.
• Sie möchten Traffic von einem Host an einen anderen weiterleiten.

So richten Sie die URL-Weiterleitung ein:

Console

1. Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.

   Zu Cloud Service Mesh

2. Klicken Sie auf Routingregelzuordnungen.

3. Klicken Sie auf  Routingregelzuordnung erstellen.

4. Geben Sie auf der Seite Routingregelzuordnung erstellen einen Namen ein.

5. Wählen Sie im Menü Protokoll die Option HTTP aus.

6. Wählen Sie eine vorhandene Weiterleitungsregel aus.

7. Wählen Sie unter Routingregeln die Option Erweiterte Host-, Pfad- und Routeregel aus.

8. Klicken Sie unter Tools zum Abgleich von Hosts und Pfaden auf  Tool zum Abgleich von Hosts und Pfaden hinzufügen. Dadurch wird ein neues Tool zum Abgleich von Pfaden hinzugefügt, der den Traffic weiterleitet.

9. Fügen Sie dem Feld Tool zum Abgleich von Pfaden die folgenden Einstellungen hinzu:

       - defaultService: global/backendServices/review1
         name: matcher1
         routeRules:
         - matchRules:
           - prefixMatch: ''
           urlRedirect:
            hostRedirect: '[REDIRECT_HOST]'
            pathRedirect: '[REDIRECT_URL]'
            redirectResponseCode: 'FOUND',
           stripQuery: True
   

10. Klicken Sie auf Fertig.

11. Klicken Sie auf Speichern.

gcloud

1. Führen Sie den Befehl gcloud export aus, um die Konfiguration der URL-Zuordnung abzurufen:

   gcloud compute url-maps export review-url-map \
       --destination=review-url-map-config.yaml
   

2. Fügen Sie der Datei review-url-map-config.yaml den folgenden Abschnitt hinzu:

        hostRules:
        - description: ''
         hosts:
          - '*'
        pathMatcher: matcher1
        pathMatchers:
       - defaultService: global/backendServices/review1
         name: matcher1
         routeRules:
         - matchRules:
           - prefixMatch: ''
           urlRedirect:
            hostRedirect: '[REDIRECT_HOST]'
            pathRedirect: '[REDIRECT_URL]'
            redirectResponseCode: 'FOUND',
           stripQuery: True
   

3. Aktualisieren Sie die URL-Zuordnung:

   gcloud compute url-maps import review-url-map \
       --source=review-url-map-config.yaml
   

Traffic-Steuerung mit URL-Umschreibung einrichten

Mithilfe der Traffic-Steuerung können Sie Traffic anhand von Anfrageattributen wie Headerwerten zu verschiedenen Backend-Diensten weiterleiten. Darüber hinaus können Sie Aktionen konfigurieren, z. B. das Umschreiben der URL in der Anfrage, bevor die Anfrage an den Backend-Dienst weitergeleitet wird.

Im folgenden Beispiel wird die Anfrage an SERVICE_ANDROID_URL weitergeleitet, wenn der Anfragepfad mit dem Präfix /mobile/ und der User-Agent der Anfrage Android enthalten. Bevor die Anfrage an den Backend-Dienst gesendet wird, kann das URL-Präfix in REWRITE_PATH_ANDROID (Beispiel: /android/) geändert werden. Wenn der Pfad jedoch das Präfix /mobile/ und einen User-Agent mit iPhone hat, wird der Traffic an SERVICE_IPHONE_URL weitergeleitet und das URL-Präfix wird in REWRITE_PATH_IPHONE geändert. Alle anderen Anfragen mit dem Präfix /mobile/ und mit einem User-Agent mit einem anderen Wert als Android oder iPhone werden an SERVICE_GENERIC_DEVICE_URL weitergeleitet.

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*Android.*
         service: $[SERVICE_ANDROID_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_ANDROID]
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*iPhone.*
         service: [SERVICE_IPHONE_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_IPHONE]
       - matchRules:
         - prefixMatch: /mobile/
         service: [SERVICE_GENERIC_DEVICE_URL]

Fehlereinschleusung einrichten

Mit der Fehlereinschleusung können Sie eine feste Verzögerung oder eine erzwungene Beendigung (Abbruch) oder beides für eine bestimmte Route verursachen, um die Ausfallsicherheit einer Anwendung zu testen.

Im folgenden Beispiel werden alle Anfragen an SERVICE_URL gesendet, wobei bei 100 % der Anfragen eine feste Verzögerung von 10 Sekunden hinzugefügt wird. Der Client, der die Anfragen sendet, sieht, dass alle Antworten um 10 Sekunden verzögert sind. Darüber hinaus wird auf 50 % der Anfragen ein Beendigungsfehler mit der Antwort Service Unavailable 503 angewendet. Der Client sieht, dass 50 % der Anfragen eine 503-Antwort erhalten. Diese Anfragen erreichen den Backend-Dienst überhaupt nicht.

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: [SERVICE_URL]
            weight: 100
          faultInjectionPolicy:
            delay:
              fixedDelay:
                seconds: 10
                nanos: 0
              percentage: 100
            abort:
              httpStatus: 503
              percentage: 50

Konfigurationsfilter anhand der MetadataFilters-Übereinstimmung einrichten

MetadataFilters sind mit Weiterleitungsregeln und HttpRouteRuleMatch aktiviert. Mit diesem Feature können Sie eine bestimmte Weiterleitungs- oder Routingregel so steuern, dass die Steuerungsebene die Weiterleitungs- oder Routingregel nur an Proxys sendet, deren Knotenmetadaten mit der Metadatenfiltereinstellung übereinstimmen. Wenn Sie keine MetadataFilters angeben, wird die Regel an alle Envoy-Proxys gesendet.

Anhand dieses Features können Sie eine Konfiguration einfacher schrittweise bereitstellen. Erstellen Sie beispielsweise eine Weiterleitungsregel mit dem Namen forwarding-rule1, die nur an Envoy-Proxys übertragen werden soll, deren Knotenmetadaten app: review und version: canary enthalten.

Hinweis: Das Importieren von Weiterleitungsregeln unterliegt einer Beschränkung. Weitere Informationen finden Sie unter Erweiterte Einschränkungen bei der Trafficverwaltung im Dokument zu den Einschränkungen von Cloud Service Mesh.

So fügen Sie einen MetadataFilters zu einer Weiterleitungsregel hinzu:

gcloud

1. Führen Sie zum Abrufen der Konfiguration der Weiterleitungsregel den Befehl gcloud export aus:

   gcloud compute forwarding-rules export forwarding-rule1 \
       --destination=forwarding-rule1-config.yaml \
       --global
   

2. Löschen Sie die Weiterleitungsregel:

   gcloud compute forwarding-rules delete forwarding-rule1 \
       --global
   

3. Aktualisieren Sie die Datei forwarding-rule1-config.yaml.

   Im folgenden Beispiel wird ein Metadatenfilter MATCH_ALL erstellt:

    metadataFilters:
    - filterMatchCriteria: 'MATCH_ALL'
      filterLabels:
      - name: 'app'
        value: 'review'
      - name: 'version'
        value: 'canary'
   

   Im folgenden Beispiel wird ein Metadatenfilter MATCH_ANY erstellt:

    metadataFilters:
    - filterMatchCriteria: 'MATCH_ANY'
      filterLabels:
      - name: 'app'
        value: 'review'
      - name: 'version'
        value: 'production'
   

4. Entfernen Sie alle reinen Ausgabefelder aus der Datei forwarding-rule1-config.yaml. Weitere Informationen finden Sie in der Dokumentation zu gcloud compute forwarding-rules import.

5. Führen Sie den Befehl gcloud import zum Aktualisieren der Datei forwarding-rule1-config.yaml aus:

   gcloud compute forwarding-rules import forwarding-rule1 \
       --source=forwarding-rule1-config.yaml \
       --global
   

6. Folgen Sie dieser Anleitung, um Knotenmetadaten zum Envoy-Proxy hinzuzufügen, bevor Sie Envoy starten. Es wird lediglich ein Stringwert unterstützt.

   a. Fügen Sie für eine VM-basierte Bereitstellung in bootstrap_template.yaml im Abschnitt metadata Folgendes hinzu:

      app: 'review'
      version: 'canary'
   

   b. Bei einer auf Google Kubernetes Engine oder Kubernetes basierenden Bereitstellung fügen Sie in trafficdirector_istio_sidecar.yaml im Abschnitt env Folgendes hinzu:

      - name: ISTIO_META_app
        value: 'review'
      - name: ISTIO_META_version
        value: 'canary'
   

Beispiele für das Filtern von Metadaten

Verwenden Sie die folgende Anleitung für ein Szenario, in dem sich mehrere Projekte im selben freigegebene VPC-Netzwerk befinden und die Cloud Service Mesh-Ressourcen jedes Dienstprojekts für Proxys im selben Projekt sichtbar sein sollen.

So richten Sie die freigegebene VPC ein:

• Name des Hostprojekts: vpc-host-project
• Dienstprojekte: project1, project2
• Back-End-Dienste mit Back-End-Instanzen oder Endpunkten, die einen xDS-kompatiblen Proxy in project1 und project2 ausführen

So konfigurieren Sie Cloud Service Mesh zum Isolieren von project1:

gcloud

1. Erstellen Sie alle Weiterleitungsregeln in project1 mit dem folgenden Metadatenfilter:

        metadataFilters:
        - filterMatchCriteria: 'MATCH_ALL'
          filterLabels
          - name: 'project_name'
            value: 'project1'
          - name: 'version'
            value: 'production'
   

2. Wenn Sie die für Instanzen oder Endpunkte in project1 bereitgestellten Proxys konfigurieren, fügen Sie die folgenden Metadaten in den Knotenmetadatenbereich der Bootstrap-Datei ein:

      project_name: 'project1'
      version: 'production'
   

3. Achten Sie darauf, dass die Proxys, die bereits in project2 bereitgestellt wurden, die im ersten Schritt erstellte Weiterleitungsregel nicht erhalten haben. Versuchen Sie zu diesem Zweck, von einem System mit einem Proxy in project2 auf Dienste in project1 zuzugreifen. Informationen zum Prüfen, ob eine Cloud Service Mesh-Konfiguration ordnungsgemäß funktioniert, finden Sie unter Konfiguration prüfen.

Führen Sie die folgenden Schritte aus, um eine neue Konfiguration für einen Teil der Proxys zu testen, bevor Sie sie für alle Proxys verfügbar machen:

gcloud

1. Starten Sie die Proxys, die Sie zum Testen verwenden, mit den folgenden Knotenmetadaten. Fügen Sie diese Knotenmetadaten nicht für Proxys ein, die Sie nicht zum Testen verwenden.

     version: 'test'
   

2. Fügen Sie für jede neue Weiterleitungsregel, die Sie testen möchten, den folgenden Metadatenfilter ein:

     metadataFilters:
     - filterMatchCriteria: 'MATCH_ALL'
       filterLabels:
       - name: 'version'
         value: 'test'
   

3. Testen Sie die neue Konfiguration dadurch, dass Sie Traffic an die Testproxys senden und die erforderlichen Änderungen vornehmen. Wenn die neue Konfiguration ordnungsgemäß funktioniert, erhalten nur die getesteten Proxys die neue Konfiguration. Die verbleibenden Proxys erhalten sie nicht und können sie dementsprechend nicht verwenden.

4. Wenn Sie sicher sind, dass die neue Konfiguration ordnungsgemäß funktioniert, entfernen Sie den zugehörigen Metadatenfilter. Somit können alle Proxys die neue Konfiguration erhalten.

Fehlerbehebung

Gehen Sie nach den hier beschriebenen Informationen zur Fehlerbehebung vor, wenn der Traffic nicht gemäß den von Ihnen konfigurierten Routingregeln und Trafficrichtlinien weitergeleitet wird.

Symptome:

• Vermehrter Traffic an Dienste in Regeln über der betreffenden Regel
• Unerwartet vermehrte HTTP-Antworten des Typs 4xx und 5xx für eine bestimmte Routingregel

Lösung: Da Routingregeln in der Reihenfolge ihrer Priorität interpretiert werden, überprüfen Sie die jeder Regel zugewiesene Priorität.

Achten Sie beim Definieren von Routingregeln darauf, dass Regeln mit höherer Priorität (also mit niedrigeren Prioritätsnummern) nicht versehentlich Traffic weiterleiten, der andernfalls von einer nachfolgenden Routingregel weitergeleitet worden wäre. Dazu ein Beispiel:

• Erste Routingregel

  • Routingregel-Übereinstimmung: pathPrefix = /shopping/
  • Weiterleitungsaktion: Traffic an den Back-End-Dienst service-1 senden
  • Regelpriorität: 4

• Zweite Routingregel

  • Routingregel-Übereinstimmung: regexMatch = /shopping/cart/ordering/.*
  • Weiterleitungsaktion: Traffic an den Back-End-Dienst service-2 senden
  • Regelpriorität: 8

In diesem Fall wird eine Anfrage mit dem Pfad /shopping/cart/ordering/cart.html an service-1 weitergeleitet. Auch wenn die zweite Regel eine Übereinstimmung gewesen wäre, wird sie ignoriert, da die erste Regel eine höhere Priorität hatte.

Traffic zwischen Diensten blockieren

Wenn Sie Traffic zwischen Dienst A und Dienst B blockieren möchten und Ihre Bereitstellung in GKE erfolgt, richten Sie die Dienstsicherheit ein und verwenden eine Autorisierungsrichtlinie, um Traffic zwischen Diensten zu blockieren. Eine vollständige Anleitung finden Sie unter Traffic Director-Dienstsicherheit und in der Einrichtungsanleitung für Envoy und proxyloses gRPC.

Nächste Schritte

• Informationen zum Beheben von Cloud Service Mesh-Konfigurationsproblemen finden Sie unter Fehlerbehebung bei Bereitstellungen, die Envoy verwenden.