Cloud Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Konfigurationsupdates für die Modernisierung

In diesem Dokument werden Konfigurationsaktualisierungen beschrieben, die Sie möglicherweise an Ihrem verwalteten Cloud Service Mesh vornehmen müssen, bevor Sie Ihr Mesh von der ISTIOD-Steuerungsebene auf die TRAFFIC_DIRECTOR-Steuerungsebene umstellen.

Im Folgenden finden Sie eine Liste möglicher Konfigurationsänderungen, die erforderlich sind, um Ihren Cluster auf die Modernisierung vorzubereiten. In den einzelnen Abschnitten finden Sie eine Anleitung zum Aktualisieren:

Multi-Cluster
Workload Identity Federation for GKE aktivieren
Verwaltete CNI aktivieren
Nicht standardmäßige binäre Verwendung in Sidecar
Zum Istio-Ingress-Gateway migrieren

Weitere Informationen zum Modernisierungsworkflow finden Sie auf der Seite Verwaltete Steuerungsebene modernisieren.

Von Istio-Secrets zu multicluster_mode migrieren

Multi-Cluster-Secrets werden nicht unterstützt, wenn ein Cluster die TRAFFIC_DIRECTOR-Steuerungsebene verwendet. In diesem Dokument wird beschrieben, wie Sie von der Verwendung von Istio-Multi-Cluster-Secrets zu multicluster_mode wechseln können.

Istio-Secrets im Vergleich zu deklarativen APIs

Bei der Open-Source-Istio-Multi-Cluster-Endpunkterkennung wird mit istioctl oder anderen Tools ein Kubernetes-Secret in einem Cluster erstellt. Mit diesem Secret kann ein Cluster Traffic an einen anderen Cluster im Mesh ausgleichen. Die ISTIOD-Steuerungsebene liest dann dieses Secret und leitet den Traffic an diesen anderen Cluster weiter.

Cloud Service Mesh bietet eine deklarative API, mit der sich der Multi-Cluster-Traffic steuern lässt, anstatt Istio-Secrets direkt zu erstellen. Diese API behandelt Istio-Secrets als Implementierungsdetail und ist zuverlässiger als das manuelle Erstellen von Istio-Secrets. Künftige Cloud Service Mesh-Funktionen sind von der deklarativen API abhängig und Sie können diese neuen Funktionen nicht direkt mit Istio-Secrets verwenden. Die deklarative API ist die einzige unterstützte Option.

Wenn Sie Istio-Secrets verwenden, sollten Sie so bald wie möglich zur deklarativen API migrieren. Beachten Sie, dass die Einstellung multicluster_mode jeden Cluster anweist, Traffic an jeden anderen Cluster im Mesh weiterzuleiten. Die Verwendung von Secrets ermöglicht eine flexiblere Konfiguration. Sie können für jeden Cluster konfigurieren, an welchen anderen Cluster im Mesh der Traffic weitergeleitet werden soll. Eine vollständige Liste der Unterschiede zwischen den unterstützten Funktionen der deklarativen API und Istio-Secrets finden Sie unter Unterstützte Funktionen mit Istio APIs.

Von Istio-Secrets zur deklarativen API migrieren

Wenn Sie Cloud Service Mesh mit automatischer Verwaltung über die Fleet Feature API bereitgestellt haben, müssen Sie diese Anleitung nicht befolgen. Diese Schritte gelten nur, wenn Sie die Einrichtung mit asmcli --managed durchgeführt haben.

Hinweis: Bei diesem Vorgang werden Secrets geändert, die auf einen Cluster verweisen. Dabei werden die Endpunkte entfernt und dann wieder hinzugefügt. In der Zeit zwischen dem Entfernen und Hinzufügen der Endpunkte wird der Traffic kurzzeitig lokal weitergeleitet, anstatt über das Load Balancing an andere Cluster weitergeleitet zu werden. Weitere Informationen finden Sie im GitHub-Problem.

So wechseln Sie von Istio-Secrets zur deklarativen API: Führen Sie die folgenden Schritte gleichzeitig oder direkt hintereinander aus:

Aktivieren Sie die deklarative API für jeden Cluster in der Flotte, in dem Sie die Endpunkterkennung für mehrere Cluster aktivieren möchten. Legen Sie dazu multicluster_mode=connected fest. Sie müssen multicluster_mode=disconnected explizit festlegen, wenn der Cluster nicht auffindbar sein soll.

Mit dem folgenden Befehl können Sie einen Cluster für die clusterübergreifende Endpunkterkennung aktivieren:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Verwenden Sie den folgenden Befehl, um die Endpunkterkennung für einen Cluster zu deaktivieren:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Löschen Sie alte Secrets.

Nachdem Sie multicluster_mode=connected für Ihre Cluster festgelegt haben, wird für jeden Cluster ein neues Secret für jeden anderen Cluster generiert, für den auch multicluster_mode=connected festgelegt ist. Das Secret wird im Namespace „istio-system“ platziert und hat das folgende Format:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
Auf jedes Secret wird außerdem das Label istio.io/owned-by: mesh.googleapis.com angewendet.

Nachdem die neuen Secrets erstellt wurden, können Sie alle manuell mit istioctl create-remote-secret erstellten Secrets löschen:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Prüfen Sie nach der Migration die Messwerte für Anfragen, um sicherzustellen, dass sie wie erwartet weitergeleitet werden.

Identitätsföderation von Arbeitslasten für GKE aktivieren

Die Identitätsföderation von Arbeitslasten ist die empfohlene sichere Methode für Google Kubernetes Engine-Arbeitslasten. So erhalten Sie Zugriff auf Google Cloud Dienste wie Compute Engine, BigQuery und Machine Learning APIs. Da die Workload Identity-Föderation IAM-Richtlinien verwendet, sind keine manuelle Konfiguration oder weniger sichere Methoden wie Dienstkonto-Schlüsseldateien erforderlich. Weitere Informationen zur Identitätsföderation von Arbeitslasten finden Sie unter Funktionsweise der Identitätsföderation von Arbeitslasten für GKE.

Im folgenden Abschnitt wird beschrieben, wie Sie die Workload Identity-Föderation aktivieren.

Workload Identity-Föderation in Clustern aktivieren

Prüfen Sie, ob die Identitätsförderung von Arbeitslasten für Ihren Cluster aktiviert ist. Dazu muss im GKE-Cluster ein Workload Identity-Föderationspool konfiguriert sein. Dies ist für die Validierung von IAM-Anmeldedaten erforderlich.

Mit dem folgenden Befehl können Sie den für einen Cluster festgelegten Workload Identity-Pool prüfen:
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```
Ersetzen Sie dabei CLUSTER_NAME durch den Namen Ihres GKE-Cluster. Wenn Sie noch keine Standardzone oder -region für gcloud angegeben haben, müssen Sie beim Ausführen dieses Befehls evtl. das Flag --region oder --zone angeben.
Wenn die Ausgabe leer ist, folgen Sie der Anleitung unter Vorhandenen Cluster aktualisieren, um Workload Identity für vorhandene GKE-Cluster zu aktivieren.

Workload Identity-Föderation für Knotenpools aktivieren

Nachdem die Identitätsföderation von Arbeitslasten in einem Cluster aktiviert wurde, müssen Knotenpools für die Verwendung des GKE-Metadatenservers konfiguriert werden.

Listet alle Knotenpools eines Standardclusters auf. Führen Sie den Befehl gcloud container node-pools list aus:
```
gcloud container node-pools list --cluster CLUSTER_NAME
```
Ersetzen Sie dabei CLUSTER_NAME durch den Namen Ihres GKE-Cluster. Wenn Sie noch keine Standardzone oder -region für gcloud angegeben haben, müssen Sie beim Ausführen dieses Befehls evtl. das Flag --region oder --zone angeben.
Prüfen Sie, ob jeder Knotenpool den GKE-Metadatenserver verwendet:
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
Ersetzen Sie Folgendes:
- NODEPOOL_NAME durch den Namen Ihres Knotenpools.
- CLUSTER_NAME durch den Namen Ihres GKE-Cluster.
Wenn die Ausgabe nicht GKE_METADATA enthält, aktualisieren Sie den Knotenpool anhand der Anleitung Vorhandenen Knotenpool aktualisieren.

Verwaltete Container Network Interface (CNI) aktivieren

In diesem Abschnitt erfahren Sie, wie Sie verwaltetes CNI für Cloud Service Mesh in der Google Kubernetes Engine aktivieren.

Verwaltete CNI – Übersicht

Das Managed Container Network Interface (CNI) ist eine von Google verwaltete Implementierung des Istio CNI. Das CNI-Plug-in optimiert das Pod-Netzwerk, indem es iptables-Regeln konfiguriert. Dadurch wird die Weiterleitung von Traffic zwischen Anwendungen und Envoy-Proxys ermöglicht. Es sind keine privilegierten Berechtigungen für den Init-Container mehr erforderlich, die zum Verwalten von iptables erforderlich sind.

Der istio-init-Container wird durch das Istio CNI-Plug-in ersetzt. Der istio-init-Container war zuvor für die Einrichtung der Netzwerkumgebung des Pods verantwortlich, um das Abfangen von Traffic für die Istio-Sidecar zu ermöglichen. Das CNI-Plug-in führt dieselbe Netzwerkweiterleitungsfunktion aus, hat aber den zusätzlichen Vorteil, dass weniger erhöhte Berechtigungen erforderlich sind, was die Sicherheit erhöht.

Daher ist für eine verbesserte Sicherheit und Zuverlässigkeit sowie zur Vereinfachung der Verwaltung und Fehlerbehebung eine verwaltete CNI für alle verwalteten Cloud Service Mesh-Bereitstellungen erforderlich.

Auswirkungen auf Init-Container

Init-Container sind spezielle Container, die vor Anwendungscontainern für Einrichtungsaufgaben ausgeführt werden. Zu den Einrichtungsaufgaben gehören z. B. das Herunterladen von Konfigurationsdateien, die Kommunikation mit externen Diensten oder die Vorabinitialisierung der Anwendung. Bei Init-Containern, die auf den Netzwerkzugriff angewiesen sind, können Probleme auftreten, wenn die verwaltete CNI im Cluster aktiviert ist.

So richten Sie einen Pod mit verwalteter CNI ein:

Das CNI-Plug-in richtet Pod-Netzwerkschnittstellen ein, weist Pod-IPs zu und leitet Traffic an den Istio-Sidecar-Proxy weiter, der noch nicht gestartet wurde.
Alle Init-Container werden ausgeführt und abgeschlossen.
Der Istio-Sidecar-Proxy wird zusammen mit den Anwendungscontainern gestartet.

Wenn ein Init-Container also versucht, ausgehende Netzwerkverbindungen herzustellen oder eine Verbindung zu Diensten innerhalb des Mesh herzustellen, werden die Netzwerkanfragen der Init-Container möglicherweise verworfen oder falsch weitergeleitet. Das liegt daran, dass der Istio-Sidecar-Proxy, der den Netzwerkverkehr für den Pod verwaltet, nicht ausgeführt wird, wenn die Anfragen gestellt werden. Weitere Informationen finden Sie in der Istio CNI-Dokumentation.

Verwaltete CNI für Ihren Cluster aktivieren

Führen Sie die Schritte in diesem Abschnitt aus, um die verwaltete CNI in Ihrem Cluster zu aktivieren.

Entfernen Sie Netzwerkabhängigkeiten aus Ihrem Init-Container. Sie haben folgende Möglichkeiten:
- Anwendungslogik oder Container ändern:Sie können Ihre Dienste so ändern, dass die Abhängigkeit von Init-Containern, die Netzwerkanfragen erfordern, aufgehoben wird. Außerdem können Sie Netzwerkvorgänge in Ihren Anwendungscontainern ausführen, nachdem der Sidecar-Proxy gestartet wurde.
- Kubernetes-ConfigMaps oder ‑Secrets verwenden:Speichern Sie die von der Netzwerkanfrage abgerufenen Konfigurationsdaten in Kubernetes-ConfigMaps oder ‑Secrets und binden Sie sie in Ihre Anwendungscontainer ein. Alternative Lösungen finden Sie in der Istio-Dokumentation.
Verwaltete CNI in Ihrem Cluster aktivieren:
1. Nehmen Sie die folgenden Konfigurationsänderungen vor:
  1. Führen Sie den folgenden Befehl aus, um den controlPlaneRevision zu finden.
```
kubectl get controlplanerevision -n istio-system
```
  2. Legen Sie in Ihrer benutzerdefinierten ControlPlaneRevision-Ressource (CPR) das Label mesh.cloud.google.com/managed-cni-enabled auf true fest.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite
```
    Ersetzen Sie CPR_NAME durch den Wert in der Spalte „NAME“ aus der Ausgabe des vorherigen Schritts.
  3. Legen Sie in der ConfigMap „asm-options“ den Wert für ASM_OPTS auf CNI=on fest.
