Anwendungsfälle für die Datenverkehrsverwaltung für Azure Kubernetes Application Network (Vorschau)

Von Bedeutung

AKS-Vorschaufunktionen sind auf Selbstbedienungsbasis und freiwillig verfügbar. Vorschauversionen werden „im Istzustand“ und „wie verfügbar“ bereitgestellt und sind von den Service Level Agreements und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Azure Kubernetes Application Network Traffic Management verwendet den Istio-Umgebungsmodus und die Kubernetes-Gateway-API , um eine präzise Kontrolle über Dienst-zu-Dienst-Interaktionen innerhalb und über Cluster hinweg zu ermöglichen. Diese Lösung bietet ein umfassendes Spektrum an Verkehrsmanagementfunktionen, darunter:

  • L4/L7-Autorisierungsrichtlinien
  • JWT-Anspruchsbasiertes Routing
  • Verkehrsumleitung
  • Einschleusen von Fehlern

Dieser Artikel enthält schrittweise Anleitungen zum Implementieren dieser Datenverkehrsmanagement-Anwendungsfälle mithilfe des Azure Kubernetes-Anwendungsnetzwerks über mehrere Azure Kubernetes Service (AKS)-Cluster hinweg.

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass Sie über die folgenden Voraussetzungen verfügen:

Überprüfen der Installation von Istio und ztunnel

  1. Überprüfen Sie Istio CRDs mithilfe des kubectl get crds Befehls.

    kubectl --context $CLUSTER_NAME_1 get crds | grep istio

    Ihre Ausgabe sollte die folgenden 14 CRDs für den Istio-Umgebungsmodus anzeigen:

    authorizationpolicies.security.istio.io                            2026-03-12T18:02:11Z
destinationrules.networking.istio.io                               2026-03-12T18:02:11Z
envoyfilters.networking.istio.io                                   2026-03-12T18:02:11Z
gateways.networking.istio.io                                       2026-03-12T18:02:11Z
peerauthentications.security.istio.io                              2026-03-12T18:02:11Z
proxyconfigs.networking.istio.io                                   2026-03-12T18:02:11Z
requestauthentications.security.istio.io                           2026-03-12T18:02:11Z
serviceentries.networking.istio.io                                 2026-03-12T18:02:11Z
sidecars.networking.istio.io                                       2026-03-12T18:02:11Z
telemetries.telemetry.istio.io                                     2026-03-12T18:02:11Z
virtualservices.networking.istio.io                                2026-03-12T18:02:11Z
wasmplugins.extensions.istio.io                                    2026-03-12T18:02:11Z
workloadentries.networking.istio.io                                2026-03-12T18:02:11Z
workloadgroups.networking.istio.io                                 2026-03-12T18:02:11Z

  2. Überprüfen Sie, ob Istio CNI und ztunnel DaemonSet im applink-system-Namespace mit dem kubectl get daemonset-Befehl ausgeführt werden.

    kubectl --context $CLUSTER_NAME_1 --namespace applink-system get daemonset

    Ihre Ausgabe sollte die folgenden DaemonSets mit allen Pods im READY Status anzeigen:

    NAME             DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
istio-cni-node   3         3         3       3            3           kubernetes.io/os=linux   108m
ztunnel          3         3         3       3            3           kubernetes.io/os=linux   107m

Erstellen einer Beispielanwendung

Anwendungsarchitektur

Diese Architektur erweitert die Bookinfo-Beispielanwendung so, dass sie über mehrere AKS-Cluster hinweg ausgeführt wird.

Screenshot eines Architekturdiagramms mit der Bookinfo-Beispielanwendungsarchitektur, die über zwei AKS-Cluster hinweg ausgeführt wird.

  • Cluster 1 hostet:
    • productpage-v1 (Python)
    • reviews-v1 (Java)
    • details-v1 (Ruby)
  • Cluster 2 hostet:
    • reviews-v2 (Java)
    • reviews-v3 (Java)
    • ratings-v1 (Node.js)

Der productpage Dienst sendet Anforderungen an reviews.default.svc.cluster.local. Da der reviews Dienst in beiden AKS-Clustern mit globaler Dienstebene verfügbar ist, können Anforderungen an alle verfügbaren Back-Ends (reviews-v1, reviews-v2oder reviews-v3) über Cluster weitergeleitet werden. Die reviews-v2 und reviews-v3 Dienste rufen auch den ratings Dienst auf, um Bewertungsdaten abzurufen, bevor die Antwort an productpage zurückgegeben wird.

Diese Architektur veranschaulicht, wie sich eine verteilte Anwendung über mehrere Cluster erstrecken kann, während sie weiterhin einen konsistenten Dienstnamen und ein einheitliches Kommunikationsmuster verwenden und eine nahtlose Dienstinteraktion über Clustergrenzen hinweg ermöglichen.

