Sie sehen die Legacy-Dokumentation zum Service Mesh der Version 1.18.

Verfügbare Versionen

Cloud Service Mesh
1.20-Archiv
1.19-Archiv
1.18-Archiv

Diese Seite wurde von der Cloud Translation API übersetzt.

Gateways installieren und upgraden

Mit Cloud Service Mesh haben Sie die Möglichkeit, Gateways als Teil eines Ihr Service Mesh. Ein Gateway beschreibt einen Load-Balancer, der am Rand des Mesh-Netzwerks ausgeführt wird und eingehende oder ausgehende HTTP/TCP-Verbindungen empfängt. Gateways sind Envoy-Proxys, die Ihnen eine detaillierte Kontrolle über den in das Mesh-Netzwerk eingehenden und ausgehenden Traffic ermöglichen. Gateways werden hauptsächlich zum Verwalten des eingehenden Traffics verwendet. Sie können jedoch auch Gateways konfigurieren, um andere Arten von Traffic zu verwalten. Beispiel:

Gateways für ausgehenden Traffic: Mit einem Gateway für ausgehenden Traffic können Sie einen dedizierten Ausgangsknoten für den Traffic konfigurieren, der das Mesh-Netzwerk verlässt, und einschränken, welche Dienste auf externe Netzwerke zugreifen können. Außerdem können Sie damit den ausgehenden Traffic sicher steuern, um Ihrem Mesh beispielsweise mehr Sicherheit hinzuzufügen.
East-west-Gateways: Ein Proxy für east-west-Traffic, damit Dienstarbeitslasten über Clustergrenzen hinweg in einem Multi-Primary-Mesh-Netzwerk in verschiedenen Netzwerken 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. Dinge wie Trafficaufteilung, Weiterleitungen und Wiederholungslogik sind möglich, Anwenden eines Gateway Konfiguration an die Gateway-Proxys. Statt die Anwendungsebene für das Traffic-Routing (L7) an dieselbe API-Ressource Virtueller Dienst an das Gateway an. Auf diese Weise können Sie den Gateway-Traffic wie jeden anderen Traffic auf Datenebene im Service Mesh verwalten.

Sie können Gateways auf verschiedene Arten bereitstellen und festlegen, dass mehrere Topologien innerhalb desselben Clusters verwendet werden. Weitere Informationen finden Sie unter Topologien für die Gatewaybereitstellung finden Sie in der Istio-Dokumentation weitere Informationen zu diesen Topologien.

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, dass Sie Gateways in einem anderen Namespace über die Steuerungsebene bereitstellen.
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.
Verlagert die Verwaltung und Wartung von Gateway-Instanzen in Cloud Service Mesh verwaltete Datenebene.

Best Practices für nicht verwaltete Datenebenen

Steuerungsebene und Gateways separat bereitstellen und verwalten.
Als Best Practice für die Sicherheit empfehlen wir, dass Sie Gateways in einem anderen Namespace über die Steuerungsebene bereitstellen.
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. Das Ausführen einer Gateway-Bereitstellung entspricht somit dem Ausführen von Sidecar-Proxys für Ihre Dienste.

Gateways bereitstellen

Zur Unterstützung von Nutzern mit vorhandenen Bereitstellungstools unterstützt Cloud Service Mesh die haben die gleichen Möglichkeiten, ein Gateway bereitzustellen wie Istio: IstioOperator, Helm und Kubernetes-YAML-Datei. Jede Methode führt zu demselben Ergebnis. Sie können zwar die Methode auswählen, die Sie am häufigsten verwenden, wir empfehlen jedoch, die YAML-Methode von Kubernetes zu verwenden, da sie einfacher zu ändern ist und hydrierte Manifeste in der Versionsverwaltung speichern kann.

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
```
Um die automatische Einfügung zu aktivieren, versehen Sie Ihre Namespaces mit den Standard-Injektionslabels, wenn das Standard-Tag eingerichtet ist, oder Sie wenden das Überarbeitungslabel auf Ihren Namespace an. Welches Label Sie hinzufügen, hängt auch davon ab, ob Sie verwaltetes Cloud Service Mesh oder die clusterinterne Steuerungsebene installiert. Das Label wird vom Sidecar verwendet Injector-Webhook, um eingefügte Sidecars mit einem bestimmten Steuerelement zu verknüpfen Überarbeitung der Ebene.

Wählen Sie unten den Tab entsprechend Ihrem Installationstyp (entweder verwaltet oder im Cluster) aus.
Verwaltet
Verwenden Sie folgenden Befehl, um die verfügbaren Release-Kanäle zu finden:
```
kubectl -n istio-system get controlplanerevision
```
Die Ausgabe sieht in etwa so aus:
```
NAME                AGE
asm-managed         6d7h
asm-managed-rapid   6d7h
```
In der Ausgabe ist der Wert in der Spalte NAME das Überarbeitungslabel der den verfügbaren Release-Version für die Cloud Service Mesh-Version.
Clusterintern
Bei Steuerungsebenen im Cluster werden der istiod-Dienst und das Deployment in der Regel haben ein Überarbeitungslabel ähnlich wie istio.io/rev=, wobei identifiziert die Cloud Service Mesh-Version. Die Überarbeitung wird Teil des istiod-Dienstnamens, z. B. istiod-.istio-system.

Verwenden Sie den folgenden Befehl, um das Überarbeitungslabel in istiod für die clusterinterne Steuerungsebene zu finden:
```
kubectl get deploy -n istio-system -l app=istiod \
  -o=jsonpath='{.items[*].metadata.labels.istio\.io\/rev}''{"\n"}'
