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 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
.
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
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.
- Verlagerung der Verwaltung und Wartung von Gatewayinstanzen auf von Anthos 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, 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
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.
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 davon ab, ob Sie verwaltetes Anthos Service Mesh oder die clusterinterne Steuerungsebene installiert haben. Das Überarbeitungslabel wird vom Sidecar-Injektor-Webhook verwendet, um eingefügte Sidecars mit einer bestimmten Überarbeitung der Steuerungsebene zu verknüpfen.
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
NAME
-Spalte das Überarbeitungslabel, das dem verfügbaren Release-Kanal für die Anthos Service Mesh-Version entspricht.Clusterintern
Bei clusterinternen Steuerungsebenen haben der
istiod
-Service und das Deployment in der Regel ein Überarbeitungslabel ähnlich wieistio.io/rev=asm-1157-23
, wobeiasm-1157-23
die Anthos Service Mesh-Version identifiziert. Die Überarbeitung wird Teil desistiod
-Dienstnamens, z. B.istiod-asm-1157-23.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.kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
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 mitcd
zum Verzeichnissamples
.Wenn Sie
asmcli
nicht zur Installation genutzt haben, kopieren Sie die Konfigurationsdateien für die Gateways aus dem Repositoryanthos-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 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
für das Gateway-Deployment 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 das Gateway-Deployment einfach neu starten. Die neuen Pods werden dann automatisch mit der neuesten Konfiguration und Version eingefügt.
kubectl rollout restart deployment istio-ingressgateway \
-n GATEWAY_NAMESPACE
Clusterinterne Steuerungsebene
Wenn Sie mit der clusterinternen Steuerungsebene das gleiche Muster auf Ihre Gateways anwenden möchten, müssen Sie die vom Gateway verwendete Überarbeitung der Steuerungsebene ändern.
Legen Sie das Label istio.io/rev
für das Gateway-Deployment fest, das einen rollierenden Neustart auslöst. Die erforderlichen Schritte hängen davon ab, ob Sie das Überarbeitungslabel für den Namespace und/oder den Gateway-Pod aktualisieren müssen.
Wenn Sie den Namespace mit einem Label für die Injektion versehen 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 Injektion nur für den Gateway-Pod aktiviert haben, legen Sie das Label
istio.io/rev
für das Deployment wie in der folgenden Kubernetes-YAML-Datei auf den neuen Versionswert fest: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
Mindestversion von TLS für das Gateway konfigurieren
Ab Anthos Service Mesh Version 1.14 ist die standardmäßige Mindestversion für TLS für Gatewayserver 1.2. Sie können die Mindestversion für TLS im Feld minProtocolVersion
konfigurieren. Weitere Informationen finden Sie unter ServerTLSSettings.
Fehlerbehebung bei Gateways
Gateway-Image von auto
konnte nicht aktualisiert werden
Wenn Sie ein Gateway bereitstellen oder upgraden, fügt Anthos Service Mesh auto
als Platzhalter im Feld image
ein. Nach dem Aufruf zum mutierenden Webhook ersetzt Anthos Service Mesh diesen Platzhalter automatisch durch das tatsächliche Anthos Service Mesh-Proxy-Image. Wenn der Aufruf zum Ändern des 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. Prüfen Sie, ob Sie den richtigen Namespace konfiguriert haben, und stellen Sie das Gateway dann noch einmal bereit oder führen Sie ein Upgrade durch.