Kubernetes-Arbeitslasten einrichten
Auf dieser Seite wird beschrieben, wie Sie Kubernetes-Arbeitslasten mit Cloud Service Mesh einrichten.
Kubernetes-Dienste bereitstellen
So stellen Sie Kubernetes-Dienste für Cluster mit Cloud Service Mesh bereit:
Erstellen Sie Kubernetes-Dienste für alle Container. Alle Deployments sollten mit einem Kubernetes-Dienst verknüpft sein.
Benennen Sie die Dienstports. Obwohl Sie in GKE unbenannte Dienstports definieren können, müssen Sie für Cloud Service Mesh einen Namen für einen Port angeben, der mit dem Protokoll des Ports übereinstimmt.
Versehen Sie Ihre Bereitstellungen mit Labels. Auf diese Weise können Sie Features zur Traffic-Verwaltung von Cloud Service Mesh verwenden und den Traffic zwischen Versionen desselben Dienstes aufteilen.
Das folgende Beispiel für eine Bereitstellung und einen Dienst veranschaulichen diese Anforderungen:
Nachdem Sie Ihre Dienste in einem Cluster mit Cloud Service Mesh bereitgestellt haben, müssen Sie Sidecar-Proxys einfügen.
Beispiel: Online Boutique-Beispiel bereitstellen
Die Beispielanwendung Online Boutique im Repository anthos-service-mesh-packages
wird im Vergleich zum ursprünglichen Satz von Manifesten im Repository microservices-demo
geändert. Gemäß Best Practices wird jeder Dienst in einem separaten Namespace mit einem eindeutigen Dienstkonto bereitgestellt.
Erstellen Sie die Namespaces für die Anwendung:
kubectl apply -f \ DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces
Erwartete Ausgabe:
namespace/ad created namespace/cart created namespace/checkout created namespace/currency created namespace/email created namespace/frontend created namespace/loadgenerator created namespace/payment created namespace/product-catalog created namespace/recommendation created namespace/shipping created
Aktivieren Sie die automatische Sidecar-Injektion (automatische Injektion). Dieser Befehl unterscheidet sich je nachdem, ob Sie das verwaltete Cloud Service Mesh oder das Cloud Service Mesh im Cluster verwenden. Wenn Sie verwaltetes Cloud Service Mesh verwenden, verwenden Sie Standard-Injection-Labels (z. B.
istio-injection=enabled
). Wenn Sie Cloud Service Mesh im Cluster nutzen, verwenden Sie dasselbe Überarbeitungslabel, mit dem Sie den Namespace des Ingress-Gateways annotiert haben. Vorhandene migrierte Kunden der verwalteten Steuerungsebene können zusätzlich zum Standardlabel für die Einschleusung auch ihre vorhandenen Überarbeitungslabels verwenden.Standard-Injektionslabels
Wenden Sie die Standard-Injektionslabels auf den Namespace an. Im folgenden Befehl ist GATEWAY_NAMESPACE der Wert, mit dem Sie den Namespace des Ingress-Gateways annotiert haben.
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns istio-injection=enabled istio.io/rev- done;
Erwartete Ausgabe:
namespace/ad labeled namespace/cart labeled namespace/checkout labeled namespace/currency labeled namespace/email labeled namespace/frontend labeled namespace/loadgenerator labeled namespace/payment labeled namespace/product-catalog labeled namespace/recommendation labeled namespace/shipping labeled
Überarbeitungslabel
Wenden Sie das Überarbeitungslabel auf die Anwendungs-Namespaces an. Im folgenden Befehl ist REVISION der Wert, mit dem Sie den Namespace des Ingress-Gateways annotiert haben.
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns istio.io/rev=REVISION --overwrite done;
Erwartete Ausgabe:
namespace/ad labeled namespace/cart labeled namespace/checkout labeled namespace/currency labeled namespace/email labeled namespace/frontend labeled namespace/loadgenerator labeled namespace/payment labeled namespace/product-catalog labeled namespace/recommendation labeled namespace/shipping labeled
Stellen Sie die Beispielanwendung im Cluster bereit:
Erstellen Sie die Dienstkonten und Deployments:
kubectl apply -f \ DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments
Erwartete Ausgabe:
serviceaccount/ad created deployment.apps/adservice created serviceaccount/cart created deployment.apps/cartservice created serviceaccount/checkout created deployment.apps/checkoutservice created serviceaccount/currency created deployment.apps/currencyservice created serviceaccount/email created deployment.apps/emailservice created serviceaccount/frontend created deployment.apps/frontend created serviceaccount/loadgenerator created deployment.apps/loadgenerator created serviceaccount/payment created deployment.apps/paymentservice created serviceaccount/product-catalog created deployment.apps/productcatalogservice created serviceaccount/recommendation created deployment.apps/recommendationservice created serviceaccount/shipping created deployment.apps/shippingservice created
Erstellen Sie die Dienste:
kubectl apply -f \ DIR_PATH/samples/online-boutique/kubernetes-manifests/services
Erwartete Ausgabe:
service/adservice created service/cartservice created service/checkoutservice created service/currencyservice created service/emailservice created service/frontend created service/frontend-external created service/paymentservice created service/productcatalogservice created service/recommendationservice created service/shippingservice created
Erstellen Sie die Diensteinträge:
kubectl apply -f \ DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml
Erwartete Ausgabe:
serviceentry.networking.istio.io/allow-egress-googleapis created serviceentry.networking.istio.io/allow-egress-google-metadata created
Dienstports benennen
Damit Dienstports in Cloud Service Mesh aufgenommen werden können, müssen sie benannt werden und der Name muss das Protokoll des Ports enthalten. Beispiel:
apiVersion: v1 kind: Service metadata: name: ratings labels: app: ratings service: ratings spec: ports: - port: 9080 name: http
Der Portname des Diensts kann ein Suffix in der Syntax name: protocol[-suffix]
enthalten, wobei mit den eckigen Klammern ein optionales Suffix angegeben wird, das mit einem Bindestrich beginnen muss. Beispiel:
kind: Service metadata: name: myservice spec: ports: - number: 3306 name: mysql - number: 80 name: http-web
Damit die Messwerte in der Google Cloud Console angezeigt werden, müssen die Dienstports mit einem der folgenden Protokolle benannt werden: http
, http2
oder grpc
.
Dienstports mit dem https
-Protokoll im Namen werden als tcp
behandelt. Für diese Dienste werden keine Messwerte angezeigt.
Sidecar-Proxys einfügen
In diesem Abschnitt wird beschrieben, wie Sie die Sidecar-Proxy-Injektion mit Cloud Service Mesh konfigurieren, um die Netzwerksicherheit, Zuverlässigkeit und Beobachtbarkeit zu verbessern. Diese Funktionen werden vom primären Container der Anwendung abstrahiert und in einem gemeinsamen Out-of-Process-Proxy (dem Sidecar) implementiert, der als separater Container im selben Pod bereitgestellt wird. Sie können die Features von Cloud Service Mesh nutzen, ohne Ihre Produktionsanwendungen für die Teilnahme an einem Service Mesh neu zu gestalten.
Die automatische Sidecar-Proxy-Injektion (automatische Einfügung) erfolgt, wenn Cloud Service Mesh ein Namespace-Label erkennt, das Sie für den Pod der Arbeitslast konfigurieren. Der Proxy fängt den gesamten ein- und ausgehenden Traffic an die Arbeitslasten ab und kommuniziert mit Cloud Service Mesh.
Automatische Sidecar-Einfügung aktivieren
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 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 NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Wenn Sie bereits Nutzer mit der Managed Istio-Steuerungsebene sind:Wir empfehlen die Verwendung der Standardeinschleusung. Die versionsbasierte Einschleusung wird jedoch 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 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 NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Wir empfehlen die Standardeinschleusung, aber die versionsbasierte Einschleusung wird unterstützt: Gehe 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 NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Starten Sie die betroffenen Pods neu. Führen Sie dazu die Schritte im nächsten Abschnitt aus.
Annotieren Sie den
demo
-Namespace so:kubectl annotate --overwrite namespace NAMESPACE \ mesh.cloud.google.com/proxy='{"managed":"true"}'
Pods neu starten, um Sidecar-Proxys zu aktualisieren
Mit der automatischen Sidecar-Einfügung können Sie die Sidecar-Proxys für vorhandene Pods mit einem Pod-Neustart aktualisieren.
Wie Sie Pods neu starten, hängt davon ab, ob sie als Teil einer Bereitstellung erstellt wurden.
Starten Sie die Bereitstellung neu, wenn Sie eine Bereitstellung verwendet haben. Dadurch werden alle Pods mit Sidecar-Dateien neu gestartet:
kubectl rollout restart deployment -n NAMESPACE
Wenn Sie keine Bereitstellung verwendet haben, löschen Sie die Pods, und sie werden automatisch mit Sidecar-Dateien neu erstellt:
kubectl delete pod -n NAMESPACE --all
Prüfen Sie, ob alle Pods im Namespace Sidecar-Dateien eingefügt haben:
kubectl get pod -n NAMESPACE
In der folgenden Beispielausgabe des vorherigen Befehls sehen Sie, dass die Spalte
READY
zwei Container für jede Ihrer Arbeitslasten enthält: den primären Container und den Container für den Sidecar-Proxy.NAME READY STATUS RESTARTS AGE WORKLOAD 2/2 Running 0 20s ...