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

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Gateways mit Istio-APIs installieren und upgraden

Cloud Service Mesh bietet Ihnen die Möglichkeit, Gateways als Teil Ihres Service Mesh bereitzustellen und zu verwalten. Ein Gateway beschreibt einen Load-Balancer, der am Rand des Mesh-Netzwerks eingesetzt wird und ein- oder ausgehende HTTP/TCP-Verbindungen empfängt. Gateways werden hauptsächlich zur Verwaltung von eingehendem Traffic verwendet, Sie können Gateways aber auch für andere Arten von Traffic konfigurieren.

Ausgangsgateways: Mit einem Ausgangsgateway können Sie einen bestimmten Ausgangsknoten für den Traffic konfigurieren, der das Mesh-Netzwerk verlässt. So können Sie einschränken, welche Dienste auf externe Netzwerke zugreifen können. Außerdem können Sie den ausgehenden Traffic sicher steuern, um die Sicherheit Ihres Mesh-Netzwerks zu erhöhen.
Ingress-Gateways: Mit einem Ingress-Gateway können Sie einen bestimmten Eingangsknoten konfigurieren, um eingehende HTTP/TCP-Verbindungen zu empfangen.
East-West-Gateways: Ein Proxy für East-West-Traffic, damit Dienstarbeitslasten in einem Multi-Primary-Mesh in verschiedenen Netzwerken clusterübergreifend kommunizieren können. Standardmäßig ist dieses Gateway im Internet öffentlich zugänglich.

Auf dieser Seite finden Sie Best Practices zum Bereitstellen und Aktualisieren der Gateway-Proxys sowie Beispiele zum Konfigurieren Ihrer eigenen Gateway-Proxys istio-ingressgateway und istio-egressgateway.

Gateways können auf verschiedene Arten bereitgestellt werden und Sie können mehr als eine Topologie im selben Cluster verwenden. Weitere Informationen zu diesen Topologien finden Sie in der Istio-Dokumentation unter Gateway deployment topologies.

Best Practices für die Bereitstellung von Gateways

Die Best Practices für die Bereitstellung von Gateways hängen davon ab, ob Sie die verwaltete Datenebene oder die nicht verwaltete Datenebene verwenden.

Best Practices für verwaltete Datenebenen

Aktivieren Sie die verwaltete Datenebene.
Fügen Sie einem Namespace ein verwaltetes Überarbeitungslabel hinzu.
Steuerungsebene und Gateways separat bereitstellen und verwalten.
Als Best Practice für die Sicherheit empfehlen wir, Gateways in einem anderen Namespace als die Steuerungsebene bereitzustellen.
Verwenden Sie die automatische Sidecar-Datei-Einfügung (automatische Einfügung), um die Proxykonfiguration für die Gateways ähnlich wie die Sidecar-Proxys für Ihre Dienste einzufügen.

Diese Best Practices:

Achten Sie darauf, dass Ihre verwalteten Gateways automatisch mit den neuesten Verbesserungen und Sicherheitsupdates auf dem neuesten Stand sind.
Verlagerung der Verwaltung und Wartung von Gatewayinstanzen auf von Cloud Service Mesh verwaltete Datenebenen.

Best Practices für nicht verwaltete Datenebenen

Steuerungsebene und Gateways separat bereitstellen und verwalten.
Als Best Practice für die Sicherheit empfehlen wir, Gateways in einem anderen Namespace als die Steuerungsebene bereitzustellen.
Verwenden Sie die automatische Sidecar-Datei-Einfügung (automatische Einfügung), um die Proxykonfiguration für die Gateways ähnlich wie die Sidecar-Proxys für Ihre Dienste einzufügen.

Diese Best Practices:

Lassen Sie Gateways von Ihren Namespace-Administratoren verwalten, ohne erweiterte Berechtigungen für Ihren gesamten Cluster zu benötigen.
Administratoren können dieselben Bereitstellungstools oder Mechanismen verwenden, die sie zum Verwalten von Kubernetes-Anwendungen für die Bereitstellung und Verwaltung von Gateways verwenden.
Geben Sie Administratoren die volle Kontrolle über die Gatewaybereitstellung und vereinfachen Sie auch die Vorgänge. Wenn ein neues Upgrade verfügbar ist oder sich eine Konfiguration geändert hat, starten Administratoren Gateway-Pods einfach neu, um sie zu aktualisieren. Dadurch ist die Bedienung einer Gateway-Bereitstellung dieselbe wie die Bedienung von Sidecar-Proxys für Ihre Dienste.

Beispielgateway bereitstellen

Um Nutzer mit vorhandenen Bereitstellungstools zu unterstützen, bietet Cloud Service Mesh die gleichen Möglichkeiten zum Bereitstellen eines Gateways wie Istio: IstioOperator, Helm und Kubernetes-YAML. Jede Methode führt zu demselben Ergebnis. Sie können zwar die Methode auswählen, mit der Sie am besten vertraut sind, wir empfehlen jedoch die Kubernetes-YAML-Methode, da sie einfacher zu ändern ist und Sie die Manifeste in der Quellcodeverwaltung speichern können.

In den folgenden Schritten wird beschrieben, wie Sie ein Beispielgateway bereitstellen.

Erstellen Sie einen Namespace für das Gateway, falls Sie noch keinen haben. Ersetzen Sie GATEWAY_NAMESPACE durch den Namen Ihres Namespace.
```
kubectl create namespace GATEWAY_NAMESPACE
```
Aktivieren Sie den Namespace für die Injektion. Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.
Verwaltet (TD)
1. Wenden Sie das Standard-Einschleusungslabel auf den Namespace an.
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Verwaltet (Istiod)
Achtung: Verwaltetes Cloud Service Mesh mit der ISTIOD-Steuerungsebene ist eingestellt. Sie müssen alle verwalteten ISTIOD-Flotten modernisieren, um die Implementierung der TRAFFIC_DIRECTOR-Steuerungsebene zu verwenden.

Empfohlen: Führen Sie den folgenden Befehl aus, um das Standard-Injektionslabel auf den Namespace anzuwenden:
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Für vorhandene Nutzer der verwalteten Istiod-Steuerungsebene: Wir empfehlen die Verwendung der Standardeinschleusung. Die versionsbasierte Einschleusung wird jedoch auch unterstützt. Gehen Sie so vor:
1. Führen Sie folgenden Befehl aus, um die verfügbaren Release-Versionen zu finden:
  
  kubectl -n istio-system get controlplanerevision
  
  Die Ausgabe sieht etwa so aus:
  
  NAME AGE asm-managed-rapid 6d7h
  
  HINWEIS: Wenn in der oberen Liste zwei Versionen der Steuerungsebene angezeigt werden, entfernen Sie eine. Im Cluster werden nicht mehrere Versionen der Steuerungsebene unterstützt.
  
  In der Ausgabe ist der Wert in der Spalte NAME das Versionslabel für die verfügbare Release-Version der Cloud Service Mesh-Version.
2. Wenden Sie das Versionslabel auf den Namespace an.
  
  kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Clusterintern
Achtung:Die clusterinterne Cloud Service Mesh-Bereitstellung mit der ISTIOD-Steuerungsebene in GKE On Google Cloud wird nicht mehr unterstützt. Cloud Service Mesh mit einer clusterinternen Steuerungsebene in Google Distributed Cloud (nur Software) wird weiterhin wie unter Unterstützte Plattformen beschrieben unterstützt.

Empfohlen: Führen Sie den folgenden Befehl aus, um das Standard-Injektionslabel auf den Namespace anzuwenden:
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Wir empfehlen die Standardeinschleusung. Die versionsbasierte Einschleusung wird jedoch auch unterstützt. Gehen Sie so vor:
1. Verwenden Sie den folgenden Befehl, um das Versionslabel für istiod zu finden:
  
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. Wenden Sie das Versionslabel auf den Namespace an. Im folgenden Befehl ist REVISION_LABEL der Wert des Versionslabels istiod, den Sie im vorherigen Schritt notiert haben.
  
  kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Kopieren Sie die Konfigurationsdateien für die Beispielgateways aus dem Repository anthos-service-mesh.
