Vollständiges Verbindungsverkehrsmanagement basierend auf den Verkehrsspuren des Alibaba Cloud Service Grid (2): Verkehrsspuren im entspannten Modus

Im vorherigen Artikel Full-Link-Verkehrsmanagement basierend auf Alibaba Cloud Service Grid Traffic Lanes (1): Strict Mode Traffic Lanes haben wir das Nutzungsszenario der Verwendung der Strict Mode Traffic Lanes des Service Grid ASM für die Full-Link-Graustufenverwaltung vorgestellt. Dieser Modus stellt keine Anforderungen an die Anwendung und kann durch die Konfiguration von Fahrspuren implementiert werden. In diesem Artikel wird weiterhin die zweite Art von Verkehrsschwimmen vorgestellt: der entspannte Modus.

Übersicht über Swimlanes im entspannten Modus

Das Gegenteil von Fahrspuren im strengen Modus sind Fahrspuren im entspannten Modus. Im entspannten Modus müssen Sie lediglich darauf achten, eine Swimlane zu erstellen, die alle Dienste in der Anrufkette enthält: die Baseline-Swimlane. Andere Schwimmbahnen umfassen möglicherweise nicht alle Dienste des Anruflinks. Wenn sich Dienste in einer Swimlane gegenseitig anrufen und der Zieldienst in der aktuellen Swimlane nicht vorhanden ist, wird die Anfrage an denselben Dienst in der Baseline-Swimlane weitergeleitet und die Anfrage wird erneut an die aktuelle Swimlane weitergeleitet Swimlane, wenn das Anforderungsziel in der aktuellen Swimlane vorhanden ist.

Wenn Sie Verkehrsspuren im entspannten Modus verwenden, muss Ihre Anwendung einen Anforderungsheader enthalten, der über die gesamte Anrufverbindung weitergeleitet werden kann (den Link-Passthrough-Anforderungsheader), und der Wert des Link-Passthrough-Anforderungsheaders ist für jede Anforderung eindeutig. Sind nicht gleich . Gleichzeitig müssen Sie einen Header für die Anforderung einer Verkehrsumleitung angeben, und das ASM-Gateway sendet den Datenverkehr basierend auf dem Inhalt des Headers für die Anforderung einer Verkehrsumleitung an verschiedene Fahrspuren. In diesem Artikel wird beschrieben, wie Sie Fahrspuren im entspannten Modus in ASM verwenden, um ein vollständiges Link-Verkehrsmanagement zu implementieren.

Drill-Szenario 1 im entspannten Modus: Der Header der Verkehrsumleitungsanforderung wird im Link nicht transparent übertragen

In diesem Artikel wird zunächst das am häufigsten verwendete Nutzungsszenario für Fahrspuren im entspannten Modus vorgestellt, dh der in der Anrufverbindung transparent übertragene Anforderungsheader ist nicht der Anforderungsheader für die Verkehrsumleitung.

In diesem Beispielszenario im entspannten Modus werden die drei Dienste Mocka, Mockb und Mockc, wie in der Abbildung gezeigt, verwendet, um drei Schwimmspuren zu erstellen, die drei Versionen der Dienstaufrufkette darstellen: s1, s2 und s3. Darunter ist s1 die Basis-Swimlane, die drei vollständige Dienste enthält, während s2 nur zwei Dienste, Mocka und Mockc, enthält und s3 nur einen Dienst, Mockb, enthält.

Voraussetzungen

  • Es wurde eine ASM Enterprise Edition- oder Ultimate Edition-Instanz erstellt und die Version ist 1.18.2.111 oder höher. Informationen zu bestimmten Vorgängen finden Sie unter Erstellen einer ASM-Instanz[1].
  • Der Cluster wurde der ASM-Instanz hinzugefügt. Informationen zu bestimmten Vorgängen finden Sie unter Hinzufügen eines Clusters zu einer ASM-Instanz[2].
  • Ein ASM-Gateway mit dem Namen ingressgateway wurde erstellt. Informationen zu bestimmten Vorgängen finden Sie unter Erstellen eines Ingress-Gateway-Dienstes[3].
  • Es wurde eine Gateway-Regel namens ingressgateway mit dem Namespace istio-system erstellt. Informationen zu bestimmten Vorgängen finden Sie unter Verwalten von Gateway-Regeln[4].
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
 name: ingressgateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - '*'

Schritt 1: Stellen Sie den Beispieldienst bereit

1. Aktivieren Sie die automatische Injektion des Sidecar-Grid-Proxys für den Standard-Namespace. Informationen zu bestimmten Vorgängen finden Sie unter Aktivieren der automatischen Injektion[5]. Weitere Informationen zur automatischen Injektion finden Sie unter Aktivieren der automatischen Sidecar-Injektion[6].

2. Führen Sie den folgenden Befehl im ACK-Cluster aus, um den Beispieldienst bereitzustellen.

kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-v1.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-v2.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-v3.yaml

Schritt 2: Erstellen Sie Fahrspurgruppen und entsprechende Fahrspuren

1. Erstellen Sie eine Spurgruppe.

a. Melden Sie sich bei der ASM-Konsole [7] an und wählen Sie Service Grid > Grid Management in der linken Navigationsleiste .

b. Klicken Sie auf der Rasterverwaltungsseite auf den Namen der Zielinstanz und wählen Sie dann Traffic Management Center > Traffic Lane in der linken Navigationsleiste aus .

c. Klicken Sie auf der Seite „Verkehrsspuren“ auf „Spurgruppe erstellen“ , konfigurieren Sie die relevanten Informationen im Bereich „Spurgruppe erstellen“ und klicken Sie dann auf „OK“ .

Konfigurationselemente veranschaulichen
Name der Spurgruppe Dieses Beispiel ist als Test konfiguriert.
Ingress-Gateway Wählen Sie Ingressgateway aus.
Swimlane-Modus Wählen Sie den entspannten Modus
Header-Einstellungen anfordern Da die Beispielanwendung den Anforderungsheader „my-request-id“ im aufrufenden Link transparent überträgt, überträgt der Link den Anforderungsheader mit „my-request-id“ transparent. Der Anforderungsheader für die Verkehrsumleitung wird vom Gateway verwendet, um den Verkehr auf verschiedene Swimlanes umzuleiten und den Swimlane-Kontext basierend auf dem Inhalt des Anforderungsheaders aufrechtzuerhalten. Er kann beliebig angegeben werden. Tragen Sie hier x-asm-prefer-tag ein der Header der Verkehrsumleitungsanforderung.
Spurdienst Wählen Sie den Ziel-Kubernetes-Cluster und den Standard-Namespace aus, wählen Sie die Dienste „Mocka“, „Mockb“ und „Mockc“ in der Liste unten aus, klicken Sie auf das Symbol und fügen Sie den Zieldienst zum ausgewählten Bereich hinzu.

Nach Abschluss der Konfiguration wird automatisch das entsprechende Verkehrsetikett TrafficLabel generiert. Für den Mocka-Dienst wird beispielsweise das folgende Verkehrslabel TrafficLabel generiert.

apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
 labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: asm-swimlane-test-mocka
  namespace: default
spec:
  rules:
    - labels:
        - name: asm-label
          valueFrom:
            - '$getExternalInboundRequestHeader(x-asm-prefer-tag, my-request-id)'
  workloadSelector:
    labels:
      app: mocka

2. Erstellen Sie die Spuren s1, s2 und s3 und binden Sie die Versionen v1, v2 bzw. v3.

a. Klicken Sie im Bereich zur Definition der Verkehrsregeln auf der Seite „Verkehrs-Schwimmspur“ auf „Schwimmelane erstellen“ .

b. Konfigurieren Sie im Dialogfeld „ Schwimmbahn erstellen“ die relevanten Informationen und klicken Sie dann auf „OK“ .