Bereitstellen der Anwendungsdienste

  1. Stellen Sie die productpage-Dienste mithilfe der folgenden kubectl apply-Befehle auf AKS-Cluster 1 bereit:

    kubectl --context $CLUSTER_NAME_1 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l app=productpage
kubectl --context $CLUSTER_NAME_1 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l account=productpage

  2. Stellen Sie die reviews-v1-Dienste mithilfe der folgenden kubectl apply-Befehle auf AKS-Cluster 1 bereit:

    kubectl --context $CLUSTER_NAME_1 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l app=reviews,service=reviews
kubectl --context $CLUSTER_NAME_1 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l account=reviews
kubectl --context $CLUSTER_NAME_1 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l app=reviews,version=v1

  3. Stellen Sie die details Dienste mit den folgenden kubectl apply Befehlen auf AKS-Cluster 1 bereit.

    kubectl --context $CLUSTER_NAME_1 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l app=details
kubectl --context $CLUSTER_NAME_1 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l account=details

  4. Stellen Sie den Curl-Dienst mithilfe des folgenden kubectl apply Befehls auf AKS-Cluster 1 bereit:

    kubectl --context $CLUSTER_NAME_1 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/curl/curl.yaml

  5. Stellen Sie die Dienste reviews-v2 und reviews-v3 mit den folgenden Befehlen kubectl apply in AKS Cluster 2 bereit:

    kubectl --context $CLUSTER_NAME_2 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l app=reviews,service=reviews
kubectl --context $CLUSTER_NAME_2 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l account=reviews
kubectl --context $CLUSTER_NAME_2 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l 'app=reviews,version in (v2,v3)'

  6. Stellen Sie die ratings-Dienste mithilfe der folgenden kubectl apply-Befehle auf AKS-Cluster 2 bereit:

    kubectl --context $CLUSTER_NAME_2 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l app=ratings
kubectl --context $CLUSTER_NAME_2 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/platform/kube/bookinfo.yaml -l account=ratings

Bereitstellen des Ingress-Gateways

  1. Stellen Sie das Eingangsgateway mithilfe des folgenden kubectl apply Befehls in AKS-Cluster 1 bereit:

    kubectl --context $CLUSTER_NAME_1 apply -f https://raw.githubusercontent.com/istio/istio/release-1.29/samples/bookinfo/gateway-api/bookinfo-gateway.yaml

  2. Überprüfen Sie, ob das Gateway mit dem folgenden kubectl get gateway Befehl programmiert ist:

    kubectl --context $CLUSTER_NAME_1 --namespace default get gateway

    Nach etwa einer Minute sollte eine Ausgabe ähnlich wie die folgende angezeigt werden, wobei PROGRAMMED als True angezeigt wird.

    NAME               CLASS   ADDRESS        PROGRAMMED   AGE
bookinfo-gateway   istio   20.112.40.27   True         21s

Hinzufügen einer Anwendung zum Netz

  • Fügen Sie die Anwendung zum Mesh hinzu, indem Sie den default Namespace in beiden AKS-Clustern mit istio.io/dataplane-mode=ambient kennzeichnen:

    kubectl --context $CLUSTER_NAME_1 label namespace default istio.io/dataplane-mode=ambient
kubectl --context $CLUSTER_NAME_2 label namespace default istio.io/dataplane-mode=ambient

Installieren von Waypoint-Diensten und Kennzeichnen von Diensten als global

  1. Installieren Sie waypoint Gateways in beiden Clustern mithilfe der folgenden istioctl waypoint apply Befehle:

    istioctl --context $CLUSTER_NAME_1 waypoint apply --enroll-namespace --wait
istioctl --context $CLUSTER_NAME_2 waypoint apply --enroll-namespace --wait

    Die Ausgabe sollte ähnlich wie folgt aussehen, was darauf hinweist, dass der waypoint angewendet wurde und der default Namespace in beiden Clustern korrekt bezeichnet wurde:

    ✅ waypoint default/waypoint applied
✅ namespace default labeled with "istio.io/use-waypoint: waypoint"
✅ waypoint default/waypoint applied
✅ namespace default labeled with "istio.io/use-waypoint: waypoint"

  2. Überprüfen Sie, ob die waypoint Gateways mit dem folgenden kubectl get gateway waypoint Befehl in beiden Clustern programmiert sind:

    kubectl --context $CLUSTER_NAME_1 get gateway waypoint
kubectl --context $CLUSTER_NAME_2 get gateway waypoint

    Nach etwa einer Minute sollten Sie in beiden Clustern eine ähnliche Ausgabe sehen, wobei PROGRAMMED als True angezeigt wird.

    NAME       CLASS            ADDRESS       PROGRAMMED   AGE
waypoint   istio-waypoint   10.1.78.229   True         28s

  3. Markieren Sie den reviews-v1 Dienst im AKS-Cluster 1 und die reviews-v2 und reviews-v3 Dienste im AKS-Cluster 2 als globale Dienste, indem Sie sie mit istio.io/global="true" kennzeichnen.

    kubectl --context $CLUSTER_NAME_1 label service reviews istio.io/global="true"
