Version 1.11

Virtuelle Compute Engine-Maschinen zu Anthos Service Mesh hinzufügen

Auf dieser Seite wird beschrieben, wie Sie virtuelle Compute Engine-VMs zu Anthos Service Mesh in Google Kubernetes Engine (GKE) hinzufügen. Auf dieser Seite wird gezeigt, wie Sie Anthos Service Mesh 1.11.2 mit der Option installieren, die den Cluster zum Hinzufügen einer VM vorbereitet.

  • Wenn Anthos Service Mesh 1.9 or a 1.10 patch release bereits installiert ist, erfahren Sie auf dieser Seite, wie Sie ein Upgrade auf Anthos Service Mesh 1.11.2 mit der erforderlichen Option zum Hinzufügen einer VM ausführen.

  • Wenn Sie Anthos Service Mesh 1.9 verwenden und kein Upgrade ausführen möchten, lesen Sie im Leitfaden zu Anthos Service Mesh 1.9 die Anleitungen zum Hinzufügen von VMs zu Anthos Service Mesh 1.9.

  • Wenn Sie eine ältere Version von Anthos Service Mesh haben, müssen Sie zuerst Anthos Service Mesh auf Version 1.9 oder höher aktualisieren.

Diese Seite enthält die Befehlszeile zum Installieren der clusterinternen Steuerungsebene oder der von Google verwalteten Steuerungsebene.

Einführung

Mit Anthos Service Mesh können Sie Dienste, die in verwalteten Instanzgruppen (Managed Instance Groups, MIGs) ausgeführt werden, zusammen mit Diensten ausführen, die in GKE-Clustern (Google Kubernetes Engine) im Mesh-Netzwerk ausgeführt werden. Dadurch können Sie mit den Compute Engine-Instanzen in Ihrem Mesh-Netzwerk Folgendes tun:

  • Traffic verwalten.
  • mTLS erzwingen.
  • Zugriffssteuerung auf Diensttraffic anwenden.
  • Sicher auf Google Cloud-Dienste zugreifen.
  • Messwerte erfassen sowie Logging und Tracing von Daten.
  • Dienste mit der Google Cloud Console überwachen.

Dadurch können Legacy-Anwendungen für die Nutzung von Anthos Service Mesh-Funktionen aktiviert werden, die sich nicht für die Containerisierung eignen. Außerdem ist die Einbindung dieser Arbeitslasten in die übrigen Dienste möglich.

So gehts:

Anthos Service Mesh bietet zwei verwandte benutzerdefinierte Ressourcendefinitionen (Custom Resource Definitions, CRDs) zur Darstellung von Arbeitslasten virtueller Maschinen:

  • WorkloadGroup steht für eine logische Gruppe von VM-Arbeitslasten mit gemeinsamen Attributen. Dies ähnelt einem Deployment in Kubernetes.
  • WorkloadEntry steht für eine einzelne Instanz einer VM-Arbeitslast. Dies ist mit einem Pod in Kubernetes vergleichbar.
  • Ein Service kann dann den WorkloadGroup wählen und Anthos Service Mesh Traffic an die VM-Instanz weiterleiten lassen, ähnlich wie bei einem Pod. Auf diese Weise kann die VM wie jede andere Arbeitslast im Mesh-Netzwerk ausgeführt werden.

Sie erstellen eine Compute Engine-Instanzvorlage für jede Compute Engine-Instanzgruppe, die einen Dienstproxy-Agent für jede Compute Engine-Instanz in dieser Gruppe angibt. Während der Installation bootet der Agent den Dienstproxy, richtet das Abfangen von Traffic ein und überwacht den Status des Dienstproxys während der Lebensdauer der Compute Engine-Instanz. Der Proxy stellt eine Verbindung zur Anthos Service Mesh-Steuerungsebene her und registriert dann automatisch jede Compute Engine-Instanz als WorkloadEntry für die entsprechende WorkloadGroup.. So kann Anthos Service Mesh jede Instanz als Dienstendpunkt behandeln, wie die Kubernetes-Pods im Cluster. Sie können Kubernetes-Dienste auch für VM-Arbeitslasten erstellen, wie dies bei Kubernetes-Pods der Fall ist.

Informationen zum horizontalen Skalieren der Anzahl von Arbeitslasten in Compute Engine-Instanzen, beginnend mit einer MIG-Mindestgröße von null, finden Sie unter Autoscaling von Instanzgruppen.

Der Dienst-Proxy-Agent stützt sich auf VM-Manager, um dafür zu sorgen, dass der Agent auf jeder VM in der MIG installiert wird. Weitere Informationen zu Instanzgruppen und zur VM-Verwaltung finden Sie unter Verwaltete Instanzgruppe (Managed Instance Group, MIG) und VM Manager.

Unterstützte Linux-Distributionen

Betriebssystemversion Unterstützt
Debian 10
Debian 9
CentOS 8
CentOS 7

Weitere Informationen zu Betriebssystem-Distributionen finden Sie unter Debian-Unterstützung oder CentOS-Unterstützung.

Beschränkungen

  • Die Steuerungsebene des Mesh-Netzwerks muss Anthos Service Mesh 1.9 oder höher sein.
  • Es werden nur von Compute Engine verwaltete Instanzgruppen unterstützt, die anhand einer Compute Engine-Instanzvorlage erstellt wurden.
  • Der Cluster und die VMs müssen sich im selben Netzwerk und im selben Projekt befinden und eine einzelne Netzwerkschnittstelle verwenden.
  • Sie können dieses Feature ohne Anthos-Abo nutzen. Bestimmte UI-Elemente und Features in der Google Cloud Console sind jedoch nur für Anthos-Abonnenten verfügbar. Informationen dazu, welche Features Abonnenten und Nicht-Abonnenten zur Verfügung stehen, finden Sie unter Unterschiede zwischen Anthos und Anthos Service Mesh in der Benutzeroberfläche.
  • Obwohl Sie sowohl die von Google verwaltete Steuerungsebene als auch die von Google verwaltete Datenebene in Ihrem Cluster bereitstellen können, verwaltet die von Google verwaltete Datenebene nicht die Proxys auf den VMs.

Vorbereitung

Hinweise:

Prüfen Sie das Cloud-Projekt, die Anthos-Lizenzierung und die allgemeinen Anforderungen, die unter Voraussetzungen beschrieben werden.

Clusteranforderungen

Prüfen Sie vor dem Fortfahren, ob Ihr Cluster die GKE-Anforderungen erfüllt. Außerdem erfordert der Anthos Service Mesh-VM-Support Folgendes:

  • Sie geben Mesh CA als Zertifizierungsstelle (Certificate Authority) an, wenn Sie Anthos Service Mesh installieren.
  • Sie überschreiben Stackdriver nicht für Telemetrie. Stackdriver ist bei der Installation von Anthos Service Mesh standardmäßig konfiguriert.
  • Ihr Cluster ist bei einer Flotte registriert. Sollte der Cluster nicht registriert sein, wird er vom VM-Installationsprozess im von Ihnen angegebenen Projekt registriert.

Erste Schritte

Gehen Sie wie unter Jetzt starten beschrieben vor, um folgende Aufgaben auszuführen:

Wenn Anthos Service Mesh nicht installiert ist, fahren Sie mit dem nächsten Abschnitt fort. Wenn Sie bereits eine Anthos Service Mesh-Installation haben, folgen Sie den Schritten unter Vorhandene Installationen.

Neuinstallation

Richten Sie den Anthos Service Mesh-Cluster für VMs ein, indem Sie die Anthos Service Mesh 1.11-Steuerungsebene vorbereiten. Der auszuführende Befehl hängt vom Typ der Anthos Service Mesh-Steuerungsebene ab, die Sie in Ihrem Cluster installieren möchten.

Clusterintern

Mit dem folgenden Befehl wird gezeigt, wie Sie die clusterinterne Steuerungsebene von Anthos Service Mesh mit der --option vm installieren, die die Steuerungsebene zum Hinzufügen von VMs vorbereitet.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm
  • --project_id, --cluster_name und --cluster_location geben die Projekt-ID des Clusters, den Clusternamen und die Clusterzone oder -region an.
  • --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und die Installationsdatei extrahiert, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
  • --enable_all Ermöglicht dem Skript Folgendes:
    • Erforderliche IAM-Berechtigungen gewähren.
    • Erforderliche Google APIs aktivieren.
    • Im Cluster ein Label zur Angabe des Mesh-Netzwerks festlegen.
    • Den Cluster bei der Flotte registrieren, falls noch nicht geschehen.

  • --ca mesh_ca Mesh CA als Zertifizierungsstelle verwenden. asmcli konfiguriert Mesh CA für die Verwendung der Workload Identity der Flotte.
  • --option vm Bereitet den Cluster für die Aufnahme einer VM in das Service Mesh vor.

Wenn in Ihrem Cluster bereits Arbeitslasten ausgeführt werden, stellen Sie die Arbeitslasten noch einmal bereit und kehren Sie dann zu dieser Seite zurück, um Ihre VMs hinzuzufügen.

Verwaltetes Dienst-Mesh

Mit dem folgenden Befehl wird gezeigt, wie Sie die von Google verwaltete Anthos Service Mesh-Steuerungsebene mit --option vm bereitstellen, die die Steuerungsebene für das Hinzufügen von VMs vorbereitet. Weitere Informationen zu anderen verfügbaren Optionen finden Sie unter Von Google verwaltete Steuerungsebene anwenden. Obwohl die verwaltete Anthos Service Mesh-Dokumentation das Skript install_asm anstelle von asmcli install verwendet, geben Sie die Optionen bei beiden Installationsskripts auf die gleiche Weise an.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm \
  --managed
  • --project_id, --cluster_name und --cluster_location geben die Projekt-ID des Clusters, den Clusternamen und die Clusterzone oder -region an.
  • --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und die Installationsdatei extrahiert, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
  • --enable_all Ermöglicht dem Skript Folgendes:
    • Erforderliche IAM-Berechtigungen gewähren.
    • Erforderliche Google APIs aktivieren.
    • Im Cluster ein Label zur Angabe des Mesh-Netzwerks festlegen.
    • Den Cluster bei der Flotte registrieren, falls noch nicht geschehen.

  • --ca mesh_ca Mesh CA als Zertifizierungsstelle verwenden. asmcli konfiguriert Mesh CA für die Verwendung der Workload Identity der Flotte.
  • --option vm Bereitet den Cluster für die Aufnahme einer VM in das Service Mesh vor.
  • --managed Von Google verwaltete Steuerungsebene bereitstellen.

Vorhandene Installationen

Wenn Anthos Service Mesh bereits auf Ihrem Cluster installiert wurde, gehen Sie so vor:

  1. Registrieren Sie den Cluster bei der Flotte, falls noch nicht geschehen.

  2. Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Anthos Service Mesh-Installation für VM-Arbeitslasten bereit ist. Sie führen denselben Befehl für die von Cluster verwalteten und die von Google verwalteten Steuerungsebenen aus.

    ./asmcli experimental vm prepare-cluster \
        --project_id PROJECT_ID \
        --cluster_name CLUSTER_NAME \
        --cluster_location CLUSTER_LOCATION
    

    Bei Erfolg gibt der Befehl Folgendes aus:

    The cluster is ready for adding VM workloads.
    Please follow the Anthos Service Mesh for Compute Engine VM user guide to add
    Compute Engine VMs to your mesh.
    