Konfigurationselemente veranschaulichen
Spurname Geben Sie für verschiedene Spuren jeweils s1, s2 und s3 ein.
Konfigurieren Sie Service-Tags In diesem Beispiel ist der Tag-Name als ASM_TRAFFIC_TAG konfiguriert. Für die Spuren s1, s2 und s3 sind die Tag-Werte als v1, v2 bzw. v3 konfiguriert.
Dienst hinzufügen Wählen Sie für Spur s1 „Mocka“ (Standard), „Mockb“ (Standard) und „Mockc“ (Standard). Wählen Sie für Spur s2 „mocka(default)“ und „mockc(default)“ aus. Wählen Sie für Spur s3 „mockb“ (Standard) aus.

Die folgende Abbildung zeigt ein Beispiel der Schnittstelle beim Erstellen der s1-Schwimmbahn:

Standardmäßig wird die erste Swimlane, die Sie in der Swimlane-Gruppe erstellen, als Baseline-Swimlane festgelegt. Sie können die Baseline-Swimlane ändern. Wenn Datenverkehr an Dienste gesendet wird, die in anderen Swimlanes nicht vorhanden sind, erfolgt die Anforderung wird über den Fallback-Mechanismus an den Dienst weitergeleitet. Baseline Lane.

Nachdem die drei Schwimmbahnen erstellt wurden, sieht der Beispieleffekt wie folgt aus:

Jedes Mal, wenn eine Schwimmbahn erstellt wird, wird automatisch die entsprechende Zielregel DestinationRule erstellt. Nachdem beispielsweise alle Schwimmbahnen erstellt wurden, wird die folgende Zielregel DestinationRule automatisch für den s1-Dienst erstellt.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
 labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-dr-test-default-mocka
  namespace: istio-system
spec:
  host: mocka.default.svc.cluster.local
  subsets:
    - labels:
        ASM_TRAFFIC_TAG: v1
      name: s1
    - labels:
        ASM_TRAFFIC_TAG: v2
      name: s2

Nachdem die drei Schwimmbahnen erstellt wurden, wird für jeden Dienst in der Schwimmbahngruppe ein virtueller Dienst VirtualService generiert, der den Schwimmbahnregeln entspricht. Beispielsweise wird der folgende virtuelle Dienst VirtualService automatisch für den Mocka-Dienst erstellt.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-vs-test-default-mocka
  namespace: istio-system
spec:
  hosts:
    - mocka.default.svc.cluster.local
  http:
    - name: default
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: $asm-label
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

3. Erstellen Sie Verkehrsumleitungsregeln für jede Schwimmspur. Im Folgenden sehen Sie ein Beispiel für die Erstellung von Verkehrsumleitungsregeln für die Fahrspur s1. Bitte führen Sie die folgenden Schritte aus, um Verkehrsumleitungsregeln für die Fahrspuren s2 und s3 zu erstellen.

a. Klicken Sie im Definitionsbereich der Verkehrsregeln der Fahrspurseite auf die Verkehrsumleitungsregel unter der Aktionsspalte auf der rechten Seite der Zielspur .

b. Konfigurieren Sie im Dialogfeld „ Verkehrsumleitungsregel hinzufügen“ die relevanten Informationen und klicken Sie dann auf „OK“ . In diesem Artikel wird die Eingabe-API für Swimlane-Dienste als /mock als Beispiel verwendet und für jede Swimlane dieselben Verkehrsumleitungsregeln konfiguriert.

Konfigurationselemente veranschaulichen
Eingangsservice Wählen Sie „mocka.default.svc.cluster.local“ aus.
Entwässerungsregeln Der Konfigurationsname ist r1 und der Domänenname ist *.
Passen Sie den angeforderten URI an Konfigurieren Sie den Matching-Modus auf „Exact“ und den Matching-Inhalt auf „/mock“.