kubectl --context $CLUSTER_NAME_2 label service reviews istio.io/global="true"

  4. Markieren Sie die waypoint Dienste als globale Dienste, indem Sie sie istio.io/global="true" in beiden Clustern bezeichnen:

    kubectl --context $CLUSTER_NAME_1 label service waypoint istio.io/global="true"
kubectl --context $CLUSTER_NAME_2 label service waypoint istio.io/global="true"

  5. Überprüfen Sie globale Dienste aus ztunnel-Konfigurationen in beiden Clustern mithilfe des istioctl zc service Befehls. Sie sollten die Dienste reviews und waypoint aus beiden Clustern mit ihren jeweiligen VIPs in der Spalte SERVICE VIP sehen.

    istioctl --context "$CLUSTER_NAME_1" zc service -n applink-system | awk 'NR==1 || $2=="reviews" || $2=="waypoint"'
istioctl --context "$CLUSTER_NAME_2" zc service -n applink-system | awk 'NR==1 || $2=="reviews" || $2=="waypoint"'

    Ihre Ausgabe sollte ähnlich wie das Folgende in beiden Clustern aussehen, was darauf hinweist, dass die reviews und waypoint Dienste mit ihren VIPs als globale Dienste erkannt werden.

    # Output from cluster 1
NAMESPACE         SERVICE NAME                 SERVICE VIP              WAYPOINT ENDPOINTS
default           reviews                      10.1.36.199,10.1.164.195 waypoint 2/2
default           waypoint                     10.1.78.229,10.1.135.117 None     2/2

# Output from cluster 2
NAMESPACE         SERVICE NAME                 SERVICE VIP              WAYPOINT ENDPOINTS
default           reviews                      10.1.36.199,10.1.164.195 waypoint 3/3
default           waypoint                     10.1.78.229,10.1.135.117 None     2/2

Überprüfen des Anwendungszugriffs

Hinweis

Wenn Sie nicht über das Internet auf die Anwendung zugreifen können, stellen Sie sicher, dass die dem Cluster zugeordnete Netzwerksicherheitsgruppe (NSG) eingehenden Internetdatenverkehr über den TCP-Port 80 zum Eingangsgateway zulässt.

  • Greifen Sie über das Eingangsgateway über die folgenden Befehle auf die Anwendung zu:

    export BOOK_INFO_GTW_IP=$(kubectl --context $CLUSTER_NAME_1 -n default get gateway bookinfo-gateway -o jsonpath="{.status.addresses[0].value}")
echo $BOOK_INFO_GTW_IP
curl -I http://$BOOK_INFO_GTW_IP/productpage

    Die Ausgabe sollte etwa wie folgt aussehen, was darauf hinweist, dass die Anwendung über das Gateway zugänglich ist:

    20.112.40.27
HTTP/1.1 200 OK
server: istio-envoy
date: Fri, 13 Mar 2026 17:52:13 GMT
content-type: text/html; charset=utf-8
content-length: 15070
vary: Cookie
x-envoy-upstream-service-time: 571

Implementierung von L4/L7-Autorisierungsrichtlinien

L4-Autorisierungsrichtlinie erzwingen

  1. Wenden Sie eine L4-Autorisierungsrichtlinie an, um den Datenverkehr zu dem productpage-Dienst nur vom Eingangsgateway zuzulassen, indem Sie den folgendenkubectl apply-Befehl verwenden:

    kubectl --context $CLUSTER_NAME_1 apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-ztunnel
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/bookinfo-gateway-istio
EOF

  2. Stellen Sie sicher, dass Sie weiterhin über das Eingangsgateway auf die Anwendung zugreifen können, indem Sie den folgenden Befehl verwenden:

    curl -I http://$BOOK_INFO_GTW_IP/productpage

    Ihre Ausgabe sollte etwa wie folgt aussehen, was darauf hinweist, dass die Anwendung weiterhin über das Gateway zugänglich ist:

    HTTP/1.1 200 OK
server: istio-envoy
date: Fri, 13 Mar 2026 18:00:51 GMT
content-type: text/html; charset=utf-8
content-length: 15068
vary: Cookie
x-envoy-upstream-service-time: 19

  3. Vergewissern Sie sich, dass der Zugriff auf den productpage Dienst von anderen Quellen blockiert wird, indem Sie versuchen, über den folgenden Befehl vom Curl-Pod darauf zuzugreifen:

    kubectl --context $CLUSTER_NAME_1 exec deploy/curl -- curl -s "http://productpage:9080/productpage"

    Ihre Ausgabe sollte etwa wie folgt aussehen, was darauf hinweist, dass der Zugriff aufgrund der L4-Autorisierungsrichtlinie verweigert wird:

    upstream connect error or disconnect/reset before headers. reset reason: connection termination

Erzwingen der L7-Autorisierungsrichtlinie

  1. Wenden Sie eine L7-Autorisierungsrichtlinie an, um nur GET-Anforderungen an den productpage-Dienst vom curl-Dienstkonto mit dem folgenden kubectl apply Befehl zuzulassen:

    kubectl --context $CLUSTER_NAME_1 apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-waypoint
  namespace: default
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/curl
    to:
    - operation:
        methods: ["GET"]
EOF

  2. Aktualisieren Sie die L4-Autorisierungsrichtlinie, um Datenverkehr vom Waypoint zu ztunnel zuzulassen, indem Sie das Dienstkonto waypoint als zulässigen Prinzipal mithilfe des folgenden kubectl apply-Befehls hinzufügen:

    kubectl --context $CLUSTER_NAME_1 apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-ztunnel
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/bookinfo-gateway-istio
        - cluster.local/ns/default/sa/waypoint
EOF

  3. Verwenden Sie zur Prüfung, ob DELETE-Vorgänge für den productpage-Dienst vonCurl-Dienstkonto blockiert werden, den folgenden kubectl exec-Befehl:

    kubectl --context $CLUSTER_NAME_1 exec deploy/curl -- curl -s "http://productpage:9080/productpage" -X DELETE

    Ihre Ausgabe sollte etwa wie folgt aussehen, was darauf hinweist, dass der Zugriff aufgrund der L7-Autorisierungsrichtlinie verweigert wird:

    RBAC: access denied

  4. Überprüfen Sie, ob andere Dienstkonten als Curl mit dem folgenden productpage Befehl am Zugriff auf den kubectl exec Dienst gehindert werden:

    kubectl --context $CLUSTER_NAME_1 exec deploy/reviews-v1 -- curl -s http://productpage:9080/productpage

    Ihre Ausgabe sollte etwa wie folgt aussehen, was darauf hinweist, dass der Zugriff aufgrund der L7-Autorisierungsrichtlinie verweigert wird:

    RBAC: access denied

  5. Stellen Sie sicher, dass GET Anforderungen an den productpage Dienst über das curl-Dienstkonto mit dem folgenden kubectl exec Befehl zulässig sind:

    kubectl --context $CLUSTER_NAME_1 exec deploy/curl -- curl -s http://productpage:9080/productpage | grep -o "<title>.*</title>"

    Ihre Ausgabe sollte etwa wie folgt aussehen, was angibt, dass GET-Anforderungen zulässig sind und auf die productpage zugegriffen werden kann:

    <title>Simple Bookstore App</title>

  6. Überprüfen Sie, ob productpage weiterhin über das Eingangsgateway zugänglich ist, indem Sie den folgenden Befehl verwenden:

    curl -I http://$BOOK_INFO_GTW_IP/productpage

    Die Ausgabe sollte etwa wie folgt aussehen, was darauf hinweist, dass der productpage Zugriff über das Gateway noch möglich ist:

    HTTP/1.1 200 OK
server: istio-envoy
date: Fri, 13 Mar 2026 18:07:02 GMT
content-type: text/html; charset=utf-8
content-length: 15070
vary: Cookie
x-envoy-upstream-service-time: 45

Implementieren des anspruchsbasierten Routings von JWT

Erstellen eines Eingangsgateways und Sichern des Gateways mit JWT-Authentifizierung

  1. Erstellen Sie einen neuen Namespace für das Eingangsgateway mithilfe des kubectl create namespace Befehls.

    kubectl --context $CLUSTER_NAME_1 create namespace applink-ingress

  2. Erstellen Sie ein Eingangsgateway mithilfe der Kubernetes-Gateway-API, und lassen Sie nur Routen aus demselben Namespace mithilfe des folgenden kubectl apply Befehls zu:

    kubectl --context $CLUSTER_NAME_1 apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: applink-ingressgateway
  namespace: applink-ingress
  labels:
    app: applink-ingressgateway
    istio: applink-ingressgateway
spec:
  gatewayClassName: istio
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
EOF

  3. Überprüfen Sie, ob das Gateway mit dem folgenden kubectl get gateway Befehl programmiert ist:

    kubectl --context $CLUSTER_NAME_1 -n applink-ingress get gateway

    Nach etwa einer Minute sollte die Ausgabe ähnlich wie folgt angezeigt werden, wobei PROGRAMMED als True erscheint.

    NAME                     CLASS   ADDRESS         PROGRAMMED   AGE
applink-ingressgateway   istio   20.99.227.197   True         30s

  4. Rufen Sie die OIDC-Aussteller-URL aus dem AKS-Cluster ab, und legen Sie sie als Umgebungsvariable fest.

    export OIDC_ISSUER_URL=$(az aks show --resource-group $AKS_RG --name $CLUSTER_NAME_1 --query "oidcIssuerProfile.issuerUrl" -o tsv)