Wechseln Sie in das Verzeichnis samples. Um sicherzustellen, dass Sie sich im richtigen Verzeichnis befinden, führen Sie den Befehl ls aus. Dadurch werden alle Verzeichnisinhalte aufgerufen und Sie können nachsehen, ob es ein Verzeichnis gateways (auf das Sie im nächsten Schritt zugreifen) und online-boutique gibt.
Stellen Sie ein Ingress- oder Egress-Gateway bereit. Sie befinden sich im Verzeichnis samples/gateways/ und können unverändert übernommen oder nach Bedarf geändert werden.
Eingehender Traffic
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
Ausgehender Traffic
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway

Prüfen Sie nach dem Ausführen der Bereitstellung, ob die neuen Dienste ordnungsgemäß funktionieren:

kubectl get pod,service -n GATEWAY_NAMESPACE

Überprüfen Sie, ob die Ausgabe in etwa so aussieht:

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Gateway-Ressourcen wie jede andere Kubernetes-Anwendung verwalten Die Beispiele im anthos-service-mesh-packages-Repository dienen als Orientierungshilfe und für den Schnellstart. Passen Sie sie nach Bedarf an.

Gateway-Selektoren

Sie wenden eine Gateway-Konfiguration auf die istio-ingressgateway- und istio-egressgateway-Proxys an, um den eingehenden und ausgehenden Traffic für Ihr Mesh-Netzwerk zu verwalten. So können Sie festlegen, welcher Traffic in das Mesh-Netzwerk ein- oder aus ihm austreten soll. Die Labels in den Pods einer Gateway-Bereitstellung werden von den Gateway-Konfigurationsressourcen verwendet. Daher ist es wichtig, dass Ihre Gateway-Auswahl mit diesen Labels übereinstimmt.

In den vorherigen Bereitstellungen ist das Label istio=ingressgateway beispielsweise für die Gateway-Pods festgelegt. Wenn Sie eine Gateway-Konfiguration auf diese Bereitstellungen anwenden möchten, müssen Sie dasselbe Label auswählen:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

Ein Beispiel für eine Gateway-Konfiguration und einen virtuellen Dienst finden Sie in der frontend.yaml-Datei der Online Boutique-Beispielanwendung.

Upgrade für Gateways durchführen

Direkte Upgrades

In den meisten Anwendungsfällen sollten Sie ein Upgrade Ihrer Gateways nach dem Muster für direkte Upgrades ausführen. Da Gateways die Pod-Injektion verwenden, werden neu erstellte Gateway-Pods automatisch mit der neuesten Konfiguration eingefügt, die die Version enthält.

Wenn Sie die vom Gateway verwendete Überarbeitung der Steuerungsebene ändern möchten, können Sie das Label istio.io/rev in der Gateway-Bereitstellung festlegen. Dadurch wird auch ein rollierender Neustart ausgelöst.

Verwaltete Steuerungsebene

Da Google die Upgrades der Steuerungsebene für die verwaltete Steuerungsebene verwaltet, können Sie die Gateway-Bereitstellung einfach neu starten. Die neuen Pods werden automatisch mit der neuesten Konfiguration und Version eingefügt.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Clusterinterne Steuerungsebene

Achtung:Die clusterinterne Cloud Service Mesh-Bereitstellung mit der ISTIOD-Steuerungsebene in GKE On Google Cloud wird nicht mehr unterstützt. Cloud Service Mesh mit einer clusterinternen Steuerungsebene in Google Distributed Cloud (nur Software) wird weiterhin wie unter Unterstützte Plattformen beschrieben unterstützt.

Um dasselbe Muster auf Ihre Gateways anzuwenden, wenn die Steuerungsebene clusterintern ist, müssen Sie die vom Gateway verwendete Überarbeitung der Steuerungsebene ändern. Legen Sie das Label istio.io/rev in der Gateway-Bereitstellung fest. Dadurch wird ein rollierender Neustart ausgelöst. Welche Schritte erforderlich sind, hängt davon ab, ob Sie das Überarbeitungslabel für den Namespace und/oder den Gateway-Pod aktualisieren müssen.

