Verwaltetes Anthos Service Mesh konfigurieren

Übersicht

Managed Anthos Service Mesh ist eine von Google verwaltete Steuerungsebene und eine optionale Datenebene, die Sie nur konfigurieren müssen. Google sorgt für ihre Zuverlässigkeit, Upgrades, Skalierung und Sicherheit in abwärtskompatibler Art und Weise. In dieser Anleitung wird erläutert, wie Sie Anwendungen einrichten oder zum verwalteten Anthos Service Mesh in einer Einzel- oder Multi-Cluster-Konfiguration mit asmcli migrieren.

Informationen zu den unterstützten Features und Einschränkungen des verwalteten Anthos Service Mesh finden Sie unter Unterstützte Features für verwaltetes Anthos Service Mesh.

Vorbereitung

Sie sollten Folgendes bereits haben:

Voraussetzungen

  • Ein oder mehrere Cluster mit einer unterstützten Version von GKE in einer der unterstützten Regionen.
  • Ihre Cluster müssen in einer Flotte registriert sein. Dieser Schritt kann separat vor der Installation oder im Rahmen der Installation erfolgen. Übergeben Sie dazu die Flags --enable-registration und --fleet-id.

  • In Ihrem Projekt muss das Service Mesh-Feature aktiviert sein. Sie können die Funktion im Rahmen der Installation aktivieren, indem Sie --enable-gcp-components übergeben oder den folgenden Befehl ausführen:

    gcloud container hub mesh enable --project=FLEET_PROJECT_ID

    Dabei ist FLEET_PROJECT_ID die Projekt-ID des Flottenhostprojekts.

  • Managed Anthos Service Mesh kann mehrere GKE-Cluster in einem Projekt mit einem einzelnen Projekt oder in einem einzelnen Netzwerk mit mehreren Projekten verwenden. Wenn Sie Cluster zusammenführen, die sich nicht im selben Projekt befinden, müssen sie im selben Flottenhostprojekt registriert sein und die Cluster müssen sich zusammen in einer Konfiguration mit freigegebener VPC im selben Netzwerk befinden. Außerdem empfehlen wir, dass Sie ein Projekt zum Hosten der freigegebenen VPC und zwei Dienstprojekte zum Erstellen von Clustern haben. Weitere Informationen finden Sie unter Cluster mit freigegebener VPC einrichten.

Beschränkungen

Wir empfehlen Ihnen, die Liste der von verwaltetem Anthos Service Mesh unterstützten Features und Einschränkungen durchzugehen. Insbesondere ist Folgendes zu berücksichtigen:

gcloud konfigurieren

Führen Sie die folgenden Schritte auch dann aus, wenn Sie Cloud Shell verwenden.

  1. Authentifizieren Sie sich mit dem Google Cloud CLI:

    gcloud auth login --project PROJECT_ID

  2. Aktualisieren Sie die Komponenten:

    gcloud components update

  3. Wenn Sie Anthos Service Mesh in einem GKE-Cluster installieren, konfigurieren Sie kubectl so, dass auf den Cluster verwiesen wird.

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

Installationstool herunterladen

  1. Laden Sie die neueste Version des Tools in das aktuelle Arbeitsverzeichnis herunter:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli

  2. Machen Sie das Tool ausführbar:

    chmod +x asmcli

Jeden Cluster konfigurieren

Führen Sie die folgenden Schritte aus, um ein verwaltetes Anthos Service Mesh für jeden Cluster in Ihrem Mesh-Netzwerk zu konfigurieren.

Von Google verwaltete Steuerungsebene anwenden

Führen Sie das Installationstool für jeden Cluster aus, der verwaltetes Anthos Service Mesh verwendet. Wir empfehlen, die beiden folgenden Optionen anzugeben:

  • --enable-registration --fleet_id FLEET_PROJECT_ID Diese beiden Flags registrieren den Cluster in einer Flotte, wobei FLEET_ID die Projekt-ID des Fleet-Hostprojekts ist. Wenn Sie ein einzelnes Projekt verwenden, ist FLEET_PROJECT_ID mit PROJECT_ID identisch, also das das Flottenhostprojekt und das Clusterprojekt sind identisch. In komplexeren Konfigurationen wie mehreren Projekten empfehlen wir die Verwendung eines separaten Hostprojekts.

  • --enable-all Dieses Flag aktiviert sowohl die erforderlichen Komponenten als auch die Registrierung.