Nachdem die Verkehrsumleitungsregeln für die drei Fahrspuren erfolgreich erstellt wurden, sieht der Beispieleffekt wie folgt aus:

Nach erfolgreicher Erstellung werden die Verkehrsumleitungsregeln für jede Schwimmspur automatisch generiert, also den virtuellen Dienst VirtualService. Beispielsweise wird der folgende virtuelle Dienst VirtualService für die Schwimmbahn s2 generiert:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: swimlane-ingress-vs-test-s2
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s2
          uri:
            exact: /mock
      name: r2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Schritt 3: Überprüfen Sie, ob die Full-Link-Graustufenfunktion wirksam ist

1. Ermitteln Sie die öffentliche IP des ASM-Gateways. Informationen zu bestimmten Vorgängen finden Sie unter Abrufen der ASM-Gateway-Adresse[8].

2. Führen Sie den folgenden Befehl aus, um Umgebungsvariablen festzulegen. http://xxx.xxx.xxx.xxx  ist die im vorherigen Schritt erhaltene IP.

export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx

3. Überprüfen Sie, ob die vollständige Graustufen-Link-Funktion wirksam ist. a. Führen Sie den folgenden Befehl aus, um den Zugriffseffekt von Spur s1 zu überprüfen. Der Wert s1, der x-asm-prefer-tag entspricht, ist der Lane-Name, der beim Erstellen der s1-Lane in Schritt 2 konfiguriert wurde.

for i in {1..100}; do curl   -H 'x-asm-prefer-tag: s1' -H'my-request-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Erwartete Ausgabe:

-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)

Aus der erwarteten Ausgabe geht hervor, dass der durch Festlegen des HTTP-Headers x-asm-prefer-tag: s1 deklarierte Datenverkehr erwartungsgemäß zu den relevanten Diensten unter der S1-Swimlane fließt.

b. Führen Sie den folgenden Befehl aus, um den Zugriffseffekt der S2-Spur zu überprüfen. Der Wert s2, der x-asm-prefer-tag entspricht, ist der Lane-Name, der beim Erstellen der s2-Lane in Schritt 2 konfiguriert wurde.

for i in {1..100}; do curl   -H 'x-asm-prefer-tag: s2' -H'my-request-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Erwartete Ausgabe:

-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v2, ip: 172.17.0.128)

Von der erwarteten Ausgabe fließt der durch Festlegen des HTTP-Headers x-asm-prefer-tag: s2 deklarierte Datenverkehr zu den relevanten Diensten unter der Schwimmspur s2. Wenn der Datenverkehr an den Dienst Mockb gesendet wird, der in der Schwimmspur nicht vorhanden ist s2, der Datenverkehr wird über den Fallback-Mechanismus gesendet. An den Mockb-Dienst in der Baseline-Swim-Lane s1, wenn nachfolgender Datenverkehr an den Mockc-Dienst gesendet wird, wird das Ziel auf den Mockc-Dienst in der S2-Spur zurückgesetzt, was mit übereinstimmt Erwartungen.

c. Führen Sie den folgenden Befehl aus, um den Zugriffseffekt der S3-Schwimmbahn zu überprüfen. Der Wert s3, der x-asm-prefer-tag entspricht, ist der Lane-Name, der beim Erstellen der s3-Lane in Schritt 2 konfiguriert wurde.

for i in {1..100}; do curl   -H 'x-asm-prefer-tag: s3 -H'my-request-id: x000'$i' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Erwartete Ausgabe:

mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)

Aus der erwarteten Ausgabe erhalten, fließt der durch Festlegen des HTTP-Headers x-asm-prefer-tag: s3 deklarierte Datenverkehr zu den relevanten Diensten unter der S3-Schwimmspur. Wenn der Datenverkehr an die Dienste Mockb und Mockc gesendet wird, die in nicht vorhanden sind In der Swimlane S3 wird der Datenverkehr durch den Fallback-Mechanismus geleitet. Der Mechanismus wird an die Mockb- und Mockc-Dienste in der Basis-Swimlane S1 gesendet, was den Erwartungen entspricht.

Übungsszenario 2 im entspannten Modus: Der Header der Verkehrsumleitungsanforderung wurde transparent im Link übertragen

Im entspannten Modus-Übungsszenario 1 sind der Anforderungsheader für die Verkehrsumleitung und der Anforderungsheader für die transparente Übertragung der Verbindung unterschiedlich (my-request-id bzw. x-asm-prefer-tag). In diesem Fall muss der Inhalt im Anforderungsheader für die transparente Linkübertragung für jede Anforderung unterschiedlich sein (d. h. jeder Aufruf des Links hat eine eindeutige Link-ID). Wenn der Anforderungsheader für die transparente Übertragung der Verbindung auch als Anforderungsheader für die Datenverkehrsumleitung festgelegt ist, sind die oben genannten Einschränkungen für den Anforderungsheader der transparenten Übertragung der Verbindung nicht mehr erforderlich. Sie müssen nur den Inhalt des Anforderungsheaders für die transparente Übertragung der Verbindung verwenden, um den Datenverkehr dorthin umzuleiten verschiedene Schwimmbahnen.

Im zweiten Beispielszenario für den entspannten Modus werden die drei Dienste Mocka, Mockb und Mockc, wie in der Abbildung gezeigt, verwendet, um drei Schwimmspuren zu erstellen, die drei Versionen der Dienstaufrufkette darstellen: s1, s2 und s3. Darunter ist s1 die Basis-Swimlane, die drei vollständige Dienste enthält, während s2 nur zwei Dienste, Mocka und Mockc, enthält und s3 nur einen Dienst, Mockb, enthält. Gleichzeitig werden sowohl der Link-Transparent-Transmission-Request-Header als auch der Traffic-Diversion-Request-Header als my-request-id angegeben.

Voraussetzungen

  • Es wurde eine ASM Enterprise Edition- oder Ultimate Edition-Instanz erstellt und die Version ist 1.18.2.111 oder höher. Informationen zu bestimmten Vorgängen finden Sie unter Erstellen einer ASM-Instanz[1].
  • Der Cluster wurde der ASM-Instanz hinzugefügt. Informationen zu bestimmten Vorgängen finden Sie unter Hinzufügen eines Clusters zu einer ASM-Instanz[2].
  • Ein ASM-Gateway mit dem Namen ingressgateway wurde erstellt. Informationen zu bestimmten Vorgängen finden Sie unter Erstellen eines Ingress-Gateway-Dienstes[3].
  • Es wurde eine Gateway-Regel namens ingressgateway mit dem Namespace istio-system erstellt. Informationen zu bestimmten Vorgängen finden Sie unter Verwalten von Gateway-Regeln[4].
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
 name: ingressgateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - '*'

Schritt 1: Stellen Sie den Beispieldienst bereit

1. Aktivieren Sie die automatische Injektion des Sidecar-Grid-Proxys für den Standard-Namespace. Informationen zu bestimmten Vorgängen finden Sie unter Aktivieren der automatischen Injektion[5]. Weitere Informationen zur automatischen Injektion finden Sie unter Aktivieren der automatischen Sidecar-Injektion[6].

2. Führen Sie den folgenden Befehl im ACK-Cluster aus, um den Beispieldienst bereitzustellen.

kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-v1.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-v2.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-v3.yaml

Schritt 2: Erstellen Sie Fahrspurgruppen und entsprechende Fahrspuren

1. Erstellen Sie eine Spurgruppe.

a. Melden Sie sich bei der ASM-Konsole [7] an und wählen Sie Service Grid > Grid Management in der linken Navigationsleiste .

b. Klicken Sie auf der Rasterverwaltungsseite auf den Namen der Zielinstanz und wählen Sie dann Traffic Management Center > Traffic Lane in der linken Navigationsleiste aus .

