Gateways mit Istio APIs installieren und aktualisieren
Mit Cloud Service Mesh können Sie Gateways als Teil eines Ihr Service Mesh. Ein Gateway beschreibt einen Load-Balancer, der am Netzwerkrand ausgeführt wird und empfängt eingehende oder ausgehende HTTP/TCP-Verbindungen. Gateways sind werden hauptsächlich zur Verwaltung von eingehendem Traffic verwendet. Sie können aber auch Gateways so konfigurieren, dass andere Arten von Traffic verwalten.
Gateways für ausgehenden Traffic: Mit einem Gateway für ausgehenden Traffic können Sie einen dedizierten Exit-Knoten konfigurieren. für Traffic, der das Mesh-Netzwerk verlässt, sodass Sie einschränken können, 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 dedizierten Eingang konfigurieren um eingehende HTTP/TCP-Verbindungen zu empfangen.
East-West-Gateways: Ein Proxy für Ost-West damit Dienstarbeitslasten über Clustergrenzen hinweg kommunizieren können, ein multiprimäres Mesh-Netzwerk in verschiedenen Netzwerken. 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 mehr als innerhalb desselben Clusters. 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 oder eine Konfiguration geändert hat, aktualisieren Administratoren die Gateway-Pods, indem sie sie neu starten. Dieses macht den Betrieb eines Gateway-Deployments den Betrieb von Sidecar-Proxys für Ihre Dienste.
Beispielgateway 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 die Methode wählen, mit der Sie am besten vertraut sind.
empfehlen die Verwendung der YAML-Methode von Kubernetes, da diese einfacher
und Sie können Manifeste mit Hydration in der Versionsverwaltung speichern.
In den folgenden Schritten wird gezeigt, 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 Injection: Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.
Verwaltet (TD)
- 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-Injection-Label auf den Namespace anzuwenden:
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Wenn Sie bereits Nutzer mit der Managed Istiod-Steuerungsebene sind: Wir empfehlen die Standardeinschleusung, aber die überarbeitete Injektion ist unterstützt. Gehe dazu so vor:
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 Spalte
NAME
das Überarbeitungslabel, das der verfügbaren Release-Version für die Cloud Service Mesh-Version entspricht.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:
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"}'
Wenden Sie das Überarbeitungslabel auf den Namespace an. Im folgenden Befehl ist
REVISION_LABEL
der Wert des Überarbeitungslabelsistiod
, 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
anthos-service-mesh
-Repository.Wechseln Sie in das Verzeichnis
samples
. Um sicherzustellen, dass Sie sich im Verzeichnis ist, führen Sie den Befehlls
aus, um den Verzeichnisinhalt Bestätigen Sie dann, dass eingateways
-Verzeichnis vorhanden ist (auf das Sie im nächsten Schritt) und einonline-boutique
-Verzeichnis enthält.Gateway für eingehenden oder ausgehenden Traffic bereitstellen Diese befinden sich in der
samples/gateways/
unverändert lassen oder bei 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
Ü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
Sie können Gateway-Ressourcen wie jede andere Kubernetes-Anwendung verwalten. Die Beispiele in
Das anthos-service-mesh-packages
-Repository dient als Orientierungshilfe
Kurzanleitung. Passen Sie sie an Ihre Bedürfnisse an.
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 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 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
TLS-Mindestversion des Gateways konfigurieren
Für Cloud Service Mesh ist die TLS-Standardversion für Gatewayserver 1.2.
Sie können die TLS-Mindestversion über das Feld minProtocolVersion
konfigurieren.
Weitere Informationen finden Sie unter
ServerTLSSettings
Nicht unterstützte Funktionen
Wenn du TRAFFIC_DIRECTOR
hast
Implementierung der Steuerungsebene dann
Die folgenden Felder oder Werte in Gateway werden 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 mutierenden Webhooks fehlschlägt, wird der Fehler auto
Platzhalter bleibt und der Container wurde 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.