Agent Substrate in GKE installieren

Agent Substrate in GKE führt agentische Arbeitslasten effizient in GKE-Clustern aus: Ihre Anwendung setzt inaktive Agenten aus und das System stellt sie wieder her, wenn sie wieder aktiv werden müssen. Agent Substrate in der GKE ist eine Open-Source-Software, die Sie in einem GKE Standard-Cluster installieren können. Informationen zum Vergleichen von Agent Substrate in der GKE mit Agent Sandbox in der GKE und zum Auswählen einer Architektur für Ihre KI-Agent-Arbeitslasten finden Sie unter Architektur für KI-Agent-Arbeitslasten in der GKE planen.

In diesem Dokument wird beschrieben, wie Sie Ihr Google Cloud -Projekt und Ihren GKE-Cluster für Agent Substrate in GKE vorbereiten. Außerdem wird erläutert, wie Sie das Installationsprogramm ausführen, und die Ressourcen beschrieben, die bei der Installation erstellt werden.

Preise

Agent Substrate in der GKE wird ohne Aufpreis angeboten. Für die von Ihnen erstellten Ressourcen gelten die GKE-Preise.

Beschränkungen

Für Agent Substrate in der GKE gelten die folgenden Installationsbeschränkungen:

  • Cloud Shell: Sie können Agent Substrate nicht auf GKE in Cloud Shell installieren, da Cloud Shell 5 GB nichtflüchtigen Speicher bietet, was für die Installation nicht ausreicht. Sie müssen das Installationsprogramm auf Ihrem lokalen Computer ausführen.
  • Clustermodus: Sie können Agent Substrate in GKE nur in GKE Standard-Clustern installieren. Autopilot-Cluster werden nicht unterstützt.
  • Clusterversion: Sowohl die Steuerungsebene als auch die Knotenpools in Ihrem Cluster müssen die GKE-Version 1.37 oder höher ausführen. Versionen vor 1.37 werden nicht unterstützt.
  • Release-Version: Sie können Agent Substrate in GKE nicht auf Clustern installieren, die für die erweiterte Release-Version registriert sind. Das Installationsprogramm aktiviert Kubernetes-Beta-APIs in Ihrem Cluster und die erweiterte Release-Version unterstützt keine explizit aktivierten Beta-APIs.
  • Maschinentypen: Sie können keine Maschinenserien verwenden, die auf gemischten CPU-Architekturen ausgeführt werden (z. B. E2-Maschinentypen).

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  • Installieren Sie die folgenden Komponenten in der gcloud CLI:
    • kubectl
    • gke-gcloud-auth-plugin
  • Prüfen Sie, ob die folgenden Tools auf Ihrem lokalen Computer installiert sind:
    • Git, um das Agent Substrate-Repository zu klonen.
    • Go, um die Programme des Installers auszuführen, die als Quellcode verteilt werden.
    • make, um das Installationsprogramm zu starten.
    • Docker und das zugehörige Buildx-Plug-in, um die Agent Substrate on GKE-Container-Images zu erstellen.
    • sha256sum, zstd, unzip und jq, um die MicroVM-Laufzeit einzurichten, wenn Sie sie verwenden möchten. Das Installationsprogramm bietet die MicroVM-Laufzeit nicht an, wenn eines dieser Tools fehlt.

  • Damit das Installationsprogramm die von ihm erstellten Images per Push übertragen kann, konfigurieren Sie Docker für die Authentifizierung bei Artifact Registry in der Region Ihres Clusters:

    gcloud auth configure-docker REGION-docker.pkg.dev

    Ersetzen Sie REGION durch die Region Ihres Clusters, z. B. us-west1. Weitere Informationen finden Sie unter Authentifizierung bei Artifact Registry für Docker konfigurieren.

  • Da das Installationsprogramm in Ihrem Namen APIs aktiviert und Ressourcen bereitstellt, richten Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) ein. Führen Sie dazu den folgenden Befehl aus:

    gcloud auth application-default login

    Weitere Informationen zur Authentifizierung mit ADC finden Sie unter Standardanmeldedaten für Anwendungen einrichten.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Installieren von Agent Substrate in GKE benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Clusteranforderungen

Wenn Sie den Installer einen Cluster für Sie erstellen lassen, wird automatisch ein Cluster konfiguriert, der alle Anforderungen für Agent Substrate in GKE erfüllt.

Wenn Sie Agent Substrate in einem vorhandenen GKE-Cluster installieren möchten, muss dieser Cluster die folgenden Anforderungen erfüllen:

  • Wird in GKE Standard ausgeführt (Agent Substrate in GKE wird nur in Standard-Clustern unterstützt).
  • Auf der Steuerungsebene und in den Knotenpools wird die GKE-Version 1.37 oder höher ausgeführt. Wenn auf der Steuerungsebene eine frühere Version ausgeführt wird, aktualisieren Sie zuerst die Steuerungsebene. Aktualisieren Sie dann alle Knotenpools, auf denen eine frühere Version ausgeführt wird, damit die Knoten Pod-Zertifikate in Pods bereitstellen können.
  • Der Cluster ist nicht für die erweiterte Release-Version registriert. Weitere Informationen finden Sie unter Einschränkungen.
  • Verwendet GKE Dataplane V2.
  • Verwendet c3-standard-4 oder größere Maschinentypen für Knoten.

  • Wenn Sie mehr als etwa 800 gleichzeitige Sandboxen pro Knoten ausführen möchten, verwendet der Cluster Knoten mit höheren Limits im Linux-Kernel für das Monitoring des Dateisystems (inotify) und für die Nachbartabelle des Address Resolution Protocol (ARP). Ohne diese höheren Limits können Sandboxes möglicherweise nicht gestartet werden und das Netzwerk kann ins Stocken geraten. Die Knoten benötigen die folgenden Kerneleinstellungen:

    • net.ipv4.neigh.default.gc_thresh1: 4096
    • net.ipv4.neigh.default.gc_thresh2: 16384
    • net.ipv4.neigh.default.gc_thresh3: 32768
    • fs.inotify.max_user_instances: 65536
    • fs.inotify.max_user_watches: 1048576

    Das Installationsprogramm wendet diese Einstellungen automatisch nur auf Cluster an, die es erstellt. Wenn Sie diese Einstellungen auf Knotenpools in einem vorhandenen Cluster anwenden möchten, verwenden Sie eine Knotensystemkonfiguration. Weitere Informationen finden Sie unter Sysctl-Konfigurationsoptionen.

Agent Substrate in der GKE installieren

Führen Sie einen der folgenden Befehle in Ihrem lokalen Terminal aus, um Agent Substrate in GKE zu installieren:

  • Führen Sie den folgenden Befehl aus, um die Installation für Ihre eigenen Arbeitslasten vorzunehmen:

    curl -sSL https://raw.githubusercontent.com/ai-on-gke/substrate-gke/main/install.sh | bash

  • Führen Sie den folgenden Befehl aus, um die Zähler-Demo zu installieren und auszuprobieren:

    curl -sSL https://raw.githubusercontent.com/ai-on-gke/substrate-gke/main/install.sh | bash -s -- --demo