Wenn Sie den Namespace für die Einschleusung gekennzeichnet haben, legen Sie das Label istio.io/rev für den Namespace auf den neuen Versionswert fest:
```
  kubectl label namespace GATEWAY_NAMESPACE \
    istio-injection- istio.io/rev=REVISION \
    --overwrite
```

Wenn Sie die Einfügung nur für den Gateway-Pod aktiviert haben, legen Sie das Label istio.io/rev für die Bereitstellung auf den neuen Revisionswert fest, wie in der folgenden Kubernetes-YAML-Datei:

cat <<EOF > gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Cloud Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
EOF

kubectl apply -f gateway-deployment.yaml

Canary-Upgrades (erweitert)

Wenn Sie die Steuerungsebene im Cluster verwenden und die Einführung einer neuen Überarbeitung der Steuerungsebene langsamer steuern möchten, können Sie das Canary-Upgrade-Muster verwenden. Sie können mehrere Versionen einer Gateway-Bereitstellung ausführen und dafür sorgen, dass bei einem Teil Ihres Traffics alles wie erwartet funktioniert. Wenn Sie beispielsweise eine neue Überarbeitung (Canary) einführen möchten, erstellen Sie eine Kopie der Gateway-Bereitstellung. Geben Sie dabei für die neue Überarbeitung das Label istio.io/rev=REVISION an und legen Sie einen neuen Namen fest. istio-ingressgateway-canary:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

Mit dieser Bereitstellung haben Sie zwei Versionen des Gateways, die beide vom selben Dienst ausgewählt werden:

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

Wenn Sie sicher sind, dass Ihre Anwendungen wie erwartet funktionieren, führen Sie den folgenden Befehl aus, um zur neuen Version zu wechseln. Löschen Sie dazu die Bereitstellung mit dem alten istio.io/rev-Labelsatz:

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Wenn beim Testen Ihrer Anwendung mit der neuen Version des Gateways ein Problem aufgetreten ist, führen Sie diesen Befehl aus, um zur alten Version zurückzukehren. Löschen Sie dazu die Bereitstellung mit dem neuen istio.io/rev-Labelsatz:

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

Erweiterte Konfiguration

Gateways bereitstellen, die TLS-Traffic beenden

Weitere Informationen finden Sie im Dokument TLS-Terminierung im Ingress-Gateway einrichten.

TLS-Mindestversion für Gateway konfigurieren

Für Cloud Service Mesh ist die standardmäßige Mindest-TLS-Version für Gatewayserver 1.2. Sie können die Mindest-TLS-Version über das Feld minProtocolVersion konfigurieren. Weitere Informationen finden Sie unter ServerTLSSettings.

Nicht unterstützte Funktionen

Wenn Sie eine TRAFFIC_DIRECTOR-Implementierung der Steuerungsebene haben, werden die folgenden Felder oder Werte in Gateway nicht unterstützt:

ServerTLSSettings.TLSmode mit dem Wert AUTO_PASSTHROUGH
ServerTLSSettings.verifyCertificateSpki
ServerTLSSettings.verifyCertificateHash

Fehlerbehebung bei Gateways

Das Gateway-Bild konnte nicht von `auto` aktualisiert werden.

Wenn Sie ein Gateway bereitstellen oder aktualisieren, fügt Cloud Service Mesh auto als Platzhalter in das Feld image ein. Nach dem Aufruf eines Mutating Webhooks ersetzt Cloud Service Mesh diesen Platzhalter automatisch durch das tatsächliche Cloud Service Mesh-Proxy-Image. Wenn der Aufruf des Mutating-Webhooks fehlschlägt, bleibt der Platzhalter auto erhalten und der Container wird nicht gefunden. Dies wird in der Regel durch ein falsches Namespace-Label verursacht. Achten Sie darauf, dass Sie den richtigen Namespace konfiguriert haben, und stellen Sie das Gateway dann noch einmal bereit oder führen Sie ein Upgrade durch.