echo $OIDC_ISSUER_URL

  5. Wenden Sie eine RequestAuthentication-Richtlinie an, um JWT-Token zu überprüfen, die vom AKS-Cluster-OIDC-Aussteller ausgestellt wurden, und leiten Sie das ursprüngliche Token an den reviews Dienst weiter, und ein VirtualService, um den Datenverkehr basierend auf dem reviews Anspruch im JWT-Token mithilfe des folgenden sub Befehls an den kubectl apply Dienst weiterzuleiten:

    envsubst <<EOF | kubectl --context $CLUSTER_NAME_1 apply -f -
apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: bookinfo-ingress-jwt-istio
  namespace: applink-ingress
spec:
  selector:
    matchLabels:
      app: applink-ingressgateway
  jwtRules:
  - issuer: "${OIDC_ISSUER_URL}"
    audiences:
    - "${OIDC_ISSUER_URL}"
    jwksUri: "${OIDC_ISSUER_URL}openid/v1/jwks"
    forwardOriginalToken: true
---
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway-istio
  namespace: applink-ingress
spec:
  selector:
    app: applink-ingressgateway
  servers:
    - hosts:
      - "*"
      port:
        name: http
        number: 80
        protocol: HTTP
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bookinfo-vs-istio
  namespace: applink-ingress
spec:
    hosts:
    - "*"
    gateways:
    - bookinfo-gateway-istio
    http:
    - name: reviews
      match:
      - uri:
          prefix: /
        headers:
          "@request.auth.claims.sub":
            exact: "system:serviceaccount:default:curl"
      route:
      - destination:
          host: reviews.default.svc.cluster.local
          port:
            number: 9080
EOF

  6. Rufen Sie die IP-Adresse des neuen Eingangsgateways ab, und legen Sie sie als Umgebungsvariable fest.

    export NO_REV_GTW_IP=$(kubectl --context $CLUSTER_NAME_1 -n applink-ingress get gateway applink-ingressgateway -o jsonpath="{.status.addresses[0].value}") 
echo $NO_REV_GTW_IP