Das interaktive Installationsprogramm fordert Sie auf, Ihre Container-Images sowie Ihre Projekt-, Cluster-, Speicher- und Ingress-Einstellungen anzugeben. Das Installationsprogramm schlägt nach Möglichkeit empfohlene Standardeinstellungen vor, die Sie akzeptieren oder anpassen können:

  • Container-Images (erforderlich): Wenn Sie vom Installationsprogramm aufgefordert werden, Ihre Images auszuwählen, wählen Sie Aus Quelle erstellen aus. Das Installationsprogramm erstellt die Images aus dem Upstream-Agent Substrate-Repository und überträgt sie per Push in ein Artifact Registry-Repository in Ihrem Projekt. Standardmäßig erstellt das Installationsprogramm die aktuelle Version von Agent Substrate. Wenn Sie eine andere Version erstellen möchten, geben Sie einen Zweig, ein Tag oder einen vollständigen Commit-SHA aus dem Upstream-Repository ein.
  • Projekt-ID (erforderlich): Geben Sie das Google Cloud -Projekt an, in dem Ressourcen bereitgestellt werden. Wenn Sie ein Standardprojekt für die gcloud CLI konfiguriert haben, verwendet das Installationsprogramm diese Projekt-ID.
  • Cluster (erforderlich): Wählen Sie aus, ob das Installationsprogramm einen neuen GKE-Cluster mit empfohlenen Standardeinstellungen erstellen oder Agent Substrate on GKE in einem vorhandenen Cluster installieren soll. Wenn Sie die Installation in einem vorhandenen Cluster durchführen möchten, prüfen Sie, ob dieser die Anforderungen im Abschnitt Clusteranforderungen erfüllt.
  • Snapshot-Bucket (optional): Geben Sie einen benutzerdefinierten Cloud Storage-Bucket-Namen an oder lassen Sie das Feld leer, damit das Installationsprogramm einen Standard-Bucket mit dem Namen ate-snapshots-<project>-<cluster>-<zone> erstellt. Da der Standardname den Clusternamen enthält, verwenden Cluster im selben Projekt und in derselben Zone keinen gemeinsamen Bucket. Ein benutzerdefinierter Name darf maximal 56 Zeichen lang sein, da das Installationsprogramm auch einen Asset-Bucket erstellt, indem es das Suffix -assets an den Namen anhängt. Bucket-Namen dürfen maximal 63 Zeichen lang sein. Wenn der Standardname länger als 56 Zeichen ist, wird er vom Installationsprogramm gekürzt und ein Hash angehängt.
  • Ingress-Clients (erforderlich): Geben Sie die SPIFFE-IDs der Arbeitslasten ein, die Anfragen an Ihre Akteure senden, z. B. den Frontend- oder Backend-Dienst Ihrer Anwendung. Eine SPIFFE-ID identifiziert eine Arbeitslast anhand des Namespace und des Kubernetes-Dienstkontos, als das die Pods ausgeführt werden. Beispiel: Pods, die im Namespace shop als Dienstkonto frontend ausgeführt werden, haben die SPIFFE-ID spiffe://cluster.local/ns/shop/sa/frontend. Da die ID nur vom Namespace und vom Dienstkonto abhängt, können Sie IDs für Clients eingeben, die Sie noch nicht bereitgestellt haben. Trennen Sie mehrere IDs durch Kommas. Anfragen erreichen Ihre Akteure über einen Ingress-Router, der nur Clients zulässt, die ein Pod-Zertifikat vorweisen, dessen SPIFFE-ID in dieser Liste enthalten ist. Jeder Client auf der Liste kann jeden Akteur erreichen. Wenn Sie das Flag --demo angeben, lässt das Installationsprogramm nur die Pods der Counter-Demo zu, anstatt nach IDs zu fragen. Informationen zum Hinzufügen von Clients nach der Installation finden Sie in der README-Datei zu substrate-gke unter Akteure über den Ingress-Router erreichen.

Was der Installateur tut

Das Installationsprogramm führt die folgenden Programme in Ihrem Namen aus:

  • setup-gcp: Erstellt oder prüft die erforderlichen Google Cloud -Ressourcen, aktiviert APIs, erstellt den GKE-Cluster (wenn Sie keinen vorhandenen Cluster verwenden möchten) und den Cloud Storage-Bucket und konfiguriert IAM-Richtlinien.
  • ate-setup: Stellt das Agent Substrate auf GKE-Container-Images und -Controllern in Ihrem GKE-Cluster bereit.

Zuerst nimmt das Installationsprogramm die folgenden Änderungen an Ihrem Google Cloud -Projekt vor:

  1. Aktiviert die Google Cloud -APIs, die Agent Substrate in GKE benötigt.
  2. Erstellt einen GKE-Standardcluster (wenn kein vorhandener Cluster verwendet wird), auf dem Version 1.37 oder höher ausgeführt wird und der die folgenden Einstellungen hat:
    • Workload Identity Federation for GKE: Ermöglicht Agent Substrate in GKE den Zugriff auf Cloud Storage, ohne Schlüssel auf den Knoten zu speichern.
    • GKE Dataplane V2: Verarbeitet das Netzwerk, das zum Weiterleiten eingehender Anfragen an Ihre Agents erforderlich ist.
    • Verwaltetes OpenTelemetry: Erfasst Messwerte und Traces aus Ihrem Cluster.
  3. Erstellt die Cloud Storage-Buckets, die Agent Substrate in GKE verwendet: einen für Ihre Snapshots und einen für die Dateien, die die MicroVM-Laufzeit benötigt. Der Name des zweiten Buckets ist der Name des Snapshot-Buckets, gefolgt vom Suffix -assets.
  4. Erstellt ein Artifact Registry-Repository mit dem Namen ate-images für die Container-Images, die vom Installationsprogramm erstellt werden.
  5. Erstellt ein Dienstkonto mit dem Namen ate-snapshot-transfer, das von Agent Substrate on GKE zum Übertragen von Snapshots verwendet wird.
  6. Gewährt den GKE-Knoten, den Agent Substrate on GKE-Komponenten und dem Dienstkonto ate-snapshot-transfer die IAM-Berechtigungen, die sie für den Zugriff auf die Buckets und die Container-Images benötigen.
  7. Erstellt Cloud Monitoring-Dashboards, die die Agent Substrate-Routing-Latenz, die Snapshot-Größe und den gRPC-Traffic in GKE darstellen.

