Sie lesen die Dokumentation für Anthos Service Mesh 1.10. Lesen Sie die aktuelle Dokumentation oder wählen Sie eine andere verfügbare Version aus:

Sidecar-Proxys einfügen

Anthos Service Mesh verwendet Sidecar-Proxys, um die Sicherheit, Zuverlässigkeit und Beobachtbarkeit von Netzwerken 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. Dadurch werden die Features von Anthos Service Mesh bereitgestellt, ohne dass Ihre Produktionsanwendungen neu gestaltet werden müssen, um an einem Service Mesh teilzunehmen.

Die automatische Sidecar-Proxy-Einfügung (automatische Einfügung) tritt auf, wenn Anthos Service Mesh ein Namespace-Label erkennt, das Sie für den Pod der Arbeitslast konfigurieren. Der Proxy fängt den gesamten eingehenden und ausgehenden Traffic an die Arbeitslasten ab und kommuniziert mit Anthos Service Mesh.

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 Injektion zu aktivieren, fügen Sie Ihrem Namespace ein Überarbeitungslabel hinzu. 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.

So aktivieren Sie die automatische Einfügung:

Clusterintern

  1. 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-1104-14-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1104-14,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-1104-14-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1104-14,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-1104-14.

  2. 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 Anthos Service Mesh oder neuen Bereitstellungen zu erwarten wäre. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl das istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

  3. Starten Sie die betroffenen Pods neu. Führen Sie dazu die Schritte im nächsten Abschnitt aus.

Verwaltetes Dienst-Mesh

  1. Wenden Sie das folgende Überarbeitungslabel auf Ihre Namespaces an und entfernen Sie das Label istio-injection (falls vorhanden). Ersetzen Sie im folgenden Befehl NAMESPACE durch den Namen des Namespace, in dem Sie die automatische Injektion aktivieren möchten:

    kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=asm-managed-rapid --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 das istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

  2. Starten Sie die betroffenen Pods neu. Führen Sie dazu die Schritte im nächsten Abschnitt aus.

  3. 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.

  1. 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
  2. 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

Mehr zu folgenden Themen: