Gateways mit Istio APIs installieren und aktualisieren

Hinweis: Dieser Leitfaden unterstützt nur Cloud Service Mesh mit Istio APIs. Google Cloud APIs nicht unterstützt. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht

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 Edge ausgeführt wird. und empfängt eingehende oder ausgehende HTTP/TCP-Verbindungen. Gateways werden hauptsächlich zum Verwalten des eingehenden Traffics verwendet. Sie können jedoch auch Gateways konfigurieren, um andere Arten von Traffic zu verwalten.

• Gateways für ausgehenden Traffic: Mit einem Gateway für ausgehenden Traffic können Sie einen dedizierten Exit-Knoten konfigurieren. für Traffic aus dem Mesh-Netzwerk. So können Sie einschränken, welche Dienste auf externe Netzwerke zugreifen oder die sichere Steuerung des ausgehenden Traffics zu ermöglichen, Sicherheit Ihres Mesh-Netzwerks.

• Ingress-Gateways: Mit einem Ingress-Gateway können Sie einen speziellen Eingangsknoten für den Empfang eingehender HTTP/TCP-Verbindungen konfigurieren.

• East-West-Gateways: Ein Proxy für East-West-Traffic, damit Dienstarbeitslasten über Clustergrenzen hinweg in einem Multi-Primary-Mesh 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.

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

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

1. Aktivieren Sie die verwaltete Datenebene.
2. Fügen Sie einem Namespace ein verwaltetes Überarbeitungslabel hinzu.
3. Steuerungsebene und Gateways separat bereitstellen und verwalten.
4. Als Best Practice für die Sicherheit empfehlen wir, dass Sie Gateways in einem anderen Namespace über die Steuerungsebene bereitstellen.
5. 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

1. Steuerungsebene und Gateways separat bereitstellen und verwalten.
2. Als Best Practice für die Sicherheit empfehlen wir, dass Sie Gateways in einem anderen Namespace über die Steuerungsebene bereitstellen.
3. 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. Dieses macht den Betrieb eines Gateway-Deployments den Betrieb von Sidecar-Proxys für Ihre Dienste.

Beispiel-Gateway 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.

Die folgenden Schritte zeigen, wie Sie ein Beispielgateway bereitstellen.

1. 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
   

2. Aktivieren Sie den Namespace für die Injection: Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.

   Verwaltet (TD)

   1. Wenden Sie das Standard-Injection-Label auf den Namespace an:

   kubectl label namespace GATEWAY_NAMESPACE \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Verwaltet (Istiod)

   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
   

   Bereits bestehende Nutzer der verwalteten Istio-Steuerungsebene: Wir empfehlen die Standard-Injection, aber auch die revisionsbasierte Injection wird unterstützt. Gehen Sie dazu so vor:

   1. Führen Sie den folgenden Befehl aus, um die verfügbaren Release-Versionen zu finden:

      kubectl -n istio-system get controlplanerevision
      

      Die Ausgabe sieht in etwa so aus:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      HINWEIS: Wenn in der Liste oben zwei Versionen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Kanäle der Steuerungsebene im Cluster werden nicht unterstützt.

      In der Ausgabe ist der Wert in der NAME-Spalte das Überarbeitungslabel, das dem verfügbaren Release-Kanal für die Cloud Service Mesh-Version entspricht.

   2. Wenden Sie das Überarbeitungslabel auf den Namespace an.

      kubectl label namespace GATEWAY_NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

   Clusterintern

   Empfohlen:Führen Sie den folgenden Befehl aus, um das Standard-Injection-Label auf den Namespace anzuwenden:

     kubectl label namespace GATEWAY_NAMESPACE \
         istio.io/rev- istio-injection=enabled --overwrite
   

   Wir empfehlen die Standardeinschleusung, aber die versionsbasierte Einschleusung wird unterstützt: Gehe dazu so vor:

   1. Verwenden Sie den folgenden Befehl, um das Überarbeitungslabel 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 Überarbeitungslabel auf den Namespace an. Im folgenden Befehl ist REVISION_LABEL der Wert des Überarbeitungslabels istiod, den Sie im vorherigen Schritt notiert haben.

      kubectl label namespace GATEWAY_NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

3. Kopieren Sie die Konfigurationsdateien für die Beispiel-Gateways aus dem anthos-service-mesh-Repository.

4. Wechseln Sie in das Verzeichnis samples. Um sicherzustellen, dass Sie sich im Verzeichnis ist, führen Sie den Befehl ls aus, um den Verzeichnisinhalt Bestätigen Sie dann, dass ein gateways-Verzeichnis vorhanden ist (auf das Sie im nächsten Schritt) und ein online-boutique-Verzeichnis enthält.

5. Stellen Sie ein Ingress- oder Egress-Gateway bereit. 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
   

6. 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 in Das anthos-service-mesh-packages-Repository dient als Orientierungshilfe Kurzanleitung. Sie können sie nach Bedarf anpassen.

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 vorherigen Bereitstellungen wird beispielsweise das Label istio=ingressgateway festgelegt auf den Gateway-Pods. 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 für das Gateway-Deployment festlegen, einen rollierenden Neustart auslösen.

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

Wenn Sie dasselbe Muster auf Ihre Gateways anwenden möchten, wenn die Steuerungsebene clusterintern ist, müssen Sie die vom Gateway verwendete Überarbeitung der Steuerungsebene ändern. Legen Sie das Label istio.io/rev auf die Gateway-Bereitstellung fest, um einen rollierenden Neustart auszulösen. 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 um:

    kubectl label namespace GATEWAY_NAMESPACE \
      istio-injection- istio.io/rev=REVISION \
      --overwrite
  

• Wenn Sie die Injection nur für den Gateway-Pod aktiviert haben, legen Sie das Label istio.io/rev in der Bereitstellung auf den neuen Überarbeitungswert 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
  

  Hinweis: Wenn image nicht automatisch mit dem tatsächlichen Cloud Service Mesh-Proxy-Image: Der Container wird nicht gefunden und es wird ein Fehler angezeigt. erfolgt. Weitere Informationen finden Sie unter Fehlerbehebung bei Gateways.

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

Hinweis: Wenn image nicht automatisch mit dem tatsächlichen Cloud Service Mesh-Proxy-Image aktualisiert wird, wird der Container nicht gefunden und es tritt ein Fehler auf. Weitere Informationen finden Sie unter Weitere Informationen finden Sie unter Fehlerbehebung bei Gateways.

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

Hinweis: Im Gegensatz zu Anwendungsdiensten, die innerhalb des Mesh-Netzwerks bereitgestellt werden, können Sie die Trafficverteilung auf Istio nicht zur Verteilung des Traffics zwischen den Gateway-Versionen verwenden, da der Traffic direkt von externen Clients stammt, die von Istio nicht gesteuert werden. Stattdessen können Sie die Verteilung des Traffics durch die Anzahl der Replikate jedes Deployments steuern. Wenn Sie ein anderes Lastenausgleichsmodul Istio können Sie damit auch die Trafficverteilung steuern.

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 für das Gateway konfigurieren

Für Cloud Service Mesh ist die TLS-Standardversion für Gatewayserver 1.2. Sie können die TLS-Mindestversion mit dem Feld minProtocolVersion konfigurieren. Weitere Informationen finden Sie unter ServerTLSSettings

Nicht unterstützte Funktionen

Wenn Sie eine TRAFFIC_DIRECTOR-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

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 Webhooks zum Ändern 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 die richtige Namespace und stellen das Gateway dann noch einmal bereit oder aktualisieren es.