Als Nächstes nimmt das Installationsprogramm die folgenden Änderungen an Ihrem Cluster vor:

  1. Fügt Ihrem Cluster die benutzerdefinierten Kubernetes-Ressourcen von Agent Substrate on GKE hinzu, z. B. WorkerPool (definiert, wie viele inaktive Sandboxes bereitgehalten werden) und SandboxConfig (definiert eine Sandbox-Laufzeit). Andere Agent Substrate-Ressourcen in GKE, z. B. ActorTemplate (definiert die Container-Images und Ressourcen, die Ihre Agents verwenden) und Akteure, sind keine Kubernetes-Ressourcen. Sie verwalten sie über die Agent Substrate on GKE API mit dem kubectl ate-Plug-in, einem kubectl-Plug-in zum Verwalten von Akteuren und Workern. Informationen zum Installieren des Plug-ins finden Sie unter kubectl ate-Plug-in installieren.
  2. Richtet die Zertifizierungsstellen ein, die die Zertifikate ausstellen, die Agent Substrate auf GKE-Komponenten und Ihre Akteure identifizieren. Komponenten präsentieren diese Zertifikate, um sich gegenseitig mithilfe von mTLS zu authentifizieren.
  3. Stellt Agent Substrate auf GKE-Komponenten in Ihrem Cluster bereit, zusammen mit einer PostgreSQL-Datenbank, die den Status Ihrer Akteure und Worker verfolgt. Die Datenbank speichert ihre Daten auf einem nichtflüchtigen Speicher mit 500 GiB. Das Installationsprogramm wartet, bis die Datenbank und alle Pods der Steuerungsebene bereit sind. Bei Produktionsclustern können Sie die PostgreSQL-Datenbank und die Systeminfrastrukturkomponenten auf dedizierten Knotenpools isolieren, bevor Sie das Installationsprogramm ausführen. Eine Anleitung finden Sie unter Systeminfrastruktur und Worker-Knotenpools isolieren.

Agent Substrate in der GKE stellt seine Komponenten als normale Arbeitslasten in den Namespaces ate-system und podcertificate-controller-system bereit. Wenn Sie die Installation in einem vorhandenen Cluster durchführen, aktualisiert das Installationsprogramm auch den Cluster, um die folgenden Features zu aktivieren, falls sie deaktiviert sind: Workload Identity Federation for GKE, Managed OpenTelemetry und die Betaversionen der Kubernetes APIs podcertificaterequests und clustertrustbundles. Durch das Aktivieren der Beta-APIs wird die GKE-Steuerungsebene aktualisiert. Dies dauert etwa 10 Minuten.

Zu den bereitgestellten Komponenten gehört die gVisor-basierte Laufzeit, die Agent Substrate in GKE standardmäßig verwendet, um jeden Ihrer Agenten vom Knoten zu isolieren, auf dem er ausgeführt wird. Wenn Sie die MicroVM-Laufzeit während der optionalen Schritte auswählen, lädt das Installationsprogramm auch die Dateien, die die MicroVM-Laufzeit benötigt, in Cloud Storage hoch und wendet eine clusterweite SandboxConfig-Ressource mit dem Namen microvm an, die auf diese Dateien verweist.

Worker, die die MicroVM-Laufzeit verwenden, benötigen Knoten, auf denen virtuelle Maschinen ausgeführt werden können. Wenn das Installationsprogramm einen Cluster erstellt, ist für den erstellten Knotenpool die verschachtelte Virtualisierung aktiviert. Wenn Sie die erweiterte Einrichtung auswählen und den Maschinentyp ändern, wählen Sie eine Maschinenreihe aus, die verschachtelte Virtualisierung unterstützt, z. B. C3, C4, N2 oder N4.