```
Aktivieren Sie den Namespace für die Injection: Ersetzen Sie REVISION und durch den Wert für das Überarbeitungslabel.

Hinweis: Sie können istio.io/rev durch das Label istio-injection=enabled ersetzen, wenn das Standard-Tag konfiguriert ist. Prüfen Sie, ob das Standard-Tag vorhanden ist. Führen Sie dazu istioctl tag list mit dem istioctl von OUTPUT_DIR aus.
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```
Wenn Sie Cloud Service Mesh mit asmcli installiert haben, wechseln Sie in das Verzeichnis, das den Sie in --output_dir angegeben haben, dann cd in das Verzeichnis samples.

Wichtig: Um sicherzustellen, dass Sie sich im richtigen samples-Verzeichnis befinden, führen Sie den ls-Befehl 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.

Wenn Sie asmcli nicht zur Installation genutzt haben, kopieren Sie die Konfigurationsdateien für die Gateways aus dem Repository anthos-service-mesh.
Sie können die Beispiel-Gateway-Konfiguration im Verzeichnis samples/gateways/ unverändert bereitstellen oder nach Bedarf ändern.
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

Die Ausgabe sieht etwa so aus:

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-Selektoren

Sie wenden eine Gateway Konfiguration an die Proxys istio-ingressgateway und istio-egressgateway, für Ihr Mesh-Netzwerk den ein- und ausgehenden Traffic verwalten. Dabei können Sie festlegen, Traffic, in den Sie in das Mesh-Netzwerk eintreten oder es verlassen möchten. 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 obigen Bereitstellungen ist das Label istio=ingressgateway beispielsweise auf den 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 Siehe frontend.yaml in der Beispielanwendung Online Boutique an.

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 Version der Steuerungsebene ändern möchten, können Sie das Label istio.io/rev im Gateway-Deployment festlegen, einen rollierenden Neustart auslösen.

Verwaltete Steuerungsebene

Da Google die Upgrades der Steuerungsebene verwaltet, können Sie einfach das Gateway-Deployment neu starten und die neuen Pods automatisch mit der neuesten Konfiguration und Version eingeschleust werden.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Clusterinterne Steuerungsebene

So wenden Sie das gleiche Muster auf Ihre Gateways an, wenn Sie die clusterinterne Steuerung haben müssen Sie die vom Gateway verwendete Version der Steuerungsebene ändern. Legen Sie das Label istio.io/rev für das Gateway-Deployment fest, das einen rollierender Neustart. Die erforderlichen Schritte hängen davon ab, ob Sie die Versionslabel für Namespace und/oder den Gateway-Pod.

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

Wenn Sie die Einschleusung nur für den Gateway-Pod aktiviert haben, legen Sie den istio.io/rev fest. Label des Deployments auf den neuen Versionswert wie folgt: 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 Anthos 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

TLS-Mindestversion des Gateways konfigurieren

Ab Cloud Service Mesh-Version 1.14 ist die TLS-Standardversion für Gateway-Server ist 1.2. Sie können die TLS-Mindestversion mit dem minProtocolVersion. Weitere Informationen finden Sie unter ServerTLSSettings

Fehlerbehebung bei Gateways

Gateway-Image von `auto` konnte nicht aktualisiert werden

Wenn Sie ein Gateway bereitstellen oder aktualisieren, fügt Cloud Service Mesh auto als ein Platzhalter im Feld image. Nach dem Aufruf des mutierenden Webhooks Cloud Service Mesh ersetzt diesen Platzhalter automatisch durch den tatsächlichen Cloud Service Mesh-Proxy-Image. Wenn der Aufruf des mutierenden Webhooks fehlschlägt, wird der Fehler auto Platzhalter bleibt und der Container wird nicht gefunden. Das ist normalerweise verursacht durch ein falsches Namespace-Label. Achten Sie darauf, dass Sie die richtige Namespace und stellen das Gateway dann noch einmal bereit oder aktualisieren es.