Der Befehl führt folgende Schritte durch:

Clusterintern

  1. Aktivieren Sie die automatische VM-Registrierung: Setzen Sie dazu die Variablen PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION und PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY auf „true”. Wenn diese Option aktiviert ist, werden neue VM-Instanzen bei der WorkloadGroup registriert und neue WorkloadEntry-CRs werden erstellt, um Traffic an die VMs weiterzuleiten. Für alle mit asmcli installierten Anthos Service Mesh-Steuerungsebenen ab Version 1.9 ist die automatische VM-Registrierung standardmäßig aktiviert.

  2. Installieren Sie ein Erweiterungsgateway: Dieses Gateway heißt eastwest-Gateway und ist im Anthos Service Mesh-Konfigurationspaket definiert. Dadurch wird auch die Steuerungsebene für die VMs verfügbar gemacht.

  3. Installieren Sie die CRD IdentityProvider und registrieren Sie die Google-CR IdentityProvider, um VMs zur Authentifizierung bei der Anthos Service Mesh-Steuerungsebene zu aktivieren und mit dem Rest des Service Mesh sicher zu kommunizieren.

  4. Registrieren Sie den Cluster bei einer Flotte und aktivieren Sie die Workload Identity, wenn Sie --enable_all oder --enable_registration im Skript asmcli verwenden.

  5. Aktivieren Sie das Feature Service Mesh in der Flotte. Dieses Feature verwaltet die erforderlichen Richtlinien, damit VMs sicher mit dem Mesh-Netzwerk kommunizieren können.

Verwaltetes Dienst-Mesh

  1. Automatische Registrierung von VMs aktivieren: Bei allen von Google verwalteten Anthos Service Mesh-Steuerungsebenen ist die automatische VM-Registrierung standardmäßig aktiviert.

  2. Installieren Sie die CRD IdentityProvider und registrieren Sie die Google-CR IdentityProvider, um VMs zur Authentifizierung bei der von Google verwalteten Anthos Service Mesh-Steuerungsebene zu aktivieren und mit dem Rest des Service Mesh sicher zu kommunizieren.

  3. Registrieren Sie den Cluster bei einer Flotte und aktivieren Sie die Workload Identity, wenn Sie --enable_all oder --enable_registration im Skript asmcli verwenden.

  4. Aktivieren Sie das Feature Service Mesh in der Flotte. Dieses Feature verwaltet die erforderlichen Richtlinien, damit VMs sicher mit dem Mesh-Netzwerk kommunizieren können.

Ingress-Gateways installieren

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

  1. Erstellen Sie einen Namespace für das Ingress-Gateway, falls Sie noch keinen haben. Gateways sind Nutzerarbeitslasten und sollten als Best Practice nicht im Namespace der Steuerungsebene bereitgestellt werden. Ersetzen Sie GATEWAY_NAMESPACE durch den Namen Ihres Namespace.

    kubectl create namespace GATEWAY_NAMESPACE
    
  2. Aktivieren Sie die automatische Injektion auf dem Gateway, indem Sie ein Überarbeitungslabel auf den Gateway-Namespace anwenden. Das Überarbeitungslabel wird vom Sidecar-Injektor-Webhook verwendet, um eingefügte Proxys mit einer bestimmten Überarbeitung der Steuerungsebene zu verknüpfen. Welches Überarbeitungslabel Sie verwenden, hängt davon ab, ob Sie das verwaltete Anthos Service Mesh oder die clusterinterne Steuerungsebene bereitgestellt haben.

    Clusterintern

    1. 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"}'
      
    2. Wenden Sie das Überarbeitungslabel auf den Namespace an. Im folgenden Befehl ist REVISION der Wert des Überarbeitungslabels istiod, den Sie im vorherigen Schritt notiert haben.

      kubectl label namespace GATEWAY_NAMESPACE \
        istio-injection- istio.io/rev=REVISION --overwrite
      

    Verwaltetes Dienst-Mesh

    Wenden Sie das Überarbeitungslabel asm-managed-rapid auf den Namespace an:

    kubectl label namespace GATEWAY_NAMESPACE \
      istio-injection- istio.io/rev=asm-managed-rapid --overwrite
    

    Dieses Label entspricht der aktuellen Release-Version des verwalteten Anthos Service Mesh für die Anthos Service Mesh-Version.

    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 istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

  3. Sie können die Beispielkonfiguration für das Ingress-Gateway im Verzeichnis samples/gateways/istio-ingressgateway/ unverändert bereitstellen oder nach Bedarf ändern.

    kubectl apply -n GATEWAY_NAMESPACE \
      -f DIR_PATH/samples/gateways/istio-ingressgateway
    

Best Practices für Gateways

VMs hinzufügen

In diesem Abschnitt fügen Sie Ihrem Mesh-Netzwerk Compute Engine-Instanzen basierend auf der Instanzvorlage hinzu, die Sie mit gcloud erstellt haben. gcloud generiert nur die erforderliche Konfiguration für den Dienst-Proxy-Agent. Weitere Informationen zum Hinzufügen weiterer Konfigurationen in Ihrer Instanzvorlage finden Sie in der Referenz zu gcloud.

Führen Sie die folgenden Schritte aus, um Ihrem Mesh VMs hinzuzufügen:

  1. Legen Sie die folgenden Umgebungsvariablen für die Verwendung in späteren Schritten fest. Legen Sie diese Variablen für jede VM-Arbeitslast fest:

    • WORKLOAD_NAME ist der Name der Arbeitslast, zu der die VM gehört. Dabei muss es sich um eine DNS-1123-konforme Subdomain handeln, die aus alphanumerischen Zeichen in Kleinbuchstaben besteht.
    • WORKLOAD_VERSION ist die Version der Arbeitslast, zu der die VM gehört. Optional.
    • WORKLOAD_SERVICE_ACCOUNT ist das GCP-Dienstkonto, als das die VM ausgeführt wird.
    • WORKLOAD_NAMESPACE ist der Namespace für die Arbeitslast.
    • ASM_INSTANCE_TEMPLATE ist der Name der Instanzvorlage, die erstellt werden soll. Der Name der Compute Engine-Instanzvorlage lässt keine Unterstriche zu.
  2. Erstellen Sie den Namespace für die VM-Arbeitslasten, falls noch nicht vorhanden:

    kubectl create ns WORKLOAD_NAMESPACE
    
  3. Versehen Sie den Namespace mit dem Label der Überarbeitung der Steuerungsebene.

    Clusterintern

    Ein Beispiel dafür, wie Sie die Überarbeitung der Steuerungsebene im folgenden Beispiel als REVISION ermitteln, finden Sie unter Arbeitslasten bereitstellen und wieder bereitstellen.

    kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
    

    Verwaltetes Dienst-Mesh

    Ein Beispiel für das Festlegen der Überarbeitung REVISION im folgenden Beispiel finden Sie unter Anwendungen bereitstellen.

    kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
    
  4. Erstellen Sie die WorkloadGroup für die zu registrierenden VMs:

    kubectl apply -f - << EOF
    apiVersion: networking.istio.io/v1alpha3
    kind: WorkloadGroup
    metadata:
      name: WORKLOAD_NAME
      namespace: WORKLOAD_NAMESPACE
    spec:
      metadata:
        labels:
          app.kubernetes.io/name: WORKLOAD_NAME
          app.kubernetes.io/version: WORKLOAD_VERSION
        annotations:
          security.cloud.google.com/IdentityProvider: google
      template:
        serviceAccount: WORKLOAD_SERVICE_ACCOUNT
    EOF
    
    Feld Beschreibung
    name Der Name der Arbeitslast, zu der die VM gehört.
    namespace Der Namespace, zu dem die Arbeitslast gehört.
    app.kubernetes.io/name Die empfohlenen Labels für Kubernetes-Anwendungen. Sie können für Ihre VM-Arbeitslasten eigene Labels verwenden.
    app.kubernetes.io/version Die empfohlenen Labels für Kubernetes-Anwendungen. Sie können für Ihre VM-Arbeitslasten eigene Labels verwenden.
    serviceAccount Die von der VM und dem Projekt verwendete Dienstkontoidentität, die als Teil der Identität der Arbeitslast im SPIFFE-Format verwendet wird. Weitere Informationen finden Sie unter Dienstkonten.
    security.cloud.google.com/IdentityProvider Der Identitätsanbieter, der von der VM verwendet wird und bereits in Ihrem Cluster registriert sein sollte. Für Compute Engine-VMs sollte google festgelegt sein. Der IdentityProvider teilt der Steuerungsebene mit, wie die Anmeldedaten der VM authentifiziert werden und wohin das Dienstkonto der VM extrahiert werden soll.
  5. Verwenden Sie den Befehl gcloud beta compute instance-templates create mit dem Flag --mesh, um eine Instanzvorlage für Ihre Anthos Service Mesh Compute Engine-Instanzen zu erstellen.

    gcloud prüft die Voraussetzungen für Cluster, fügt VM-Labels für Anthos Service Mesh hinzu, generiert die benutzerdefinierte Metadatenkonfiguration für den Dienst-Proxy-Agent und erstellt eine neue Instanzvorlage.

    Wenn die vorhandene Instanzvorlage ein Startskript enthält, das eine Netzwerkverbindung erfordert, sollte das Skript auch bei vorübergehenden Netzwerkverbindungsproblemen stabil sein. In der Demoanwendung finden Sie ein Beispiel dafür, wie Sie Ausfallsicherheit bei temporären Netzwerkunterbrechungen hinzufügen.

    Weitere Informationen zum Erstellen von Instanzvorlagen finden Sie unter Instanzvorlagen erstellen.

    gcloud beta compute instance-templates create \
    ASM_INSTANCE_TEMPLATE \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
    --project PROJECT_ID
    
  6. Legen Sie für jede von Ihnen erstellte MIG die folgenden Umgebungsvariablen fest:

    • INSTANCE_GROUP_NAME ist der Name der zu erstellenden Compute Engine-Instanzgruppe.
    • ASM_INSTANCE_TEMPLATE ist der Name der Instanzvorlage, die erstellt werden soll. Der Name der Compute Engine-Instanzvorlage lässt keine Unterstriche zu.
    • INSTANCE_GROUP_ZONE ist die Zone der zu erstellenden Compute Engine-Instanzgruppe.
    • PROJECT_ID ist die Projekt-ID des Projekts, in dem der Cluster erstellt wurde.
    • SIZE ist die Größe der Instanzgruppe, die erstellt werden soll. Nachdem die Instanzgruppe erstellt wurde, kann sie geändert werden.
    • WORKLOAD_NAME ist der Name der Arbeitslast, zu der die VM gehört.
    • WORKLOAD_NAMESPACE ist der Namespace für die Arbeitslast.
  7. Erstellen Sie mit den in den vorherigen Schritten erstellten Variablen eine verwaltete Instanzgruppe für die VM-Arbeitslasten:

    gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
    --template ASM_INSTANCE_TEMPLATE \
    --zone=INSTANCE_GROUP_ZONE \
    --project=PROJECT_ID \
    --size=SIZE
    

    Informationen zum horizontalen Skalieren der Anzahl von Arbeitslasten in Compute Engine-Instanzen, beginnend mit einer zonalen oder regionalen MIG-Größe von null, finden Sie unter Autoscaling von Instanzgruppen. Weitere Informationen zum Erstellen von Gruppen finden Sie unter gcloud compute instance-groups managed create.

    Beim Starten der Instanz wird sie automatisch mit der Anthos Service Mesh-Steuerungsebene im Cluster authentifiziert. Die Steuerungsebene registriert dann jede VM als WorkloadEntry.

  8. Wenn die VM-Instanz in der MIG den Startvorgang abgeschlossen hat, können Sie die registrierten VMs mit dem folgenden Befehl im Namespace der Arbeitslast anzeigen lassen:

    kubectl get workloadentry -n WORKLOAD_NAMESPACE
    
  9. Fügen Sie einen Kubernetes-Dienst hinzu, um die oben hinzugefügten VM-Arbeitslasten verfügbar zu machen. Achten Sie darauf, dass der Dienst das entsprechende Label auf der VM WorkloadGroup auswählt, die oben registriert ist, um das richtige Trafficrouting zu konfigurieren.

    Im folgenden Beispiel wird ein Kubernetes-Dienst mit dem Namen WORKLOAD_NAME im Namespace WORKLOAD_NAMESPACE erstellt, der VM-Arbeitslasten mit dem Label app.kubernetes.io/name: WORKLOAD_NAME unter HTTP-Port 80 verfügbar macht.

    kubectl apply -f - << EOF
    apiVersion: v1
    kind: Service
    metadata:
      name: WORKLOAD_NAME
      namespace: WORKLOAD_NAMESPACE
      labels:
        asm_resource_type: VM
    spec:
      ports:
      - port: 80
        name: http
      selector:
        app.kubernetes.io/name: WORKLOAD_NAME
    EOF
    

    Weitere Informationen zum Erstellen eines Kubernetes-Dienstes finden Sie unter https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service.

  10. Informationen dazu, wie Sie eine Beispielanwendung auf Ihrer VM verwenden, finden Sie unter Beispielanwendung bereitstellen.