Überprüfen der JWT-Authentifizierung und des anspruchsbasierten Routings

  1. Überprüfen Sie, ob Anforderungen ohne JWT-Token vom Gateway mit dem folgenden kubectl exec Befehl abgelehnt werden:

    kubectl --context $CLUSTER_NAME_1 exec -it $(kubectl --context $CLUSTER_NAME_1 get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -- curl -v http://$NO_REV_GTW_IP/reviews/1

    Die Ausgabe sollte ähnlich wie folgt aussehen, wobei angegeben wird, dass die Anforderung mit einem Fehler "404 Nicht gefunden" abgelehnt wird, da das JWT-Token fehlt:

    *   Trying 20.99.227.197:80...
* Established connection to 20.99.227.197 (20.99.227.197 port 80) from 10.244.2.0 port 36736 
* using HTTP/1.x
> GET /reviews/1 HTTP/1.1
> Host: 20.99.227.197
> User-Agent: curl/8.16.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 404 Not Found
< date: Fri, 13 Mar 2026 18:30:34 GMT
< server: istio-envoy
< content-length: 0
< 
* Connection #0 to host 20.99.227.197:80 left intact

  2. Überprüfen Sie, ob Anforderungen mit ungültigen JWT-Token vom Gateway mit dem folgenden kubectl exec Befehl abgelehnt werden:

    kubectl --context $CLUSTER_NAME_1 exec -it $(kubectl --context $CLUSTER_NAME_1 get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -- curl -v -H "Authorization: Bearer 123.456.789" http://$NO_REV_GTW_IP/reviews/1

    Die Ausgabe sollte ähnlich wie folgt aussehen, wobei angegeben wird, dass die Anforderung mit einem Fehler "401 Nicht autorisiert" abgelehnt wird, da das JWT-Token ungültig ist:

    *   Trying 20.99.227.197:80...
* Established connection to 20.99.227.197 (20.99.227.197 port 80) from 10.244.2.0 port 33240 
* using HTTP/1.x
> GET /reviews/1 HTTP/1.1
> Host: 20.99.227.197
> User-Agent: curl/8.16.0
> Accept: */*
> Authorization: Bearer 123.456.789
> 
* Request completely sent off
< HTTP/1.1 401 Unauthorized
< www-authenticate: Bearer realm="http://20.99.227.197/reviews/1", error="invalid_token"
< content-length: 29
< content-type: text/plain
< date: Fri, 13 Mar 2026 18:31:40 GMT
< server: istio-envoy
< 
* Connection #0 to host 20.99.227.197:80 left intact
Jwt header is an invalid JSON

  3. Überprüfen Sie, ob Anforderungen mit gültigem JWT-Token vom Gateway zugelassen und mithilfe des folgenden reviews Befehls an den kubectl exec Dienst weitergeleitet werden. Das JWT-Token wird aus dem Dienstkonto-Token abgeleitet, das im curl-Pod bereitgestellt ist. Es wird durch den OIDC-Aussteller des AKS-Clusters ausgegeben.

    kubectl --context $CLUSTER_NAME_1 exec -it $(kubectl --context $CLUSTER_NAME1 get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -- sh -c "export NO_REV_GTW_IP=$NO_REV_GTW_IP; exec sh"

  4. Führen Sie den folgenden Befehl in der interaktiven Shell aus, um eine Anforderung mit dem gültigen JWT-Token an das Gateway zu senden:

    curl -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" http://$NO_REV_GTW_IP/health; echo

    Die Ausgabe sollte etwa wie folgt aussehen, was angibt, dass die Anforderung zulässig ist und der reviews Dienst fehlerfrei ist:

    {"status": "Reviews is healthy"}

  5. Führen Sie den folgenden Befehl in der interaktiven Shell aus, um eine Anforderung mit dem gültigen JWT-Token an das Gateway zu senden, um auf den reviews Dienst zuzugreifen. Die Anforderung sollte zulässig und an den reviews Dienst weitergeleitet werden, da der sub Anspruch im JWT-Token dem wert entspricht, der in der VirtualService-Route übereinstimmungsbedingung angegeben ist.

    curl -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" http://$NO_REV_GTW_IP/reviews/1; echo

    Die Ausgabe sollte ähnlich wie folgt aussehen, wobei angegeben wird, dass die Anforderung zulässig ist und an den reviews Dienst weitergeleitet wird und die Rezension für Produkt 1 zurückgegeben wird:

    {"id": "1","podname": "reviews-v1-12ab34c5de-fg6hi","clustername": "null","reviews": [{  "reviewer": "Reviewer1",  "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!"},{  "reviewer": "Reviewer2",  "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare."}]}

Verlagerung von Traffic zwischen Clustern umsetzen

Wir implementieren eine clusterübergreifende Datenverkehrsverschiebung mithilfe des folgenden Setups in den beiden AKS-Clustern:

  • AKS-Cluster 1: Die reviews-local Dienste wählen nur reviews-v1 Pods aus, und der reviews-remote Dienst wählt absichtlich keine lokalen Pods aus.
  • AKS-Cluster 2: Der reviews-local Dienst wählt absichtlich keine lokalen Pods aus, und der reviews-remote Dienst wählt beide reviews-v2 und reviews-v3 Pods aus.

In diesem Abschnitt werden die Begriffe "Lokal " und "Remote " aus der Perspektive des AKS-Clusters 1 definiert.

  1. Wenden Sie die folgenden Dienstressourcen im AKS-Cluster 1 an, um die Dienste reviews-local und reviews-remote mithilfe der entsprechenden Selektoren und des Befehls kubectl apply einzurichten.

    kubectl --context $CLUSTER_NAME_1 apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: reviews-local
  namespace: default
  labels:
    app: reviews
    service: reviews-local
    istio.io/global: "true"
    istio.io/use-waypoint: waypoint
spec:
  ports:
  - name: http
    port: 9080
    targetPort: 9080
  selector:
    app: reviews
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-remote
  namespace: default
  labels:
    app: reviews
    service: reviews-remote
    istio.io/global: "true"
    istio.io/use-waypoint: waypoint
spec:
  ports:
  - name: http
    port: 9080
    targetPort: 9080
  selector:
    app: reviews
    version: remote
EOF

  2. Wenden Sie die folgenden Dienstressourcen in AKS Cluster 2 an, um die Dienste reviews-local und reviews-remote mit den entsprechenden Selektoren mithilfe des kubectl apply Befehls einzurichten.

    kubectl --context $CLUSTER_NAME_2 apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: reviews-local
  namespace: default
  labels:
    app: reviews
    service: reviews-local
    istio.io/global: "true"
    istio.io/use-waypoint: waypoint
spec:
  ports:
  - name: http
    port: 9080
    targetPort: 9080
  selector:
    app: reviews
    version: local
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-remote
  namespace: default
  labels:
    app: reviews
    service: reviews-remote
    istio.io/global: "true"
    istio.io/use-waypoint: waypoint
spec:
  ports:
  - name: http
    port: 9080
    targetPort: 9080
  selector:
    app: reviews
EOF

  3. Teilen Sie den Datenverkehr für den reviews Dienst 20/80 zwischen den lokalen und Remoteclustern mit dem folgenden kubectl apply Befehl:

    kubectl --context $CLUSTER_NAME1 apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
  namespace: default
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews-local.default.svc.cluster.local
        port:
          number: 9080
      weight: 20
    - destination:
        host: reviews-remote.default.svc.cluster.local
        port:
          number: 9080
      weight: 80
EOF

  4. Überprüfen Sie die Einstellungen mithilfe des folgenden Skripts (sie können die Gewichtungen ändern und sie selbst testen).

    Der Connection: close Header schließt nur die clientseitige HTTP/1.1-Verbindung. Im umgebenden Multicluster können das Ost-West-Gateway und der Wegpunkt weiterhin HBONE-Verbindungen erneut verwenden, so dass Anforderungen an cluster-2 innerhalb eines einzelnen Durchlaufs entweder an reviews-v2 oder an reviews-v3 gebunden bleiben können. Verwenden Sie cluster-1 im Vergleich zum autoritativen Überprüfungssignal cluster-2 für die 20/80 Teilung und behandeln Sie die Sternfarbe nur als illustratives Detail.

    results=()
for i in $(seq 1 20); do
  html=$(curl -sS --http1.1 -H 'Connection: close' http://$BOOK_INFO_GTW_IP/productpage)
  pod=$(printf '%s' "$html" | grep -oE 'reviews-v[0-9]-[a-z0-9-]+' | head -n1)
  if printf '%s' "$pod" | grep -q '^reviews-v1-'; then
    target=cluster-1
  else
    target=cluster-2
  fi
  if printf '%s' "$html" | grep -q 'text-red-500'; then
    star=red
  elif printf '%s' "$html" | grep -q 'text-black-500'; then
    star=black
  else
    star=no-star
  fi

  line=$(printf '%02d  %-10s  %-8s  %s' "$i" "$target" "$star" "$pod")
  echo "$line"
  results+=("$target $star")
done

echo
echo "Summary:"
printf '%s\n' "${results[@]}" | sort | uniq -c

    Beispielausgabe:

    ...

Summary:
3 cluster-1 no-star
17 cluster-2 black

Implementieren der Fehlereinfügung

Einrichten virtueller Dienste

Von Bedeutung

In diesem Abschnitt verwenden wir die im Abschnitt Traffic Shifting erstellten reviews-local- und reviews-remote-Dienste erneut.

  1. Richten Sie virtuelle Dienste für productpage und details Dienste in AKS-Cluster 1 mithilfe des folgenden kubectl apply Befehls ein:

    kubectl --context $CLUSTER_NAME_1 apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: productpage
spec:
  hosts:
  - productpage
  http:
  - route:
    - destination:
        host: productpage
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: details
spec:
  hosts:
  - details
  http:
  - route:
    - destination:
        host: details
EOF

  2. Richten Sie einen virtuellen Dienst für den ratings Dienst in AKS-Cluster 2 mithilfe des folgenden kubectl apply Befehls ein:

    kubectl --context $CLUSTER_NAME_2 apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
EOF

  3. Aktualisieren Sie reviews-remote im AKS-Cluster 2 zur Auswahl von reviews-v2 nur mit dem folgenden kubectl apply-Befehl:

    kubectl --context $CLUSTER_NAME_2 apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: reviews-remote
  namespace: default
  labels:
    app: reviews
    service: reviews-remote
    istio.io/global: "true"
    istio.io/use-waypoint: waypoint
spec:
  ports:
  - name: http
    port: 9080
    targetPort: 9080
  selector:
    app: reviews
    version: v2
EOF

  4. Ändern Sie den virtuellen Dienst für AKS-Cluster 1, um die Anforderungen von Benutzer jason an reviews-remote mithilfe des folgenden Befehls kubectl apply weiterzuleiten:

    kubectl --context $CLUSTER_NAME_1 apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
  namespace: default
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews-remote.default.svc.cluster.local
        port:
          number: 9080
  - route:
    - destination:
        host: reviews-local.default.svc.cluster.local
        port:
          number: 9080
EOF

HTTP-Verzögerung einfügen

  1. Fügen Sie eine siebensekundenlange HTTP-Verzögerung für den Benutzer jason in den ratings-Dienst im AKS-Cluster 2 ein, indem Sie den folgenden kubectl apply Befehl verwenden:

    kubectl --context $CLUSTER_NAME2 apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    fault:
      delay:
        percentage:
          value: 100.0
        fixedDelay: 7s
    route:
    - destination:
        host: ratings
  - route:
    - destination:
        host: ratings
EOF

  2. Um die Auswirkungen dieser Verzögerung zu sehen, öffnen Sie einen Browser, und navigieren Sie zu http://$BOOK_INFO_GTW_IP/productpage. Zunächst sollten Sie unter dem Abschnitt "Buchrezensionen" keine Bewertungssterne sehen, da der gesamte Datenverkehr zu reviews-v1 geht.

  3. Melden Sie sich mit Benutzername jason und jedem gewünschten Kennwort an.

    Screenshot der Anmeldeseite der Book Info-Beispielanwendung.

    Sie sollten feststellen, dass die Webseite sehr langsam wird, wobei jede Aktualisierung etwa sechs Sekunden dauert. Der Abschnitt "Buchrezensionen" sollte einen Fehler anzeigen.

    Screenshot der Fehlermeldung, die angibt, dass Buchrezensionen zurzeit nicht verfügbar sind.

    Das Verkehrsmuster, sobald man sich beim Benutzer jason angemeldet hat, lautet: [(AKS cluster 1) productpage-v1] --(1)--> [(AKS cluster 2) reviews-v2] --(2)--> [(AKS cluster 2) ratings-v1].

    Wenn Sie als jason angemeldet sind, fügen wir eine sieben Sekunden lange Verzögerung in der Verbindung hinzu (2):

    • reviews-v2 verfügt beim Abrufen von Bewertungen über ein Timeout von 10 Sekunden, das die Verzögerung ratings-v1überschreitet, sodass sie auf das Laden von Bewertungen warten kann.
    • productpage-v1 verfügt über ein Timeout von drei Sekunden mit zwei Wiederholungen, was einem Timeout von insgesamt sechs Sekunden entspricht.
    • reviews-v2 wartet weiterhin auf die Antwort von Bewertungen, trifft das Timeout und productpage-v1 gibt einen Fehler auf der Webseite zurück.

Verringern der HTTP-Verzögerung und des Timeouts

In diesem Abschnitt bringen wir den Abschnitt "Buchrezensionen" zurück. Um die Ladezeit der Webseite zu verringern, können wir den Verkehrsverlauf für Benutzer jason ändern, um den Datenverkehr zu reviews-v3 mit einem Timeout von zweieinhalb Sekunden umzuleiten.

  1. Aktualisieren Sie reviews-remote im AKS-Cluster 2 zur Auswahl von reviews-v3 nur mit dem folgenden kubectl apply-Befehl:

    kubectl --context $CLUSTER_NAME_2 apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: reviews-remote
  namespace: default
  labels:
    app: reviews
    service: reviews-remote
    istio.io/global: "true"
    istio.io/use-waypoint: waypoint
spec:
  ports:
  - name: http
    port: 9080
    targetPort: 9080
  selector:
    app: reviews
    version: v3
EOF

    Aktualisiertes Verkehrsmuster: [(AKS cluster 1) productpage-v1] --(1)--> [(AKS cluster 2) reviews-v3] --(2)--> [(AKS cluster 2) ratings-v1]

    Nun wird der Abschnitt "Buchrezensionen" angezeigt, aber Bewertungen fehlen noch, da reviews-v3 nur zweieinhalb Sekunden wartet, bevor das Abrufen aufgegeben wird.

    Screenshot der Buchrezensionen ohne Bewertungen.

  2. Als Nächstes stellen wir den Abschnitt "Bewertungen" wieder her. Verringern Sie die Verzögerung auf ratings-v1 eine Sekunde, indem Sie den folgenden kubectl apply Befehl verwenden:

    kubectl --context $CLUSTER_NAME_2 apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- match:
    - headers:
        end-user:
        exact: jason
    fault:
    delay:
        percentage:
        value: 100.0
        fixedDelay: 1s
    route:
    - destination:
        host: ratings
        subset: v1
- route:
    - destination:
        host: ratings
        subset: v1
EOF

    Die Bewertungssterne werden nun angezeigt, da die Bewertungen eine Sekunde benötigen, um die Antwort zurückzusenden, die innerhalb des Timeouts von reviews-v3 von zweieinhalb Sekunden liegt, das wiederum innerhalb des sechssekündigen Zeitlimits der Produktseite liegt.

    Screenshot, der die geladenen Buchrezensionen und Bewertungen zeigt.

HTTP-Abbruch einfügen

  1. Stellen Sie sicher, dass reviews-remote in AKS-Cluster 2 reviews-v2 erneut ausgewählt wird, indem Sie den folgenden kubectl apply-Befehl verwenden:

    kubectl --context $CLUSTER_NAME_2 apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: reviews-remote
  namespace: default
  labels:
    app: reviews
    service: reviews-remote
    istio.io/global: "true"
    istio.io/use-waypoint: waypoint
spec:
  ports:
  - name: http
    port: 9080
    targetPort: 9080
  selector:
    app: reviews
    version: v2
EOF

  2. Lassen Sie alle Anforderungen von AKS-Cluster 1 reviews-remote erreichen, mit dem folgenden kubectl apply-Befehl.

    kubectl --context $CLUSTER_NAME_1 apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews-remote.default.svc.cluster.local
        port:
          number: 9080
EOF

  3. Fügen Sie einen 503 HTTP-Abbruch für den Benutzer jason in den ratings Dienst in AKS-Cluster 2 ein, indem Sie den folgenden kubectl apply Befehl verwenden:

    kubectl --context $CLUSTER_NAME_2 apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      abort:
        httpStatus: 503
        percentage:
          value: 100
    route:
    - destination:
        host: ratings
EOF

    Unabhängig davon, ob Sie sich anmelden oder nicht, können die Bewertungssterne nicht angezeigt werden, da alle Anfragen an den ratings-Dienst mit dem Fehlercode 503 beantwortet werden.

    Screenshot, der zeigt, dass die Buchbewertungen nicht angezeigt werden, weil alle Anfragen an den Bewertungsdienst einen 503-Fehler zurückgeben.

Verwandte Inhalte

Weitere Informationen zum Azure Kubernetes-Anwendungsnetzwerk finden Sie in den folgenden Artikeln:

  • Zuletzt aktualisiert um