```
kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'
```
  4. Legen Sie in Ihrer benutzerdefinierten ControlPlaneRevision-Ressource (CPR) das Label mesh.cloud.google.com/force-reprovision auf true fest. Dadurch wird die Steuerungsebene neu gestartet.
    
    Hinweis: Diese Methode wird nicht empfohlen, um die Steuerungsebene neu zu starten. Sie sollte nur für die Modernisierung von Cloud Service Mesh verwendet werden.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite
```
2. Prüfen Sie den Status der Funktion. Rufen Sie den Funktionsstatus mit dem folgenden Befehl ab:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
  Ersetzen Sie FLEET_PROJECT_ID durch die ID Ihres Flotten-Hostprojekts. In der Regel hat die FLEET_PROJECT_ID denselben Namen wie das Projekt.
  - Prüfen Sie, ob die Bedingung MANAGED_CNI_NOT_ENABLED aus servicemesh.conditions entfernt wurde.
  - Es kann bis zu 15 bis 20 Minuten dauern, bis der Status aktualisiert wird. Warten Sie einige Minuten und führen Sie den Befehl dann noch einmal aus.
3. Sobald der controlPlaneManagement.state im Cluster den Status Active hat, starten Sie die Pods neu.

Nicht standardmäßige Binärnutzung in Sidecar beenden

In diesem Abschnitt werden Möglichkeiten beschrieben, Ihre Bereitstellungen mit dem distroless-Envoy-Proxy-Image kompatibel zu machen.

Distroless-Envoy-Proxy-Sidecar-Images

Cloud Service Mesh verwendet je nach Konfiguration der Steuerungsebene zwei Arten von Envoy-Proxy-Sidecar-Images: ein Ubuntu-basiertes Image mit verschiedenen Binärdateien und ein Distroless-Image. Distroless-Basis-Images sind minimale Container-Images, bei denen Sicherheit und Ressourcenoptimierung im Vordergrund stehen, da nur die wichtigsten Komponenten enthalten sind. Die Angriffsfläche wird reduziert, um Sicherheitslücken zu vermeiden. Weitere Informationen finden Sie in der Dokumentation zum Distroslosen Proxy-Image.

Binäre Kompatibilität

Als Best Practice sollten Sie den Inhalt einer Containerlaufzeit auf die erforderlichen Pakete beschränken. Dieser Ansatz verbessert die Sicherheit und das Signal-Rausch-Verhältnis von CVE-Scannen (Common Vulnerabilities and Exposures). Das Distroless-Sidecar-Image enthält nur eine minimale Anzahl von Abhängigkeiten und ist frei von allen nicht erforderlichen ausführbaren Dateien, Bibliotheken und Debugging-Tools. Daher ist es nicht möglich, einen Shell-Befehl auszuführen oder curl, ping oder andere Debug-Dienstprogramme wie kubectl exec im Container zu verwenden.

Cluster mit distroless-Images kompatibel machen

Entfernen Sie Verweise auf nicht unterstützte Binärdateien (z. B. bash oder curl) aus Ihrer Konfiguration. Insbesondere in den Prüfungen für Bereitschaft, Start und Aktivität sowie in den Lifecycle-Hooks „PostStart“ und „PreStop“ in den Containern „istio-proxy“, „istio-init“ oder „istio-validation“.
Für bestimmte Anwendungsfälle können Sie Alternativen wie holdApplicationUntilProxyStarts in Betracht ziehen.
Zum Debuggen können Sie sitzungsspezifische Container verwenden, um sie an einen laufenden Arbeitslast-Pod anzuhängen. Sie können sie dann prüfen und benutzerdefinierte Befehle ausführen. Ein Beispiel finden Sie unter Cloud Service Mesh-Protokolle erfassen.

Wenn Sie keine Lösung für Ihren speziellen Anwendungsfall finden, wenden Sie sich an den Support. Google Cloud

Zum Istio Ingress Gateway migrieren

In diesem Abschnitt erfahren Sie, wie Sie zu Istio Ingress Gateway migrieren. Es gibt zwei Methoden für die Migration zum Istio Ingress Gateway:

Stufenweise Migration mit Traffic-Aufteilung

Bei dieser Methode wird der Ausfall minimiert, indem Sie den Traffic schrittweise an das neue Istio-Gateway senden. So können Sie die Leistung bei einem kleinen Prozentsatz der Anfragen überwachen und bei Bedarf schnell wieder zu der vorherigen Version zurückkehren. Beachten Sie, dass die Konfiguration der Layer 7-Traffic-Aufteilung für einige Anwendungen schwierig sein kann. Daher müssen Sie während der Umstellung beide Gateway-Systeme gleichzeitig verwalten. Eine detaillierte Anleitung finden Sie unter Phasenweise Migration mit Traffic-Aufteilung.
Direkte Migration

Bei dieser Methode wird der gesamte Traffic nach gründlichen Tests gleichzeitig an das neue Istio-Gateway weitergeleitet. Der Vorteil dieses Ansatzes besteht in der vollständigen Trennung von der Infrastruktur des alten Gateways, was eine anpassbare Konfiguration des neuen Gateways ohne die Einschränkungen der vorhandenen Einrichtung ermöglicht. Es besteht jedoch ein erhöhtes Risiko von Ausfallzeiten, falls während der Umstellung unerwartete Probleme mit dem neuen Gateway auftreten. Eine Anleitung dazu finden Sie unter Direkte Migration.

In den folgenden Migrationsbeispielen wird davon ausgegangen, dass Sie einen HTTP-Dienst (httpbin) haben, der im Anwendungs-Namespace (Standard) ausgeführt und extern über die Kubernetes Gateway API verfügbar gemacht wird. Die relevanten Konfigurationen sind:

Gateway: k8-api-gateway (im Namespace istio-ingress) – konfiguriert, um HTTP-Traffic auf Port 80 für jeden Hostnamen zu überwachen, der auf .example.com endet.
HTTPRoute: httpbin-route (im Namespace default): Leitet jede HTTP-Anfrage mit dem Hostnamen httpbin.example.com und einem Pfad, der mit /get beginnt, an den httpbin-Dienst im Namespace default weiter.
Auf die httpbin-Anwendung kann über die externe IP-Adresse 34.57.246.68 zugegriffen werden.

Einfaches Gateway-Diagramm

Stufenweise Migration mit Traffic-Aufteilung

Neues Istio-Ingress-Gateway bereitstellen

Stellen Sie ein neues Ingress-Gateway bereit, indem Sie den Schritten im Abschnitt Beispiel-Gateway bereitstellen folgen, und passen Sie die Beispielkonfigurationen an Ihre Anforderungen an. Die Samples im Repository anthos-service-mesh sind für die Bereitstellung eines istio-ingressgateway-Load Balancer-Dienstes und der entsprechenden ingress-gateway-Pods gedacht.

Beispiel für eine Gateway-Ressource (istio-ingressgateway.yaml)

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

Wenden Sie die Gateway-Konfiguration an, um den Traffic zu verwalten:
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
Achten Sie darauf, dass „spec.selector“ in Ihrer Gateway-Ressource mit den Labels Ihrer ingress-gateway-Pods übereinstimmt. Wenn die ingress-gateway-Pods beispielsweise das Label istio=ingressgateway haben, muss in der Gateway-Konfiguration auch das Label istio=ingressgateway ausgewählt sein.

Erstes Routing für das neue Gateway konfigurieren

Definieren Sie die anfänglichen Routingregeln für Ihre Anwendung mit einem Istio-VirtualService.

Beispiel für einen VirtualService (my-app-vs-new.yaml):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

Wenden Sie den VirtualService an:

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

Über das neu bereitgestellte Istio-Ingress-Gateway auf den Back-End-Dienst (httpbin) zugreifen

Legen Sie die Umgebungsvariable „Ingress Host“ auf die externe IP-Adresse fest, die dem kürzlich bereitgestellten istio-ingressgateway-Load Balancer zugewiesen ist:
```
export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
Prüfen Sie, ob über das neue Gateway auf die Anwendung (httpbin) zugegriffen werden kann:
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
Die Ausgabe sieht etwa so aus:
```
HTTP/1.1 200 OK
```