c. Klicken Sie auf der Seite „Verkehrsspuren“ auf „Spurgruppe erstellen“ , konfigurieren Sie die relevanten Informationen im Bereich „Spurgruppe erstellen“ und klicken Sie dann auf „OK“ .

Konfigurationselemente veranschaulichen
Name der Spurgruppe Dieses Beispiel ist als Test konfiguriert.
Ingress-Gateway Wählen Sie Ingressgateway aus.
Swimlane-Modus Wählen Sie den entspannten Modus
Header-Einstellungen anfordern In diesem Beispiel lauten sowohl der Anforderungsheader für die Verkehrsumleitung als auch der Anforderungsheader für die transparente Übertragung der Verbindung „my-request-id“.
Spurdienst Wählen Sie den Ziel-Kubernetes-Cluster und den Standard-Namespace aus, wählen Sie die Dienste „Mocka“, „Mockb“ und „Mockc“ in der Liste unten aus, klicken Sie auf das Symbol und fügen Sie den Zieldienst zum ausgewählten Bereich hinzu.

2. Erstellen Sie die Spuren s1, s2 und s3 und binden Sie die Versionen v1, v2 bzw. v3.

a. Klicken Sie im Bereich zur Definition der Verkehrsregeln auf der Seite „Verkehrs-Schwimmspur“ auf „Schwimmelane erstellen“ .

b. Konfigurieren Sie im Dialogfeld „ Schwimmbahn erstellen“ die relevanten Informationen und klicken Sie dann auf „OK“ .

Konfigurationselemente veranschaulichen
Spurname Geben Sie für drei Schwimmbahnen jeweils die Bahnnamen s1, s2 und s3 ein.
Konfigurieren Sie Service-Tags In diesem Beispiel ist der Tag-Name als ASM_TRAFFIC_TAG konfiguriert. Für die Spuren s1, s2 und s3 sind die Tag-Werte als v1, v2 bzw. v3 konfiguriert.
Dienst hinzufügen Wählen Sie für Spur s1 „Mocka“ (Standard), „Mockb“ (Standard) und „Mockc“ (Standard). Wählen Sie für Spur s2 „mocka(default)“ und „mockc(default)“ aus. Wählen Sie für Spur s3 „mockb“ (Standard) aus.

Die folgende Abbildung zeigt ein Beispiel der Schnittstelle beim Erstellen der s1-Schwimmbahn:

Standardmäßig wird die erste Swimlane, die Sie in der Swimlane-Gruppe erstellen, als Baseline-Swimlane festgelegt. Sie können die Baseline-Swimlane ändern. Wenn Datenverkehr an Dienste gesendet wird, die in anderen Swimlanes nicht vorhanden sind, erfolgt die Anforderung wird über den Fallback-Mechanismus an den Dienst weitergeleitet. Baseline Lane.

Nachdem die drei Schwimmbahnen erstellt wurden, sieht der Beispieleffekt wie folgt aus:

Jedes Mal, wenn eine Schwimmbahn erstellt wird, wird automatisch die entsprechende Zielregel DestinationRule erstellt. Nachdem beispielsweise alle Schwimmbahnen erstellt wurden, wird die folgende Zielregel DestinationRule automatisch für den s1-Dienst erstellt.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
 labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-dr-test-default-mocka
  namespace: istio-system
spec:
  host: mocka.default.svc.cluster.local
  subsets:
    - labels:
        ASM_TRAFFIC_TAG: v1
      name: s1
    - labels:
        ASM_TRAFFIC_TAG: v2
      name: s2

Nachdem die drei Schwimmbahnen erstellt wurden, wird für jeden Dienst in der Schwimmbahngruppe ein virtueller Dienst VirtualService generiert, der den Schwimmbahnregeln entspricht. Beispielsweise wird der folgende virtuelle Dienst VirtualService automatisch für den Mocka-Dienst erstellt.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-vs-test-default-mocka
  namespace: istio-system