Arbeitslasten nach einem Upgrade der clusterinternen Steuerungsebene neu bereitstellen

Wenn Sie im vorherigen Abschnitt ein Upgrade von Anthos Service Mesh durchgeführt haben und auf Ihrem Cluster Arbeitslasten ausgeführt werden, wechseln Sie zur neuen Steuerungsebene.

Erstellen Sie für VM-Arbeitslasten eine neue Instanzvorlage und führen Sie ein Rolling Update für die VMs in Ihrer MIG durch:

  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 des Befehls sieht in etwa so aus: Beachten Sie, dass sich die Ausgabe für Migrationen geringfügig von der Ausgabe für Upgrades unterscheidet. Die folgende Beispielausgabe stammt von einer Migration.

    NAME                                         READY   STATUS    RESTARTS   AGE   LABELS
    istiod-7744bc8dd7-qhlss                      1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
    istiod-asm-1112-17-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1112-17,istio=istiod,pod-template-hash=85d86774f7
    istiod-asm-1112-17-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1112-17,istio=istiod,pod-template-hash=85d86774f7
    1. Notieren Sie sich aus der Ausgabe in der Spalte LABELS den Wert des istiod-Überarbeitungslabels für die neue Version, der auf das Präfix istio.io/rev= folgt. In diesem Beispiel lautet der Wert asm-1112-17.

    2. Notieren Sie sich außerdem den Wert im Überarbeitungslabel der alten istiod-Version. Diesen Wert benötigen Sie, um die alte Version von istiod zu löschen, wenn Sie die Arbeitslasten in die neue Version verschoben haben. In der Beispielausgabe lautet der Wert im Überarbeitungslabel für die alte istiod-Version default.

  2. Fügen Sie das Überarbeitungslabel einem Namespace hinzu und entfernen Sie das istio-injection-Label (falls vorhanden). Geben Sie im folgenden Befehl für REVISION den Wert an, der der neuen Überarbeitung von istiod entspricht.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

    Wenn in der Ausgabe "istio-injection not found" angezeigt wird, können Sie dies ignorieren. Das bedeutet, dass der Namespace bisher nicht das Label istio-injection hatte. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

  3. Erstellen Sie mit gcloud eine neue Instanzvorlage. Achten Sie darauf, dieselbe Konfiguration anzugeben, wenn Sie eine Instanzvorlage für dieselbe Arbeitslast haben.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
    --project PROJECT_ID
    
  4. Führen Sie ein Rolling Update für die vorhandene MIG für die Arbeitslast durch.

    Weitere Informationen finden Sie unter Grundlegendes Rolling Update starten.

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_ASM_INSTANCE_TEMPLATE \
    --zone=INSTANCE_GROUP_ZONE
    
  5. Testen Sie die VM-Arbeitslast, um zu prüfen, ob sie wie erwartet funktioniert.

Upgrade für VM-Anwendungen ausführen

Wenn Aktualisierungen an der Anwendung vorgenommen wurden, einschließlich Änderungen an der WorkloadGroup und/oder Änderungen an der Konfiguration der Instanzvorlage, ist eine neue Instanzvorlage erforderlich, um die MIG Ihrer VM-Arbeitslasten zu aktualisieren.

Wenn die Änderung WorkloadGroup angewendet und/oder die neue Quellinstanzvorlage erstellt wurde, erstellen Sie eine neue Instanzvorlage für Anthos Service Mesh und führen Sie ein Rolling Update für die VMs in Ihrer MIG aus.

  1. Erstellen Sie mit gcloud eine neue Instanzvorlage.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
    --project PROJECT_ID
    
  2. Führen Sie ein Rolling Update für die vorhandene MIG für die Arbeitslast durch. Weitere Informationen zur Verwendung des MIG-Rolling Update finden Sie unter Einfaches Rolling Update starten.

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_ASM_INSTANCE_TEMPLATE \
    --zone=INSTANCE_GROUP_ZONE
    
  3. Testen Sie die VM-Arbeitslast, um zu prüfen, ob sie wie erwartet funktioniert.

Beispielanwendung bereitstellen

Installieren Sie die Beispielanwendung für BookInfo, um zu zeigen, dass Ihre neue Mesh-Konfiguration ordnungsgemäß funktioniert. In diesem Beispiel wird eine MySQL-Datenbank auf der VM ausgeführt und der Bewertungsdienst liest die Bewertungswerte aus der Datenbank.

BookInfo auf dem Cluster installieren

Führen Sie die folgenden Schritte aus, um die Dienste der BookInfo-Anwendung mit den in jedem Dienst eingefügten Sidecar-Proxys bereitzustellen. Die BookInfo-Anwendung wird im Namespace default bereitgestellt.

  1. Wechseln Sie in der Befehlszeile des Computers, auf dem Sie Anthos Service Mesh installiert haben, zum Stammverzeichnis des Anthos Service Mesh-Installationsverzeichnisses, das Sie im Schritt Skript herunterladen erstellt haben.

  2. Wählen Sie die folgende Anleitung basierend auf dem Typ der Anthos Service Mesh-Steuerungsebene aus, um die automatische Sidecar-Injektion zu aktivieren.

    Clusterintern

    Verwenden Sie den folgenden Befehl, um in istiod nach dem Label zu suchen. Dort ist der Wert des Überarbeitungslabels enthalten, der in den späteren Schritten verwendet wird.

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

    Verwaltetes Dienst-Mesh

    Verwenden Sie die Überarbeitung asm-managed-rapid, um VMs hinzuzufügen.

  3. Wenden Sie das Überarbeitungslabel auf den Namespace default an.

    Clusterintern

    Im folgenden Befehl ist REVISION der Wert des Überarbeitungslabels istiod, den Sie im vorherigen Schritt notiert haben.

    kubectl label namespace default 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 istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

    Verwaltetes Dienst-Mesh

    kubectl label namespace default istio-injection- istio.io/rev=asm-managed-rapid --overwrite
    
  4. Stellen Sie die Anwendung mit kubectl im Standard-Namespace bereit:

    kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
    
  5. Führen Sie die folgenden Befehle aus, um zu bestätigen, dass die Anwendung fehlerfrei bereitgestellt wurde:

    kubectl get services
    

    Erwartete Ausgabe:

    NAME                       CLUSTER-IP   EXTERNAL-IP         PORT(S)              AGE
    details                    10.0.0.31    <none>        9080/TCP             6m
    kubernetes                 10.0.0.1     <none>        443/TCP              7d
    productpage                10.0.0.120   <none>        9080/TCP             6m
    ratings                    10.0.0.15    <none>        9080/TCP             6m
    reviews                    10.0.0.170   <none>        9080/TCP             6m

    und

    kubectl get pod
    

    Erwartete Ausgabe:

    NAME                                        READY     STATUS    RESTARTS   AGE
    details-v1-1520924117-48z17                 2/2       Running   0          6m
    productpage-v1-560495357-jk1lz              2/2       Running   0          6m
    ratings-v1-734492171-rnr5l                  2/2       Running   0          6m
    reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
    reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
    reviews-v3-1813607990-8ch52                 2/2       Running   0          6m
  6. Definieren Sie abschließend das Ingress-Gateway-Routing für die Anwendung:

    kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
    

    Erwartete Ausgabe:

    gateway.networking.istio.io/bookinfo-gateway created
    virtualservice.networking.istio.io/bookinfo created
  7. Prüfen Sie, ob die Produktseite zugänglich ist. Im folgenden Befehl ist GATEWAY_NAMESPACE der Namespace Ihres Istio-Gateways.

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    export INGRESS_PORT=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
    export GATEWAY_URL="${INGRESS_HOST}:${INGRESS_PORT}"
    curl -s "http://${GATEWAY_URL}/productpage" | grep -o "<title>.*</title>"
    

    Erwartete Ausgabe:

    <title>Simple Bookstore App</title>
    

Compute Engine-Instanzen erstellen und MySQL installieren

In diesem Schritt erstellen Sie eine Compute Engine-Instanzvorlage für die auf der VM ausgeführte MySQL-Instanz. Weitere Informationen finden Sie unter Bookinfo mit einer virtuellen Maschine.

  1. Erstellen Sie ein Startskript, mit dem MySQL installiert und beim Start eine Bewertungsdatenbank hinzugefügt wird. Beachten Sie, dass es bei Verwendung von CentOS bis zu 10 Minuten dauern kann, bis der Mariadb-Server bereit ist.

    Debian

    cat << "EOF" > init-mysql
    #!/bin/bash
    
    # Wait until Envoy is ready before installing mysql
    while true; do
      rt=$(curl -s 127.0.0.1:15000/ready)
      if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
        echo "envoy is ready"
        break
      fi
      sleep 1
    done
    
    # Wait until DNS is ready before installing mysql
    while true; do
      curl -I productpage.default.svc:9080
      if [[ $? -eq 0 ]]; then
        echo "dns is ready"
        break
      fi
      sleep 1
    done
    
    sudo apt-get update && sudo apt-get install -y mariadb-server
    
    sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/mysql/mariadb.conf.d/50-server.cnf
    
    cat <<EOD | sudo mysql
    # Grant access to root
    GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
    
    # Grant root access to other IPs
    CREATE USER 'root'@'%' IDENTIFIED BY 'password';
    GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
    FLUSH PRIVILEGES;
    quit;
    EOD
    
    sudo systemctl restart mysql
    
    curl -LO https://raw.githubusercontent.com/istio/istio/release-1.11/samples/bookinfo/src/mysql/mysqldb-init.sql
    
    mysql -u root -ppassword < mysqldb-init.sql
    EOF
    

    CentOS

    cat << "EOF" > init-mysql
    #!/bin/bash
    
    # Wait until Envoy is ready before installing mysql
    while true; do
      rt=$(curl -s 127.0.0.1:15000/ready)
      if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
        echo "envoy is ready"
        break
      fi
      sleep 1
    done
    
    # Wait until DNS is ready before installing mysql
    while true; do
      curl -I productpage.default.svc:9080
      if [[ $? -eq 0 ]]; then
        echo "dns is ready"
        break
      fi
      sleep 1
    done
    
    sudo yum update -y && sudo yum install -y mariadb-server
    
    # Wait until mysql is ready
    while true; do
      rt=$(which mysql)
      if [[ ! -z "${rt}" ]]; then
        echo "mysql is ready"
        break
      fi
      sleep 1
    done
    
    sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/my.cnf.d/mariadb-server.cnf
    
    sudo systemctl restart mariadb
    
    cat > grantaccess.sql << EOD
    
    GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
    
    CREATE USER 'root'@'%' IDENTIFIED BY 'password';
    GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
    FLUSH PRIVILEGES;
    EOD
    
    until sudo mysql < grantaccess.sql; do
       sleep 1
    done
    
    sudo systemctl restart mariadb
    
    curl -LO https://raw.githubusercontent.com/istio/istio/release-1.11/samples/bookinfo/src/mysql/mysqldb-init.sql
    
    mysql -u root -ppassword < mysqldb-init.sql
    EOF
    
  2. Erstellen Sie eine WorkloadGroup für die MySQL-Arbeitslast

    kubectl apply -f - << EOF
    apiVersion: networking.istio.io/v1alpha3
    kind: WorkloadGroup
    metadata:
      name: mysql
      namespace: default
    spec:
      metadata:
        labels:
          app.kubernetes.io/name: mysql
        annotations:
          security.cloud.google.com/IdentityProvider: google
      template:
        serviceAccount: WORKLOAD_SERVICE_ACCOUNT
    EOF
    
  3. Verwenden Sie gcloud zum Erstellen einer neuen Instanzvorlage, um die Instanzen für Ihr Mesh vorzubereiten und das oben erstellte Startskript aufzunehmen.

    Debian

    gcloud beta compute instance-templates create asm-mysql-instance-template \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
    --project PROJECT_ID \
    --metadata-from-file=startup-script=init-mysql \
    --image-project=debian-cloud --image-family=debian-10 --boot-disk-size=10GB
    

    CentOS

    gcloud beta compute instance-templates create asm-mysql-instance-template \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
    --project PROJECT_ID \
    --metadata-from-file=startup-script=init-mysql \
    --image-project=centos-cloud --image-family=centos-8 --boot-disk-size=20GB
    
  4. Erstellen Sie eine Compute Engine-MIG mit der neu erstellten Instanzvorlage.

    gcloud compute instance-groups managed create mysql-instance \
    --template asm-mysql-instance-template \
    --zone=us-central1-c \
    --project=PROJECT_ID \
    --size=1
    

Dienste erstellen

Erstellen Sie mit dem folgenden Befehl einen Kubernetes-Dienst für den MySQL-Dienst:

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: default
  labels:
    asm_resource_type: VM
spec:
  ports:
  - name: mysql
    port: 3306
    protocol: TCP
    targetPort: 3306
  selector:
    app.kubernetes.io/name: mysql
EOF

Verwenden Sie Anthos-UI-Dashboard

Klicken Sie in der Navigationsleiste links oben auf Anthos > Service Mesh, um den neu erstellten VM-basierten Dienst aufzurufen. Es wird eine Tabelle der Dienste angezeigt, die in Ihrem Mesh ausgeführt werden. Der hinzugefügte Dienst sollte in der Tabelle mit einem Type-Wert von VM und einigen allgemeinen Messwerten angezeigt werden. Klicken Sie auf den Dienstnamen, um die Telemetrie Ihres VM-basierten Dienstes aufzurufen. Daraufhin wird das Dashboard auf Dienstebene angezeigt.

Weitere Informationen zur Verwendung des Dashboards der Anthos-UI finden Sie unter Anthos Service Mesh in der Cloud Console kennenlernen.

Traffic zu den VM-Arbeitslasten verwalten

Sie können die Netzwerkregeln ändern, um den ein- und ausgehenden Traffic der VM(s) zu steuern.

Traffic zu einem neuen Bewertungsdienst steuern (Pod zu VM)

Erstellen Sie einen weiteren Bewertungsdienst in BookInfo, der die oben erstellte MySQL-Instanz als Datenquelle verwendet, und geben Sie eine Routingregel an, die den Rezensionsdienst zur Verwendung des neuen Bewertungsdienstes zwingt.

  1. Erstellen Sie einen neuen Bewertungsdienst für die MySQL-Instanz.

    kubectl apply -f - << EOF
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ratings-v2-mysql-vm
      labels:
        app: ratings
        version: v2-mysql-vm
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: ratings
          version: v2-mysql-vm
      template:
        metadata:
          labels:
            app: ratings
            version: v2-mysql-vm
        spec:
          serviceAccountName: bookinfo-ratings
          containers:
          - name: ratings
            image: docker.io/istio/examples-bookinfo-ratings-v2:1.16.2
            imagePullPolicy: IfNotPresent
            env:
              - name: DB_TYPE
                value: "mysql"
              - name: MYSQL_DB_HOST
                value: mysql.default.svc.cluster.local
              - name: MYSQL_DB_PORT
                value: "3306"
              - name: MYSQL_DB_USER
                value: root
              - name: MYSQL_DB_PASSWORD
                value: password
            ports:
            - containerPort: 9080
    EOF
    
  2. Erstellen Sie eine Routingregel.

    kubectl apply -f - << EOF
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: reviews
    spec:
      hosts:
      - reviews
      http:
      - route:
        - destination:
            host: reviews
            subset: v3
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: ratings
    spec:
      hosts:
      - ratings
      http:
      - route:
        - destination:
            host: ratings
            subset: v2-mysql-vm
    EOF
    
  3. Wenden Sie die Zielregeln für die erstellten Dienste an.

    kubectl apply -f - << EOF
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: reviews
    spec:
      host: reviews
      subsets:
      - name: v1
        labels:
          version: v1
      - name: v2
        labels:
          version: v2
      - name: v3
        labels:
          version: v3
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: ratings
    spec:
      host: ratings
      subsets:
      - name: v1
        labels:
          version: v1
      - name: v2
        labels:
          version: v2
      - name: v2-mysql
        labels:
          version: v2-mysql
      - name: v2-mysql-vm
        labels:
          version: v2-mysql-vm
    EOF
    

Anwendungsbereitstellung validieren

Zum Prüfen, ob die BookInfo-Anwendung funktioniert, müssen Sie Traffic an das Ingress-Gateway senden.

  • Wenn Sie Anthos Service Mesh in GKE installiert haben, rufen Sie die externe IP-Adresse des Ingress-Gateways ab, die Sie in den vorherigen Schritten erstellt haben:

    kubectl get svc istio-ingressgateway -n GATEWAY_NAMESPACE
    

    Ausgabe:

    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
    istio-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

    In diesem Beispiel lautet die IP-Adresse des Ingress-Dienstes 35.239.7.64.

Anwendung testen

  1. Prüfen Sie, ob die BookInfo-Anwendung mit curl ausgeführt wird:

    curl -I http://EXTERNAL_IP/productpage
    

    Wenn in der Antwort 200 angezeigt wird, bedeutet dies, dass die Anwendung fehlerfrei mit Anthos Service Mesh funktioniert.

  2. Geben Sie die folgende Adresse in Ihren Browser ein, um die BookInfo-Webseite aufzurufen:

    http://EXTERNAL_IP/productpage
    
  3. Prüfen Sie auf der Startseite der BookInfo-Anwendung, dass fünf Sterne von Reviewer1 und vier Sternen von Reviewer2 angezeigt werden.

Sicherheit auf VM-Arbeitslasten erzwingen

Das Erzwingen der Sicherheit auf den VM-Arbeitslasten ist das gleiche, wie das Erzwingen der Sicherheit auf den Kubernetes-Arbeitslasten. Weitere Informationen finden Sie unter Istio-Sicherheit.

Nachdem Sie die vorherigen Schritte abgeschlossen haben, verfügt Ihre Compute Engine-VM über ein von Google ausgestelltes Arbeitslastzertifikat. Der Wert SubjectAlternativeName im Zertifikat zeigt die Anthos Workload Identity der VM im Format spiffe://<workload_identity_pool>/ns/WORKLOAD_NAMESPACE/sa/WORKLOAD_SERVICE_ACCOUNT an.

Weitere Informationen finden Sie unter Workload Identity-Pool.

Strikten mTLS-Modus für das Mesh-Netzwerk aktivieren

Wenden Sie die folgende YAML-Datei an, um im gesamten Mesh-Netzwerk den strikten mTLS-Modus zu erzwingen.

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
EOF

Autorisierung für Dienst-zu-Dienst-Traffic

Verwenden Sie AuthorizationPolicy, um den Zugriff zwischen den Anwendungen auf Ihrer Compute Engine-VM und anderen Mesh-Arbeitslasten (z. B. im GKE-Cluster) zu steuern.

Beispiel: Kubernetes-Arbeitslasten den Zugriff auf Compute Engine-VMs verweigern

Mit der folgenden Autorisierungsrichtlinie wird einer Kubernetes-Arbeitslast ratings verweigert, um auf Compute Engine-VM-Arbeitslasten zuzugreifen, die den MySQL-Server ratings verarbeiten.

  kubectl apply -f - << EOF
  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    name: mysql-deny
    namespace: default
  spec:
    selector:
      matchLabels:
        app.kubernetes.io/name: mysql
    action: DENY
    rules:
    - from:
      - source:
          principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
  EOF

Nachdem Sie das Beispiel AuthorizationPolicy angewendet haben, sollte auf der Produktseite im Bereich "Buchrezensionen" die Fehlermeldung Ratings service is currently unavailable angezeigt werden.

Cloud Monitoring-Agent installieren

Sie können den Cloud Monitoring-Agent installieren, um System- und Anwendungsmesswerte aus Ihren VM-Instanzen zu erfassen und zu überwachen. So können Sie wichtige Messwerte überwachen, z. B. die CPU- und Speicherauslastung des Agents.

Weitere Informationen finden Sie in der Dokumentation zum Cloud Monitoring-Agent.

Fehlerbehebung

Tipps zur Fehlerbehebung finden Sie unter Fehlerbehebung beim VM-Support.