Diese Optionen sind erforderlich, wenn Sie auch die von Google verwaltete Datenebene bereitstellen möchten. Eine vollständige Liste der Optionen finden Sie auf der Asmcli-Referenzseite.

Bevor Sie die von Google verwaltete Steuerungsebene anwenden können, müssen Sie einen Release-Channel auswählen.

Das asmcli-Tool konfiguriert die verwaltete Steuerungsebene direkt mit Tools und Logik im CLI-Tool. Folgen Sie der nachstehenden Anleitungen je nach Ihrer bevorzugten Zertifizierungsstelle.

Wenn Ihre Organisation VPC Service Control für Ihr Projekt erzwingt, müssen Sie ein zusätzliches Flag konfigurieren: --use-vpcsc. Andernfalls scheitert die Installation. Unterstützung für das VPC-SC-Feature ist in den Kanälen „Regular” und „Rapid” verfügbar. Wenn Sie 1.11 verwenden, müssen Sie den experimentellen Befehl verwenden.

Wenn es sich bei Ihrem Cluster um einen GKE-Autopilot-Cluster handelt, prüfen Sie am Ende dieses Abschnitts, ob zusätzliche Anforderungen und Flags für den Befehl "asmcli" erforderlich sind.

Beachten Sie, dass das Plug-in "Istio Container Network Interface" (CNI) standardmäßig aktiviert ist, wenn Sie die von Google verwaltete Steuerungsebene bereitstellen.

Zertifizierungsstellen

Wählen Sie eine Zertifizierungsstelle für Ihr Mesh aus.

Mesh CA

Führen Sie den folgenden Befehl aus, um die Steuerungsebene mit Standardfeatures und Mesh CA zu installieren. Geben Sie Ihre Werte in die angegebenen Platzhalter ein. Ersetzen Sie RELEASE_CHANNEL durch den entsprechenden Channel: regular, stable oder rapid.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL

CA-Dienst

  1. Führen Sie die Schritte unter Certificate Authority Service konfigurieren aus.
  2. Führen Sie den folgenden Befehl aus, um die Steuerungsebene mit Standardfeatures und Certificate Authority Service zu installieren. Geben Sie Ihre Werte in die angegebenen Platzhalter ein. Ersetzen Sie RELEASE_CHANNEL durch den entsprechenden Channel: regular, stable oder rapid.
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL \
      --ca gcp_cas \
      --ca_pool pool_name

Das Tool lädt alle Dateien zum Konfigurieren der verwalteten Steuerungsebene in das angegebene Verzeichnis --output_dir herunter und installiert das istioctl-Tool und Beispielanwendungen. Bei den Schritten in diesem Leitfaden wird davon ausgegangen, dass Sie istioctl über den --output_dir-Speicherort ausführen, den Sie bei der Ausführung von asmcli install festgelegt haben, wobei istioctl im Unterverzeichnis <Istio release dir>/bin vorhanden ist.

Wenn Sie asmcli im selben Cluster noch einmal ausführen, wird die vorhandene Konfiguration der Steuerungsebene überschrieben. Achten Sie darauf, dass Sie dieselben Optionen und Flags angeben, wenn Sie dieselbe Konfiguration verwenden möchten.

GKE Autopilot

GKE Autopilot wird nur in Anthos Service Mesh im Regular Channel und im Rapid Channel unterstützt. Der Cluster muss sich im GKE-Rapid Channel mit Version 1.21.3+ befinden. Zur Anpassung an das Ressourcenlimit von GKE Autopilot werden die Standardanfragen und -limits für Proxy-Ressourcen auf 500 mCPU und 512 MB Arbeitsspeicher festgelegt. Autopilot-Cluster erfordern das verwaltete CNI, sodass Sie das Flag --use_managed_cni angeben müssen. Ersetzen Sie RELEASE_CHANNEL durch den entsprechenden Channel: regular, stable oder rapid.

./asmcli install \
    -p PROJECT_ID \
    -l LOCATION \
    -n CLUSTER_NAME \
    --managed \
    --verbose \
    --output_dir CLUSTER_NAME \
    --use_managed_cni \
    --channel RELEASE_CHANNEL \
    --enable-all \

Bereitstellung der Steuerungsebene prüfen

Das asmcli-Tool erstellt eine benutzerdefinierte ControlPlaneRevision-Ressource im Cluster. Der Status dieser Ressource wird aktualisiert, wenn die verwaltete Steuerungsebene bereitgestellt wird oder wenn die Bereitstellung fehlschlägt.

Prüfen Sie den Status der Ressource. Ersetzen Sie NAME durch den Wert des jeweiligen Kanals: asm-managed, asm-managed-stable oder asm-managed-rapid.

kubectl describe controlplanerevision NAME -n istio-system

Die Ausgabe sieht etwa so aus:

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

Die abgeglichene Bedingung ermittelt, ob die verwaltete Steuerungsebene ordnungsgemäß ausgeführt wurde. Wenn true gilt, wird die Steuerungsebene erfolgreich ausgeführt. Stalled gibt an, dass bei der Bereitstellung der verwalteten Steuerungsebene ein Fehler festgestellt wurde. Bei Stalled enthält das Feld Message weitere Informationen zum jeweiligen Fehler. Weitere Informationen zu möglichen Fehlern finden Sie unter Fehlercodes.

Zero-Touch-Upgrades

Sobald die von Google verwaltete Steuerungsebene installiert ist, führt Google ein Upgrade automatisch durch, wenn ne ue Releases oder Patches verfügbar sind.

Es ist nicht obligatorisch, bei jedem Upgrade der Steuerungsebene ein Upgrade der Datenebene durchzuführen. Die Steuerungsebene funktioniert weiterhin mit allen Proxys im Supportfenster. Das Upgrade wird jedoch empfohlen, um Zugriff auf die neuesten Features der Datenebene, Korrekturen und Leistungsverbesserungen zu erhalten. Sie können entweder einen rollierenden Neustart vornehmen, um das Upgrade auf das neueste veröffentlichte Proxy-Image in Ihrem Kanal durchzuführen, oder die von Google verwaltete Datenebene anwenden, die dies automatisch für Sie erledigt.

Von Google verwaltete Datenebene anwenden (optional)

Wenn Sie möchten, dass Google Upgrades der Proxys verwaltet, aktivieren Sie die von Google verwaltete Datenebene. Wenn diese Option aktiviert ist, werden die Sidecar-Proxys und injizierten Gateways automatisch in Verbindung mit der verwalteten Steuerungsebene aktualisiert.

Beachten Sie, dass die von Google verwaltete Datenebene das Plug-in Istio Container Network Interface (CNI) erfordert, das jetzt standardmäßig aktiviert ist, wenn Sie die von Google verwaltete Steuerungsebene bereitstellen.

In der Feature-Vorschau aktualisiert die verwaltete Steuerungsebene Proxys durch Entfernen von Pods, auf denen ältere Versionen des Proxys ausgeführt werden. Die Bereinigungen werden in einer geordneten Weise vorgenommen. Dabei wird das Budget für die Pod-Unterbrechung berücksichtigt und die Änderungsrate kontrolliert.

In diesem Vorschaurelease der verwalteten Datenebene wird Folgendes nicht verwaltet:

  • Nicht eingefügte Pods.
  • Manuell mit istioctl kube-inject eingefügte Pods.
  • Jobs
  • Zustandsorientierte Sets
  • DaemonSet

Die verwaltete Datenebene ist in beiden Release-Kanälen verfügbar: "Rapid" und "Regular".