spec:
  hosts:
    - mocka.default.svc.cluster.local
  http:
    - match:
        - headers:
            my-request-id:
              exact: s1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-request-id:
              exact: s2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-request-id:
              exact: s3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

3. Erstellen Sie Verkehrsumleitungsregeln für jede Schwimmspur. Im Folgenden sehen Sie ein Beispiel für die Erstellung von Verkehrsumleitungsregeln für die Fahrspur s1. Bitte führen Sie die folgenden Schritte aus, um Verkehrsumleitungsregeln für die Fahrspuren s2 und s3 zu erstellen.

a. Klicken Sie im Definitionsbereich der Verkehrsregeln der Fahrspurseite auf die Verkehrsumleitungsregel unter der Aktionsspalte auf der rechten Seite der Zielspur .

b. Konfigurieren Sie im Dialogfeld „ Verkehrsumleitungsregel hinzufügen“ die relevanten Informationen und klicken Sie dann auf „OK“ . In diesem Artikel wird die Eingabe-API für Swimlane-Dienste als /mock als Beispiel verwendet und für jede Swimlane dieselben Verkehrsumleitungsregeln konfiguriert.

Konfigurationselemente veranschaulichen
Eingangsservice Wählen Sie „mocka.default.svc.cluster.local“ aus.
Entwässerungsregeln Der Konfigurationsname ist r1 und der Domänenname ist *.
Passen Sie den angeforderten URI an Konfigurieren Sie den Matching-Modus auf „Exact“ und den Matching-Inhalt auf „/mock“.

Nachdem die Verkehrsumleitungsregeln für die drei Fahrspuren erfolgreich erstellt wurden, sieht der Beispieleffekt wie folgt aus:

Nach erfolgreicher Erstellung werden die Verkehrsumleitungsregeln für jede Schwimmspur automatisch generiert, also den virtuellen Dienst VirtualService. Beispielsweise wird der folgende virtuelle Dienst VirtualService für die Schwimmbahn s2 generiert:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: swimlane-ingress-vs-test-s2
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            my-request-id:
              exact: s2
          uri:
            exact: /mock
      name: r2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Schritt 3: Überprüfen Sie, ob die Full-Link-Graustufenfunktion wirksam ist

1. Ermitteln Sie die öffentliche IP des ASM-Gateways. Informationen zu bestimmten Vorgängen finden Sie unter Abrufen der ASM-Gateway-Adresse[8].

2. Führen Sie den folgenden Befehl aus, um Umgebungsvariablen festzulegen. http://xxx.xxx.xxx.xxx ist die im vorherigen Schritt erhaltene IP.

export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx

3. Überprüfen Sie, ob die vollständige Graustufen-Link-Funktion wirksam ist. a. Führen Sie den folgenden Befehl aus, um den Zugriffseffekt von Spur s1 zu überprüfen. Der Wert s1, der my-request-id entspricht, ist der Lane-Name, der beim Erstellen der s1-Lane in Schritt 2 konfiguriert wurde.

for i in {1..100}; do curl -H'my-request-id: s1' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Erwartete Ausgabe:

-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)

Ausgehend von der erwarteten Ausgabe fließt der durch Festlegen des HTTP-Headers my-request-id: s1 deklarierte Datenverkehr zu den relevanten Diensten unter der S1-Swimlane, was den Erwartungen entspricht.

b. Führen Sie den folgenden Befehl aus, um den Zugriffseffekt der S2-Spur zu überprüfen. Der Wert s2, der my-request-id entspricht, ist der Lane-Name, der beim Erstellen der s2-Lane in Schritt 2 konfiguriert wurde.

for i in {1..100}; do curl -H'my-request-id: s2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Erwartete Ausgabe:

mocka(version: v2, ip: 192.168.1.101)-> mockb(version: v1, ip: 192.168.1.100)-> mockc(version: v2, ip: 192.168.1.116)

Aus der erwarteten Ausgabe fließt der durch Festlegen des HTTP-Headers my-request-id: s2 deklarierte Datenverkehr zu den relevanten Diensten unter der Swimlane s2. Wenn der Datenverkehr an den Dienst Mockb gesendet wird, der in der Swimlane s2 nicht vorhanden ist, Der Datenverkehr wird über den Fallback-Mechanismus an die Baseline gesendet. Für den Mockb-Dienst in Swimlane S1 wird das Ziel auf den Mockc-Dienst in Swimlane S2 zurückgesetzt, wenn nachfolgender Datenverkehr an den Mockc-Dienst gesendet wird, was den Erwartungen entspricht .

c. Führen Sie den folgenden Befehl aus, um den Zugriffseffekt der S3-Schwimmbahn zu überprüfen. Der Wert s3, der my-request-id entspricht, ist der Lane-Name, der beim Erstellen der s3-Lane in Schritt 2 konfiguriert wurde.

for i in {1..100}; do curl -H'my-request-id: s3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Erwartete Ausgabe:

mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)

Von der erwarteten Ausgabe fließt der durch Festlegen des HTTP-Headers my-request-id: s3 deklarierte Datenverkehr zu den relevanten Diensten unter der S3-Swim-Lane. Wenn der Datenverkehr an die Dienste Mockb und Mockc gesendet wird, die in der Swim-Lane nicht vorhanden sind s3, der Datenverkehr wird durch den Fallback-Mechanismus gesendet. Die Dienste für Mockb und Mockc in der Baseline-Spur s1 entsprechen den Erwartungen.

Verwandte Links:

[1] ASM-Instanz erstellen

https://help.aliyun.com/document_detail/147793.html#task-2370657

[2] Cluster zur ASM-Instanz hinzufügen

https://help.aliyun.com/document_detail/148231.html#task-2372122

[3] Erstellen Sie einen Entry-Gateway-Dienst

https://help.aliyun.com/document_detail/150510.html#task-2372970

[4] Gateway-Regeln verwalten

https://help.aliyun.com/document_detail/150504.html

[5] Automatische Injektion aktivieren

https://help.aliyun.com/document_detail/150501.html#section-30o-vil-3n7

[6] Schalten Sie die automatische Sidecar-Einspritzung ein

https://help.aliyun.com/document_detail/186136.html#task-1962690

[7] ASM-Konsole

https://servicemesh.console.aliyun.com/

[8] ASM-Gateway-Adresse abrufen

https://help.aliyun.com/document_detail/444079.html#section-ida-zt6-md7

Autor: Yin Hang

Ursprünglicher Link

Dieser Artikel ist Originalinhalt von Alibaba Cloud und darf nicht ohne Genehmigung reproduziert werden.

Microsoft startet neue „Windows App“ .NET 8 offiziell GA, die neueste LTS-Version Xiaomi gab offiziell bekannt, dass Xiaomi Vela vollständig Open Source ist und der zugrunde liegende Kernel NuttX Alibaba Cloud 11.12 ist. Die Ursache des Fehlers wurde offengelegt: Access Key Service (Access Schlüssel) Ausnahme Vite 5 offiziell veröffentlichter GitHub-Bericht: TypeScript ersetzt Java und wird zur drittbeliebtesten Sprache. Bietet eine Belohnung von Hunderttausenden Dollar für das Umschreiben von Prettier in Rust. Den Open-Source-Autor fragen: „Ist das Projekt noch am Leben?“ Sehr unhöflich und respektloses Bytedance: Verwendung von KI zur automatischen Optimierung von Linux-Kernel-Parameteroperatoren. Zauberoperation: Trennen Sie das Netzwerk im Hintergrund, deaktivieren Sie das Breitbandkonto und zwingen Sie den Benutzer, das optische Modem zu wechseln
{{o.name}}
{{m.name}}

Supongo que te gusta

Origin my.oschina.net/yunqi/blog/10149488
Recomendado
Clasificación