Anfrageablauf mit dem neuen Istio-Ingress-Gateway

Vorhandenen Ingress für die Traffic-Aufteilung ändern

Nachdem Sie die erfolgreiche Einrichtung des neuen Gateways (z. B. istio-api-gateway) bestätigt haben, können Sie einen Teil Ihres Traffics darüber weiterleiten. Aktualisieren Sie dazu Ihre aktuelle HTTPRoute, um einen kleinen Prozentsatz des Traffics an das neue Gateway weiterzuleiten, während der größere Teil weiterhin das vorhandene Gateway (k8-api-gateway) verwendet.

Öffnen Sie die httproute zum Bearbeiten:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Fügen Sie eine neue Backend-Referenz hinzu, die auf den Load Balancer-Dienst des neuen Ingress-Gateways mit einer anfänglichen Gewichtung von 10% verweist, und aktualisieren Sie die Gewichtung für das Backend des alten Gateways.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

Gewähren Sie mit einer Referenzgenehmigung die Berechtigung für Namespace-übergreifende Verweise.

Wenn Sie Ihrem HTTPRoute im Anwendungs-Namespace (standardmäßig) Zugriff auf den loadbalancer-Dienst im Gateway-Namespace (istio-ingress) gewähren möchten, müssen Sie möglicherweise eine Referenzberechtigung erstellen. Diese Ressource dient als Sicherheitskontrollelement, das explizit definiert, welche Namespace-übergreifenden Referenzen zulässig sind.