So aktivieren Sie die von Google verwaltete Datenebene:

  1. Aktivieren Sie die Verwaltung der Datenebene:

    kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

    Alternativ können Sie die von Google verwaltete Datenebene für einen bestimmten Pod aktivieren, indem Sie sie mit derselben Annotation versehen. Wenn Sie einen bestimmten Pod mit Annotationen versehen, verwendet dieser Pod den von Google verwalteten Sidecar-Proxy und der Rest der Arbeitslasten verwendet die nicht verwalteten Sidecar-Proxys.

  2. Wiederholen Sie den vorherigen Schritt für jeden Namespace, den Sie für eine verwaltete Datenebene benötigen.

    Es kann bis zu zehn Minuten dauern, bis der Datenebenen-Controller zur Verwaltung der Proxys im Cluster bereit ist. Führen Sie den folgenden Befehl aus, um den Status zu prüfen:

    if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

    Wenn der Datenebene-Controller bereit ist, gibt der Befehl Folgendes aus: Managed Data Plane is ready.

Wenn der Datenebene-Controller nach mehr als zehn Minuten nicht bereit ist, lesen Sie die Tipps zur Fehlerbehebung unter Status der verwalteten Datenebene.

Wenn Sie die von Google verwaltete Datenebene deaktivieren und wieder die Sidecar-Proxys verwalten möchten, ändern Sie die Annotation:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

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

Bevor Sie fortfahren, sollten Sie bereits verwaltetes Anthos Service Mesh auf jedem Cluster konfiguriert haben, wie in den vorherigen Schritten beschrieben. Sie müssen nicht angeben, dass ein Cluster ein primärer Cluster ist, dies ist das Standardverhalten. Sie müssen die Abschnitte Projekt- und Clustervariablen festlegen und Firewallregel erstellen ausführen, bevor Sie die Endpunkterkennung konfigurieren.

Öffentliche Cluster

Endpunkterkennung zwischen öffentlichen Clustern konfigurieren

Wenn Sie mit öffentlichen Clustern (nicht privaten Clustern) arbeiten, finden Sie weitere Informationen unter Endpunkterkennung zwischen öffentlichen Clustern konfigurieren.

Private Cluster

Endpunkterkennung zwischen privaten Clustern konfigurieren

Wenn Sie private GKE-Cluster verwenden, müssen Sie den Endpunkt der Clustersteuerungsebene als öffentlichen Endpunkt statt als privaten Endpunkt konfigurieren. Weitere Informationen finden Sie unter Endpunkterkennung zwischen privaten Clustern konfigurieren.

Eine Beispielanwendung mit zwei Clustern finden Sie im HelloWorld-Dienstbeispiel.

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-rapid fest. Wenn Sie ein anderes Überarbeitungslabel verwenden, klicken Sie auf asm-managed-rapid und ersetzen Sie es durch das entsprechende Label: asm-managed für Regular oder asm-managed-stable für Stable.

Das Überarbeitungslabel entspricht einer Release-Version:

Überarbeitungslabel Kanal
istio.io/rev=asm-managed Regulär
istio.io/rev=asm-managed-rapid Rapid
istio.io/rev=asm-managed-stable Stabile Version 
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

Sie haben die verwaltete Anthos Service Mesh-Steuerungsebene konfiguriert. Wenn Sie auch die verwaltete Datenebene angewendet haben, starten Sie Ihre Arbeitslasten neu. Führen Sie andernfalls ein Rolling Update durch. 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 auch Anthos Service Mesh oder Certificate Authority Service mit Mesh CA in anderen Namespaces ausführt, prüfen Sie, ob die Anwendung mit den anderen Anwendungen kommunizieren kann, die von der Steuerungsebene im Cluster gesteuert werden.

Messwerte der Steuerungsebene prüfen

Sie können die Version der Steuerungsebene und der Datenebene im Metrics Explorer ansehen.

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-rapid"
    • 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.

    Informationen zum aktuellen Kanal der Anthos Service Mesh-Versionszuordnung finden Sie unter Anthos Service Mesh-Versionen pro Kanal.

Anwendungen zu verwaltetem Anthos Service Mesh migrieren

So migrieren Sie zum verwalteten Anthos Service Mesh:

  1. Führen Sie das Tool wie unter Von Google verwaltete Steuerungsebene anwenden beschrieben aus.

  2. (Optional) Wenn Sie die von Google verwaltete Datenebene verwenden möchten, aktivieren Sie die Verwaltung der Datenebene:

    kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

  3. (Optional) Wenn Sie die von Google verwaltete Datenebene verwenden möchten, aktivieren Sie Anthos Service Mesh in der Flotte:

    gcloud alpha container hub mesh enable --project=PROJECT_ID

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

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

  5. So führen Sie ein Rolling Upgrade von Bereitstellungen im Namespace durch:

    kubectl rollout restart deployment -n NAMESPACE

  6. Testen Sie Ihre Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.

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

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

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

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 bestimmen 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

Deinstallieren

Die von Google verwaltete Steuerungsebene wird automatisch auf null skaliert, wenn sie nicht von Namespaces verwendet wird. Eine ausführliche Anleitung finden Sie unter Anthos Service Mesh deinstallieren.

Fehlerbehebung

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

Stalled-Codes von ControlPlaneRevision

Es gibt mehrere Gründe, warum die Bedingung Stalled im Status ControlPlaneRevisions erfüllt sein kann.

Grund Meldung Beschreibung
PreconditionFailed Es werden nur GKE-Mitgliedschaften unterstützt, wobei ${CLUSTER_NAME} kein GKE-Cluster ist. Der aktuelle Cluster scheint kein GKE-Cluster zu sein. Eine verwaltete Steuerungsebene funktioniert nur in GKE-Clustern.
Nicht unterstützter ControlPlaneRevision-Name: ${NAME}. Der Name von ControlPlaneRevision muss einer der folgenden sein:
  • asm-managed
  • asm-managed-rapid
  • asm-managed-stable
Nicht unterstützter ControlPlaneRevision-Namespace: ${NAMESPACE}. Der Namespace von ControlPlaneRevision muss istio-system sein.
Nicht unterstützter Kanal ${CHANNEL} für ControlPlaneRevision mit dem Namen ${NAME}. Erwartet wird ${OTHER_CHANNEL}. Der Name von ControlPlaneRevision muss mit dem Kanal von ControlPlaneRevision übereinstimmen:
  • asm-managed -> Regulär
  • asm-managed-rapid -> Schnell
  • asm-managed-stable -> Stabil
Der Kanal darf nicht weggelassen werden oder leer sein. Channel ist ein Pflichtfeld für ControlPlaneRevision. Es fehlt in der benutzerdefinierten Ressource oder ist leer.
Nicht unterstützter Überarbeitungstyp der Steuerungsebene: ${TYPE}. managed_service ist das einzige zulässige Feld für das Feld ControlPlaneRevisionType.
Nicht unterstützte Kubernetes-Version: ${VERSION}. Kubernetes-Versionen ab 1.15 werden unterstützt.
Workload Identity ist nicht aktiviert. Aktivieren Sie Workload Identity in Ihrem Cluster.
Nicht unterstützter Arbeitslastpool: ${POOL}. Der Arbeitslastpool muss das Format ${PROJECT_ID}.svc.id.goog haben.
Clusterprojekt und Environ-Projekt stimmen nicht überein. Cluster müssen zu dem Projekt gehören, in dem sie für den Gerätepool registriert sind.
ProvisioningFailed Beim Aktualisieren von Clusterressourcen ist ein Fehler aufgetreten. Google konnte Ihre clusterinternen Ressourcen wie CRDs und Webhooks nicht aktualisieren.
„istioistiod-asm-managed“ von MutatingWebhookConfiguration enthält einen Webhook mit der URL ${EXISTING_URL}. Es wird aber ${EXPECTED_URL} erwartet. Google überschreibt keine vorhandenen Webhooks, damit die Installation nicht geändert wird. Aktualisieren Sie diesen manuell, wenn es erforderlich ist.
ValidatingWebhookConfiguration ${NAME} enthält einen Webhook mit der URL ${EXISTING_URL}. Es wird aber ${EXPECTED_URL} erwartet. Google überschreibt keine vorhandenen Webhooks, damit die Installation nicht geändert wird. Aktualisieren Sie diesen manuell, wenn es erforderlich ist.

Nächste Schritte