Wenn Sie Agent Substrate in einem vorhandenen Cluster in GKE installieren, fügt das Installationsprogramm dem Cluster keine Knotenpools hinzu. Damit die MicroVM-Laufzeit verwendet werden kann, benötigt der Cluster einen Knotenpool, für den die verschachtelte Virtualisierung aktiviert ist oder der einen x86-Bare-Metal-Maschinentyp verwendet. Sie können die verschachtelte Virtualisierung nur aktivieren, wenn Sie einen Knotenpool erstellen. Wenn der Cluster keinen solchen Knotenpool hat, werden Sie vom Installationsprogramm gewarnt, wenn Sie die microVM-Laufzeit auswählen. Wenn Sie fortfahren, bleiben die microVM-Worker im Status Pending. Weitere Informationen zum Konfigurieren dieser Knotenpools, einschließlich Markierungen, finden Sie unter Sandbox-Laufzeiten in der substrate-gke-README-Datei.

Wenn die Installation an irgendeiner Stelle fehlschlägt (z. B. aufgrund eines vorübergehenden Netzwerkfehlers oder eines abgelaufenen Tokens), führen Sie den Befehl noch einmal aus. Das Installationsprogramm behält vorhandene Ressourcen bei und setzt die Installation an der Stelle fort, an der sie unterbrochen wurde.

Wenn Sie eine vorhandene Installation von Agent Substrate in der GKE aktualisieren möchten, führen Sie das Installationsprogramm aus und wählen Sie Installierten Cluster aktualisieren aus. Diese Option ändert Ihren Cluster nicht. Stattdessen lädt das Installationsprogramm den Quellcode der installierten Version und der Version herunter, auf die Sie ein Upgrade ausführen, und bereitet das Verzeichnis ~/ate-upgrade vor, das vom Upgrade-Runbook verwendet wird. Führen Sie das Upgrade aus, indem Sie den vom Installationsprogramm ausgegebenen Befehl ausführen und dann dem Upgrade-Runbook im Upstream-Agent-Substrate-Repository aus dem ersten Schritt folgen. Das Runbook unterstützt Upgrades auf ein späteres Patch-Release derselben Nebenversion und für Version 1.0 und höher auf die nächste Nebenversion. Bei Versionen vor 1.0 ist für den Wechsel zu einer höheren Nebenversion eine Neuinstallation erforderlich. Weitere Informationen finden Sie in der substrate-gke-README-Datei unter Installierten Cluster aktualisieren.

Optionale Schritte

Nach der Bereitstellung der Kernkomponenten bietet das Installationsprogramm die folgenden optionalen Schritte:

  • Filestore-CSI-Treiber: Installiert den Filestore-CSI-Treiber, der für Agent Substrate in GKE konfiguriert ist. Wählen Sie diese Option aus, wenn Ihre Agenten nichtflüchtigen Speicher benötigen, der verfügbar bleibt, wenn ein Agent auf einem anderen Knoten fortgesetzt wird. Jeder Agent erhält einen eigenen Speicher, der nicht mit anderen Agenten geteilt wird. Der Produktionssupport für Filestore-Agent-Volumes ist nur eingeschränkt verfügbar. Sie müssen daher Zugriff anfordern. Weitere Informationen finden Sie unter Filestore-Agent-Volumes mit Agent Substrate in GKE verwenden. Wenn für Ihren Cluster das verwaltete GKE-Filestore-Add-on aktiviert ist, wird es vom Installationsprogramm deaktiviert, bevor der Treiber bereitgestellt wird. Das Installationsprogramm stellt den Treiber im Namespace gcp-filestore-csi-driver bereit und erstellt ein Dienstkonto mit dem Namen substrate-filestore-csi, das die IAM-Berechtigungen hat, die der Treiber benötigt.
  • Knotenpool-Autoscaling: Aktiviert das Cluster-Autoscaling von GKE für Ihren Knotenpool. Sie geben die minimale und maximale Anzahl von Knoten für den Pool an. Wählen Sie diese Option aus, wenn GKE bei Bedarfsspitzen automatisch Knoten hinzufügen und Knoten entfernen soll, wenn Agents gesperrt sind. Überspringen Sie diese Option, wenn Sie eine feste Knotenanzahl mit vorhersehbaren Computing-Kosten bevorzugen. Informationen zum Konfigurieren des automatischen Hardware-Fallbacks mit benutzerdefinierten ComputeClasses, Standby-Kapazitätspuffern und Schutz vor Herunterskalierung für aktive Akteure finden Sie unter Infrastruktur für Agent Substrate in GKE entwerfen.
  • Sandbox-Laufzeit: Hier können Sie die Laufzeit auswählen, die Ihre Agenten isoliert. Das Installationsprogramm installiert die gVisor-Laufzeit als Teil der Kernkomponenten, sodass die gVisor-Laufzeit nicht zusätzlich konfiguriert werden muss. Wenn Sie eine Isolation mit Hardwarevirtualisierung wünschen, wählen Sie die microVM-Laufzeit aus. Bevor Sie diese Option für einen vorhandenen Cluster auswählen, muss der Cluster einen Knotenpool mit aktivierter verschachtelter Virtualisierung haben oder einen x86-Bare-Metal-Maschinentyp verwenden. Weitere Informationen finden Sie unter Was das Installationsprogramm tut.
  • Zähler-Demo: Stellt eine Beispielarbeitslast bereit, die das Sperren und Wiederherstellen von Agents demonstriert. Dieser Schritt wird nur angezeigt, wenn Sie beim Starten des Installationsprogramms das Flag --demo angeben. Wählen Sie diese Option aus, wenn Sie den Cluster nach der Installation testen möchten. Weitere Informationen finden Sie unter Zähler-Demo ausprobieren.

