Sidecar-Proxys mit Cloud Service Mesh einfügen

In diesem Dokument 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 (Sidecar) implementiert. Dieser wird als separater Container im selben Pod bereitgestellt. So erhalten Sie die Funktionen von Cloud Service Mesh nutzen, ohne Ihr an einem Service Mesh beteiligt zu sein.

Die automatische Sidecar-Proxy-Einschleusung (automatische Einschleusung) 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 dem Cloud Service Mesh.

Für diese Aufgaben erforderliche Berechtigungen

Zum Ausführen der Aufgaben auf dieser Seite benötigen Sie die Rolle roles/container.clusterAdmin oder eine höhere Rolle. Weitere Informationen zu den in dieser Rolle enthaltenen Berechtigungen finden Sie unter Google Kubernetes Engine-Rollen.

Automatische Sidecar-Einfügung aktivieren

Die empfohlene Methode zum Einfügen der Sidecar-Proxys ist die Verwendung des Webhook-basierten automatischen Sidecar-Injektors. Sie können die Kubernetes-Konfiguration Ihrer Pods aber auch manuell aktualisieren.

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 auch davon ab, ob Sie verwalteten Cloud Service Mesh (mit dem Flotten-API oder mit asmcli) oder die clusterinterne Steuerungsebene installiert. Das Label wird vom Sidecar verwendet Injektor-Webhook, um injizierte Sidecars mit einer bestimmten Steuerungsebene zu verknüpfen Überarbeitung.

So aktivieren Sie die automatische Einfügung:

Clusterintern

Verwenden Sie den folgenden Befehl, um das Überarbeitungslabel für istiod zu finden:

kubectl -n istio-system get pods -l app=istiod --show-labels

Die Ausgabe sieht dann ungefähr so aus:

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1233-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1233-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1233-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1233-2,istio=istiod,pod-template-hash=5788d57586

Notieren Sie sich den Wert des Überarbeitungslabels istiod aus der Ausgabe in der Spalte LABELS, das auf das Präfix istio.io/rev= folgt. In diesem Beispiel ist der Wert asm-1233-2.

Hinweis: Sie können istio.io/rev durch das Label istio-injection=enabled ersetzen, wenn das Standard-Tag konfiguriert ist. Prüfen Sie, ob das Standard-Tag vorhanden ist. Führen Sie dazu istioctl tag list mit dem istioctl von OUTPUT_DIR aus.

Wenden Sie das Überarbeitungslabel auf Namespaces an und entfernen Sie das Label zur Istio-Einfügung (falls vorhanden). Im folgenden Befehl ist NAMESPACE der Name des Namespace, in dem Sie die automatische Einfügung aktivieren möchten. REVISION ist das Überarbeitungslabel, das Sie im vorherigen Schritt notiert haben.
```
kubectl label namespace 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 Cloud Service Mesh oder neuen Bereitstellungen zu erwarten wäre. Da das Verhalten der automatischen Injektion nicht definiert ist, wenn ein Namespace sowohl istio-injection als auch das Überarbeitungslabel enthält, wird bei allen kubectl label-Befehlen in der Cloud Service Mesh-Dokumentation ausdrücklich darauf geachtet, dass nur eines davon festgelegt ist.
Starten Sie die betroffenen Pods neu. Führen Sie dazu die Schritte im nächsten Abschnitt aus.

Verwaltetes Dienst-Mesh

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
```
In der Ausgabe ist der Wert in der NAME-Spalte das REVISION-Label, das dem verfügbaren Release-Kanal für die Cloud Service Mesh-Version entspricht. Wenden Sie dieses Label auf Ihre Namespaces an und entfernen Sie das Label istio-injection, sofern vorhanden. Ersetzen Sie im folgenden Befehl REVISION durch das oben notierte Überarbeitungslabel und ersetzen Sie NAMESPACE durch den Namen des Namespace, in dem Sie die automatische Einfügung aktivieren möchten:
```
kubectl label namespace 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 Cloud Service Mesh oder neuen Bereitstellungen zu erwarten wäre. Da die automatische Injektion Verhalten ist nicht definiert, wenn ein Namespace sowohl den istio-injection-Wert und das Versionslabel, alle kubectl label-Befehle im In der Cloud Service Mesh-Dokumentation wird explizit dafür gesorgt, dass nur ein Wert festgelegt ist.
Starten Sie die betroffenen Pods neu. Führen Sie dazu die Schritte im nächsten Abschnitt aus.
Wenn Sie auch die optionale von Google verwaltete Datenebene bereitgestellt haben, annotieren Sie den Namespace demo so:
```
kubectl annotate --overwrite namespace YOUR_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 eines Deployments 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 YOUR_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 YOUR_NAMESPACE --all
```
Prüfen Sie, ob alle Pods im Namespace Sidecar-Dateien eingefügt haben:
```
kubectl get pod -n YOUR_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
YOUR_WORKLOAD           2/2     Running   0          20s
...
```

Weitere Informationen

Weitere Informationen zu folgenden Themen: