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

Von Google verwaltete Steuerungsebene konfigurieren

Übersicht

Die von Google verwaltete Anthos Service Mesh-Steuerungsebene ist ein verwalteter Google Cloud-Dienst, den Sie nur konfigurieren müssen. Google sorgt für dessen Zuverlässigkeit, Upgrades, Skalierung und Sicherheit. In diesem Leitfaden wird erläutert, wie Anwendungen auf einer von Google verwalteten Steuerungsebene mit einem einzelnen oder mehreren Clustern eingerichtet oder dahin migriert werden.

Sie können eine einzelne von Google verwaltete Steuerungsebene für mehrere GKE-Cluster in einem einzelnen Google Cloud-Projekt verwenden.

Informationen zu den unterstützten Funktionen und Einschränkungen der verwalteten Anthos Service Mesh-Steuerungsebene finden Sie unter Von Google verwaltete Anthos Service Mesh-Steuerungsebene – Funktionen.

Vorbereitung

In diesem Leitfaden wird Folgendes vorausgesetzt:

Falls Workload Identity nicht aktiviert ist, können Sie es mit dem folgenden Befehl aktivieren:

gcloud container clusters update CLUSTER_NAME \
    --zone LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog

Installationsskript herunterladen

  1. Laden Sie die aktuellste Version des Skripts herunter, mit der Anthos Service Mesh 1.9.8 in das aktuelle Arbeitsverzeichnis installiert wird:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.9 > install_asm
    
  2. Laden Sie das SHA-256 der Datei in das aktuelle Arbeitsverzeichnis herunter:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.9.sha256 > install_asm.sha256
    
  3. Prüfen Sie den Download, wenn beide Dateien im selben Verzeichnis sind:

    sha256sum -c --ignore-missing install_asm.sha256
    

    Wenn die Prüfung erfolgreich ist, gibt der Befehl Folgendes aus: install_asm: OK

    Aus Kompatibilitätsgründen enthält die Datei install_asm.sha256 die Prüfsumme zweimal, damit jede Version des Skripts in install_asm umbenannt werden kann. Wenn Sie die Fehlermeldung erhalten, dass --ignore-missing nicht vorhanden ist, führen Sie den vorherigen Befehl ohne das Flag --ignore-missing noch einmal aus.

  4. Machen Sie das Skript ausführbar:

    chmod +x install_asm
    

Jeden Cluster konfigurieren

Führen Sie die folgenden Schritte aus, um die von Google verwaltete Steuerungsebene für jeden Cluster in Ihrem Mesh-Netzwerk zu konfigurieren.

Clusteranmeldedaten abrufen

Rufen Sie die entsprechenden Anmeldedaten ab. Mit dem folgenden Befehl wird auch der Kontext kubectl auf den Zielcluster verweisen.

gcloud container clusters get-credentials  CLUSTER_NAME \
    --zone LOCATION \
    --project PROJECT_ID

Von Google verwaltete Steuerungsebene anwenden

Führen Sie das Installationsskript für jeden Cluster aus, der die von Google verwaltete Steuerungsebene verwendet:

Wenn Sie das Container Network Interface (CNI) von Istio nicht benötigen, lassen Sie das Flag --option cni-managed im Befehl install_asm weg, wie im folgenden Beispiel gezeigt. CNI ist eine Option für die von Google verwaltete Steuerungsebene, bei der das Abfangen durch Istio und Netzwerke auf niedriger Ebene über die CNCF-CNI-Schnittstelle statt über init-Containern mit hoher Berechtigung konfiguriert werden können.

./install_asm --mode install --managed \
    -p PROJECT_ID \
    -l LOCATION \
    -n CLUSTER_NAME \
    --verbose \
    --output_dir CLUSTER_NAME \
    --enable-all \
    --option cni-managed

Das Skript lädt alle Dateien zur Konfiguration der verwalteten Steuerungsebene in das angegebene --output_dir herunter und installiert ein Istio-Gateway zusammen mit dem istioctl-Tool und Beispielanwendungen.

Istio-Gateways installieren (optional)

Optional können Sie ein oder mehrere Istio-Gateways in Ihrem Cluster installieren, um typischen eingehenden Traffic zu verarbeiten. Dazu verwenden Sie folgende Schritte:

  1. Wählen Sie eine dieser beiden Optionen aus, um den Namespace einzurichten, in dem Sie das Gateway in späteren Schritten bereitstellen.

    • Aktivieren Sie den Namespace für die Injection:
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed --overwrite
      

    OR

    • Aktivieren Sie die Injection nur für den Gateway-Pod, aber nicht für alle Pods im Namespace. Mit diesem Befehl werden alle Injection-Labels entfernt. Später aktivieren Sie dann die Injection für den Pod selbst:
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-
      
  2. Verwenden Sie das folgende kleine Beispiel, um eine Bereitstellung und einen Dienst für das Gateway zu erstellen:

    kubectl apply -f - << EOF
    apiVersion: v1
    kind: Service
    metadata:
      name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
    spec:
      type: LoadBalancer
      selector:
        istio: ingressgateway
      ports:
      - port: 80
        name: http
      - port: 443
        name: https
    ---
    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 Anthos Service Mesh to inject the gateway with the
            # required configuration.
            inject.istio.io/templates: gateway
          labels:
            istio: ingressgateway
            istio.io/rev: asm-managed # This is required only if the namespace is not labeled.
        spec:
          containers:
          - name: istio-proxy
            image: auto # The image will automatically update each time the pod starts.
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: istio-ingressgateway-sds
      namespace: GATEWAY_NAMESPACE
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: istio-ingressgateway-sds
      namespace: GATEWAY_NAMESPACE
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: istio-ingressgateway-sds
    subjects:
    - kind: ServiceAccount
      name: default
    EOF
    
  3. Prüfen Sie nach dem Erstellen der Bereitstellung, ob die neuen Dienste ordnungsgemäß funktionieren:

    kubectl get pod,service -n GATEWAY_NAMESPACE
    

    Die Ausgabe sollte in etwa so aussehen:

    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

Endpunkterkennung konfigurieren (nur für Installationen mit mehreren Clustern)

Die verwaltete Anthos Service Mesh-Steuerungsebene unterstützt eine multi-primäre Konfiguration mit einem einzelnen Projekt und Netzwerk, mit dem Unterschied, dass die Steuerungsebene nicht im Cluster installiert ist. Eine multi-primäre Konfiguration bedeutet, dass jeder Cluster mit Secrets für alle anderen Cluster konfiguriert ist, sodass jeder Cluster Endpunkte aus allen anderen Clustern erkennen kann.

Bevor Sie fortfahren, sollten Sie das Installationsskript, wie in den vorherigen Schritten beschrieben, bereits auf jedem Cluster ausgeführt haben. Sie müssen nicht angeben, dass ein Cluster ein primärer Cluster ist, dies ist das Standardverhalten.

Aktivieren Sie für jeden Cluster die Endpunkterkennung. Führen Sie dazu die folgenden Befehle für jeden anderen Cluster i=1..N im Mesh-Netzwerk aus:

  1. Sorgen Sie dafür, dass der kubectl-Konfigurationskontext für jeden Cluster auf den aktuellen Cluster verweist:

    export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
    
  2. Aktivieren Sie die Endpunkterkennung, indem Sie die folgenden Befehle einmal für jeden anderen Cluster i=1..N im Mesh-Netzwerk ausführen:

    export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i
    
    ./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
      kubectl apply -f - --context=${CTX}
    
  3. Prüfen Sie mit dem folgenden Befehl, ob das Secret erstellt wurde:

    kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system
    

    Prüfen Sie die erwartete Ausgabe:

    NAME                                   TYPE     DATA   AGE
    istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s
    
  4. Wenn der aktuelle Cluster zu einem vorhandenen Mesh-Netzwerk mit mehreren Clustern hinzugefügt wird, müssen alle anderen Cluster dessen Endpunkte erkennen. Erstellen Sie dazu ein Secret für den aktuellen Cluster in allen anderen Clustern:

    ./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
      kubectl apply -f - --context=${CTX_i}
    
  5. Darüber hinaus können Sie das Secret für den anderen Cluster überprüfen:

    kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}
    

    Prüfen Sie die erwartete Ausgabe:

    NAME                            TYPE     DATA   AGE
    istio-remote-secret-CLUSTER_NAME   Opaque   1      44s
    

Weitere Informationen und ein Beispiel mit zwei Clustern finden Sie unter Endpunkterkennung aktivieren.

Anwendungen bereitstellen

Entfernen Sie vor dem Bereitstellen von Anwendungen alle vorherigen istio-injection-Labels aus ihren Namespaces und legen Sie stattdessen das Label istio.io/rev:asm-managed fest:

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

Sie haben die verwaltete Anthos Service Mesh-Steuerungsebene konfiguriert. Jetzt können Sie die Anwendungen oder die Bookinfo-Beispielanwendung bereitstellen.

Wenn Sie eine Anwendung in einer Multi-Cluster-Konfiguration bereitstellen, replizieren Sie die Kubernetes- und Steuerungsebene auf allen Clustern, sofern Sie diese bestimmte Konfiguration nicht auf eine Teilmenge von Clustern beschränken. Die auf einen bestimmten Cluster angewendete Konfiguration ist die "Source of Truth" für diesen Cluster. Wenn der Cluster außerdem Anthos Service Mesh 1.7, 1.8 oder höher mit Mesh-CA in anderen Namespaces ausführt, prüfen Sie, ob die Anwendung mit den anderen, von der clusterinternen Steuerungsebene gesteuerten Anwendungen kommunizieren kann.

Messwerte der Steuerungsebene prüfen

So prüfen Sie, ob Ihre Konfiguration ordnungsgemäß funktioniert:

  1. Rufen Sie in der Cloud Console die Messwerte der Steuerungsebene auf:

    Zum Metrics Explorer

  2. Wählen Sie Ihren Arbeitsbereich aus und fügen Sie mit den folgenden Parametern eine benutzerdefinierte Abfrage hinzu:

    • Ressourcentyp: Kubernetes-Container
    • Messwert: Proxy-Clients
    • Filter: container_name="cr-asm-managed"
    • Gruppieren nach: Überarbeitungslabel und proxy_version-Label
    • Aggregator-Summe
    • Zeitraum: 1 Minute

    Wenn Sie Anthos Service Mesh sowohl mit einer von Google verwalteten als auch mit einer clusterinternen Steuerungsebene ausführen, können Sie die Messwerte anhand ihres Containernamens unterscheiden. Beispielsweise haben verwaltete Messwerte den Wert container_name="cr-asm-managed", während nicht verwatete Messwerte container_name="discovery" haben. Entfernen Sie den Filter für container_name="cr-asm-managed", um Messwerte aus beiden anzuzeigen.

  3. Prüfen Sie die Version der Steuerungsebene und die Proxyversion anhand der folgenden Felder in Metrics Explorer:

    • Das Feld Überarbeitung gibt die Version der Steuerungsebene an.
    • Das Feld proxy_version gibt die proxy_version an.
    • Das Feld Wert gibt die Anzahl der verbundenen Proxys an.

Anwendungen auf die von Google verwaltete Steuerungsebene migrieren

Die von Google verwaltete Anthos Service Mesh-Steuerungsebene unterstützt nur die Migration von Anthos Service Mesh 1.9 mit Mesh-CA.

Führen Sie die folgenden Schritte aus, um zur von Google verwalteten Steuerungsebene zu migrieren:

  1. Führen Sie das Skript aus, wie im Abschnitt Steuerungsebene installieren beschrieben.

  2. Ersetzen Sie das aktuelle Namespace-Label durch das Label istio.io/rev:asm-managed:

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed \
        --overwrite
    
  3. So führen Sie ein Rolling Upgrade von Bereitstellungen im Namespace durch:

    kubectl rollout restart deployment -n NAMESPACE
    
  4. Testen Sie Ihre Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.

  5. Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die vorherigen Schritte für jeden Namespace.

  6. Wenn Sie die Anwendung in einer Multi-Cluster-Einrichtung bereitgestellt haben, replizieren Sie die Kubernetes- und Istio-Konfiguration in allen Clustern, es sei denn, Sie möchten die Konfiguration auf eine Teilmenge von Clustern beschränken. Die auf einen bestimmten Cluster angewendete Konfiguration ist die "Source of Truth" für diesen Cluster.

  7. Prüfen Sie, ob die Messwerte wie erwartet angezeigt werden. Führen Sie dazu die Schritte unter Messwerte der Steuerungsebene prüfen aus.

Ein Cluster kann verschiedene Überarbeitungen haben, z. B. Anthos Service Mesh 1.7 und 1.8 und eine clusterinterne Steuerungsebene. Sie können Namespaces mit verschiedenen Überarbeitungen der Anthos Service Mesh-Steuerungsebene auf unbestimmte Zeit kombinieren.

Wenn Sie mit der Anwendung zufrieden sind, können Sie den clusterinternen istiod entfernen, nachdem Sie alle Namespaces für die clusterinterne Steuerungsebene geändert haben oder diese als Sicherung beibehalten. istiod wird automatisch herunterskaliert, um weniger Ressourcen zu verwenden. Fahren Sie mit Alte Steuerungsebene löschen fort.

Falls Probleme auftreten, können Sie diese ermitteln und beheben. Dazu verwenden Sie die Informationen unter Probleme mit der verwalteten Steuerungsebene beheben und führen bei Bedarf ein Rollback auf die vorherige Version durch.

Alte Steuerungsebene löschen

Nachdem Sie die Installation abgeschlossen und bestätigt haben, dass alle Namespaces die von Google verwaltete Steuerungsebene verwenden, können Sie die alte Steuerungsebene löschen.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Wenn Sie istioctl kube-inject anstelle der automatischen Einschleusung verwendet oder zusätzliche Gateways installiert haben, prüfen Sie die Messwerte für die Steuerungsebene und achten Sie darauf, dass die Anzahl der verbundenen Endpunkte null ist.

Rollback durchführen

Führen Sie die folgenden Schritte aus, um ein Rollback auf die vorherige Version der Steuerungsebene durchzuführen:

  1. Aktualisieren Sie Arbeitslasten, damit die vorherige Version der Steuerungsebene eingeschleust werden kann: Im folgenden Befehl wird der Überarbeitungswert asm-191-1 nur als Beispiel verwendet. Ersetzen Sie den Beispielwert durch das Überarbeitungslabel der vorherigen Steuerungsebene.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
    
  2. Starten Sie die Pods neu, um die erneute Injektion auszulösen, damit die Proxys die vorherige Version erhalten:

    kubectl rollout restart deployment -n NAMESPACE
    

Die verwaltete Steuerungsebene wird automatisch auf null skaliert und verwendet keine Ressource, wenn sie nicht verwendet wird. Die geänderten Webhooks und die Bereitstellung bleiben erhalten und wirken sich nicht auf das Clusterverhalten aus.

Für das Gateway ist jetzt die Überarbeitung asm-managed festgelegt. Führen Sie den Anthos Service Mesh-Installationsbefehl noch einmal aus, um ein Rollback durchzuführen. Dadurch wird das Gateway wieder bereitgestellt, das auf Ihre clusterinterne Steuerungsebene verweist:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Bei Erfolg können Sie diese Ausgabe erwarten:

deployment.apps/istio-ingressgateway rolled back

Ein Gateway zur von Google verwalteten Steuerungsebene migrieren

  1. Erstellen Sie unter Vernwendung der Dokumentation ein Kubernetes-Deployment für die neue Version des Gateways. Sie müssen den vorhandenen Kubernetes Gateway-Dienst so konfigurieren, dass die alte und die neue Version ausgewählt werden. Verwenden Sie dazu in der Servicekonfiguration das Feld selector.

  2. Mit dem Befehl kubectl scale lässt sich die neue Bereitstellung schrittweise hochskalieren. Gleichzeitig können Sie die alte Bereitstellung herunterskalieren und auf Anzeichen von Dienstunterbrechungen oder Ausfallzeiten achten. Bei einer erfolgreichen Migration sollten Sie ohne jede Dienstunterbrechung null alte Instanzen erreichen.

Deinstallieren

Von Google verwaltete Steuerungsebene wird automatisch auf null skaliert, wenn keine Namespaces verwendet werden, sodass keine Deinstallation nötig ist.

Fehlerbehebung

Informationen zum Identifizieren und Beheben von Problemen bei der Verwendung der verwalteten Steuerungsebene finden Sie unter Probleme mit der verwalteten Steuerungsebene beheben.

Nächste Schritte