Installation überprüfen

Führen Sie die folgenden Befehle aus, um zu prüfen, ob die Installation erfolgreich war und die Kernkomponenten ausgeführt werden. Achten Sie darauf, dass alle Pods den Status Running haben:

kubectl get pods -n ate-system
kubectl get pods -n podcertificate-controller-system

kubectl ate-Plug-in installieren

Wenn Sie Akteure und ActorTemplate-Ressourcen verwalten möchten, installieren Sie das kubectl ate-Plug-in aus dem Quellcode der von Ihnen installierten Agent Substrate-Version:

git clone --depth 1 --branch VERSION https://github.com/agent-substrate/substrate.git
cd substrate
go install ./cmd/kubectl-ate

Ersetzen Sie VERSION durch die von Ihnen installierte Agent Substrate-Version, z. B. v1.0.0, die Standardversion des Installers.

Mit dem Befehl go install wird das Plug-in im Verzeichnis bin Ihres Go-Arbeitsbereichs platziert. Das kubectl-Tool findet das Plug-in nur, wenn sich dieses Verzeichnis in Ihrer Umgebungsvariablen PATH befindet. Wenn Ihre Umgebungsvariable PATH dieses Verzeichnis nicht enthält, fügen Sie es hinzu, bevor Sie kubectl ate-Befehle ausführen:

export PATH="$PATH:$(go env GOPATH)/bin"

Demo für Zähler ausprobieren

Wenn Sie beim Ausführen des Installers das Flag --demo angegeben und die Counter-Demo bereitgestellt haben, stellt der Installer einen WorkerPool und einen ActorTemplate für einen Webserver bereit, der Anfragen im Arbeitsspeicher und in einer Datei zählt. Agent Substrate on GKE behält beide Werte bei, wenn Sie den Actor, der den Server ausführt, sperren und wiederherstellen.

Nach der Installation gibt das Installationsprogramm die nächsten Schritte der Demo aus: einen Befehl, mit dem das kubectl ate-Plug-in installiert wird, und einen Befehl, mit dem ein Actor aus dem ActorTemplate erstellt wird. Bevor Sie kubectl ate-Befehle ausführen, muss das Plug-in in der Umgebungsvariable PATH enthalten sein, wie unter kubectl ate-Plug-in installieren beschrieben.

Das Installationsprogramm gibt keinen Befehl aus, der Anfragen an den Actor sendet. Der Ingress-Router lässt nur Clients zu, die ein Pod-Zertifikat vorweisen, dessen SPIFFE-ID auf der Zulassungsliste steht. Anfragen, die Sie direkt von Ihrem lokalen Computer senden, werden daher abgelehnt. Weitere Informationen zur Demo finden Sie in der Counter-Demo-README für Version 1.0.0 von Agent Substrate, die vom Installationsprogramm standardmäßig bereitgestellt wird. In einem vom Installationsprogramm eingerichteten Cluster funktionieren die Schritte in der README-Datei, die Anfragen über eine Portweiterleitung senden, aus demselben Grund nicht.

Agent Substrate in der GKE deinstallieren

Wenn die Installation abgeschlossen ist und beendet wird, gibt das Installationsprogramm benutzerdefinierte Bereinigungsbefehle für Ihre Umgebung aus.

Wählen Sie eine der folgenden Optionen aus, um die während der Installation erstellten Ressourcen zu entfernen:

  • Agent Substrate on GKE aus einem vorhandenen Cluster entfernen: Wenn Sie Agent Substrate on GKE in einem vorhandenen Cluster installiert haben und den Cluster und seine anderen Arbeitslasten beibehalten möchten, löschen Sie nur die Agent Substrate on GKE-Komponenten. Führen Sie dazu den Befehl ate-setup delete ate-system aus, der vom Installationsprogramm ausgegeben wird. Das Installationsprogramm füllt diesen Befehl vorab mit den Projekt-, Cluster- und Standortwerten aus, die während der Installation konfiguriert wurden.

  • Alle Ressourcen (einschließlich des Clusters) löschen: Wenn Sie den GKE-Cluster, die Snapshot- und Asset-Buckets, das Dienstkonto ate-snapshot-transfer, IAM-Bindungen, Dashboards und das Artifact Registry-Repository ate-images löschen möchten, führen Sie den Befehl cleanup-gcp aus, der vom Installationsprogramm ausgegeben wird. Das Installationsprogramm füllt diesen Befehl vorab mit den Projekt-, Cluster-, Standort- und Bucket-Werten aus, die während der Installation konfiguriert wurden. Da der Befehl das Skript tools/cleanup-gcp mit einem relativen Pfad ausführt, führen Sie den Befehl in dem Verzeichnis aus, in dem das Installationsprogramm das Repository substrate-gke geklont hat. Standardmäßig klont das Installationsprogramm das Repository in das Verzeichnis ~/.substrate-gke.

    Wenn andere Cluster im Projekt Agent Substrate in der GKE ausführen, fügen Sie dem Befehl das Flag --cluster-scoped hinzu. Mit diesem Flag werden die Dashboards, das Dienstkonto ate-snapshot-transfer und die IAM-Bindungen auf Projektebene beibehalten, die von diesen Clustern gemeinsam genutzt werden. Mit dem Flag --cluster-scoped wird das Repository ate-images nicht beibehalten. Wenn andere Cluster in derselben Region das Repository ate-images verwenden, fügen Sie am Ende des Befehls auch das Flag --keep-repository hinzu. Weitere Informationen finden Sie im Abschnitt „Tearing down“ der README-Datei zu substrate-gke.

Mit dem Befehl cleanup-gcp werden die folgenden Ressourcen nicht gelöscht:

  • Der nichtflüchtige Speicher der PostgreSQL-Datenbank: GKE behält nichtflüchtige Speicher bei, wenn ein Cluster gelöscht wird. Sie zahlen also weiterhin für das 500-GiB-Laufwerk. Führen Sie zum Löschen des Laufwerks den Befehl ate-setup delete ate-system aus, der vom Installationsprogramm ausgegeben wird. Warten Sie dann, bis der Befehl kubectl get pv kein Volume mehr für die Anforderung ate-system/data-postgres-0 auflistet, bevor Sie cleanup-gcp ausführen. Wenn Sie den Cluster bereits gelöscht haben, suchen Sie das Laufwerk mit dem folgenden Befehl und löschen Sie es dann mit dem Befehl gcloud compute disks delete:

    gcloud compute disks list --filter="description~data-postgres-0"

  • Das Dienstkonto substrate-filestore-csi: Alle Cluster im Projekt, auf denen der Filestore-CSI-Treiber ausgeführt wird, verwenden dieses Dienstkonto gemeinsam. Wenn Sie den Treiber installiert haben und keine anderen Cluster im Projekt den Treiber ausführen, löschen Sie das Dienstkonto mit dem folgenden Befehl:

    gcloud iam service-accounts delete substrate-filestore-csi@PROJECT_ID.

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Nächste Schritte