In der folgenden istio-ingress-grant.yaml-Datei wird ein Beispiel für einen Referenzzuschuss beschrieben:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute 
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway

Wenden Sie die Referenzgenehmigung an:

kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

Anfragen an vorhandene externe IP-Adressen prüfen (z. B. 34.57.246.68) nicht fehlschlagen. Im folgenden check-traffic-flow.sh wird ein Script zum Prüfen von Fehlern bei Anfragen beschrieben:

# Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

Führen Sie das Script aus, um zu prüfen, ob unabhängig von der Traffic-Route keine Anfragen fehlschlagen:
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

Anfrageablauf mit Traffic-Aufteilung zwischen vorhandenem Gateway und neuem Istio-Ingress-Gateway

Prozentsatz der Zugriffe langsam erhöhen

Wenn für die vorhandene externe IP-Adresse (z. B. 34.57.246.68) keine Fehlermeldungen auftreten, lenken Sie nach und nach mehr Traffic an das neue Istio Ingress-Gateway weiter, indem Sie die Backend-Gewichte in HTTPRoute anpassen. Erhöhen Sie die Gewichtung für istio-ingressgateway und verringern Sie die Gewichtung für das alte Gateway in kleinen Schritten wie 10%, 20 % usw.

Verwenden Sie den folgenden Befehl, um Ihre vorhandene HTTPRoute zu aktualisieren:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Vollständige Migration des Traffics und Entfernen des alten Gateways

Wenn das neue Istio Ingress Gateway eine stabile Leistung und eine erfolgreiche Anfrageverarbeitung aufweist, leiten Sie den gesamten Traffic dorthin um. Aktualisieren Sie HTTPRoute, um das Backend-Gewicht des alten Gateways auf 0 und das des neuen Gateways auf 100 festzulegen.
Sobald der Traffic vollständig an das neue Gateway weitergeleitet wird, aktualisieren Sie Ihre externen DNS-Einträge für den Hostnamen Ihrer Anwendung (z. B. httpbin.example.com), damit sie auf die externe IP-Adresse des Load Balancer-Dienstes verweisen, der unter Neues Istio Ingress-Gateway bereitstellen erstellt wurde.

Löschen Sie abschließend das alte Gateway und die zugehörigen Ressourcen:

kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

Direkte Migration