Gateways installieren und upgraden

Anthos 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 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 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. Traffic-Aufteilung, Weiterleitungen und Wiederholungslogik sind durch Anwenden einer Gateway-Konfiguration auf die Gateway-Proxys möglich. Anstatt Traffic-Routing auf Anwendungsebene (L7) derselben API-Ressource hinzuzufügen, binden Sie einen virtuellen Dienst an das Gateway. 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 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

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-Injektion (automatische Injektion), um die Proxykonfiguration für die Gateways genau wie für 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.
• Gewährt Administratoren vollständige Kontrolle über die Gateway-Bereitstellung und vereinfacht auch 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

Um Nutzer mit vorhandenen Bereitstellungstools zu unterstützen, unterstützt Anthos Service Mesh die Bereitstellung eines Gateways auf dieselbe Weise wie Istio: IstioOperator, Helm und Kubernetes YAML. 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.

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 die automatische Injektion auf dem Gateway, indem Sie ein Überarbeitungslabel auf den Gateway-Namespace anwenden. Das Überarbeitungslabel wird vom Sidecar-Injektor-Webhook verwendet, um eingefügte Proxys mit einer bestimmten Überarbeitung der Steuerungsebene zu verknüpfen. Welches Überarbeitungslabel Sie verwenden, hängt davon ab, ob Sie die von Google verwaltete Steuerungsebene oder die clusterinterne Steuerungsebene bereitgestellt haben.

   Von Google verwaltet

   Für die von Google verwaltete Steuerungsebene entspricht das Überarbeitungslabel einem Release-Kanal:

   Überarbeitungslabel	Kanal
   istio.io/rev=asm-managed	Regulär
   istio.io/rev=asm-managed-rapid	Rapid
   istio.io/rev=asm-managed-stable	Stabile Version

   Der Gateway-Namespace kann sich auf demselben Release-Kanal wie Ihre Dienste oder auf einem anderen Release-Kanal befinden. Wir empfehlen, dass Sie in einem Cluster denselben Release-Kanal verwenden. So sehen Sie, welche Release-Version ein Namespace verwendet:

   kubectl get namespace NAMESPACE -L istio.io/rev
   

   Clusterintern

   Bei clusterinternen Steuerungsebenen haben der istiod-Service und das Deployment in der Regel ein Überarbeitungslabel ähnlich wie istio.io/rev=asm-1106-2, wobei asm-1106-2 die Anthos Service Mesh-Version identifiziert. Die Überarbeitung wird Teil des istiod-Dienstnamens, z. B. istiod-asm-1106-2.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"}'
   

3. Aktivieren Sie den Namespace für die Injection: Ersetzen Sie REVISION und durch den Wert für das Überarbeitungslabel.

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

   Sie können die Nachricht "istio-injection not found" in der Ausgabe ignorieren. Das bedeutet, dass der Namespace bisher nicht das Label istio-injection hatte, was bei Neuinstallationen von Anthos Service Mesh oder neuen Bereitstellungen zu erwarten wäre. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

4. Wenn Sie Anthos Service Mesh mit asmcli installiert haben, wechseln Sie in das Verzeichnis, das Sie in --output_dir angegeben haben, und wechseln Sie dann mit cd zum 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.

5. 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 gateways/istio-ingressgateway
   

   Ausgehender Traffic

   kubectl apply -n GATEWAY_NAMESPACE -f 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
   

   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

Wichtig: Ihre Gateway-Ressourcen sollten wie jede andere Kubernetes-Anwendung verwaltet werden. Die Beispiele im Repository anthos-service-mesh-packages dienen als Orientierungshilfe und als Kurzanleitung. Sie sollten diese gemäß Ihren Anforderungen anpassen.

Gateway-Selektoren

Sie wenden eine Gateway-Konfiguration auf die Proxys istio-ingressgateway und istio-egressgateway an, um eingehenden und ausgehenden Traffic für Ihr Mesh zu verwalten. Dadurch können Sie angeben, welcher Traffic in das Mesh ein- und ausgehen darf. 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 finden Sie in der Beispielanwendung "Online Boutique" unter frontend.yaml.

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.

Von Google verwaltete Steuerungsebene
Da Google die Upgrades der Steuerungsebene für die von Google 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
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 auf die Gateway-Bereitstellung fest, um einen rollierenden Neustart auszulösen.

1. Aktualisieren Sie das Überarbeitungslabel im Namespace oder im Gateway-Pod.
   • Wenn Sie den Namespace zur Injektion mit Labels versehen haben:
   • Setzen Sie das Label "istio.io/rev" im Namespace auf den neuen Überarbeitungswert.

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

ODER

• 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.
    • Kubernetes-YAML

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

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 einen anderen Load-Balancer vor Istio verwenden, 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