Infrastruktur für Agent Substrate in der GKE entwerfen

Mit der Google Kubernetes Engine (GKE) können Sie Agent Substrate on GKE-Cluster skalieren, um KI-Agenten-Arbeitslasten mit hoher Nebenläufigkeit zu unterstützen und gleichzeitig die Kosten für inaktive Rechenressourcen zu minimieren. Durch die Kombination von dedizierten Knotenpools für die Systeminfrastruktur mit benutzerdefinierten ComputeClasses und Kapazitätspuffern können Sie kritische Systemkomponenten isolieren, das Hardware-Fallback über Compute Engine-Maschinenserien hinweg automatisieren und die Standby-Worker-Kapazität warm halten.

In diesem Dokument erfahren Sie, wie Sie die Größe Ihrer GKE-Clusterkomponenten anpassen, Systeminfrastruktur und Datenbankknotenpools isolieren, die automatische Knotenbereitstellung für WorkerPool-Ressourcen konfigurieren und Clusterwartungen und ‑upgrades planen. Dieses Dokument richtet sich an Plattformadministratoren, die Agent Substrate in der GKE-Infrastruktur bereitstellen und verwalten.

Hinweis

Bevor Sie Ihre Clusterinfrastruktur für die Skalierung konfigurieren, müssen Sie prüfen, ob Ihre Umgebung die folgenden Anforderungen erfüllt:

  • GKE-Clustermodus und -Version: Sie müssen einen GKE Standard-Cluster verwenden, in dem sowohl die Steuerungsebene als auch die Knotenpools Version 1.37 oder höher ausführen. GKE Autopilot-Cluster werden für Agent Substrate in der GKE nicht unterstützt.
  • Agent Substrate on GKE-Installation: Sie müssen eine vorhandene Agent Substrate on GKE-Installation haben oder planen, Agent Substrate on GKE mit aktivierter Knotenisolation für die Systeminfrastruktur zu installieren. Eine Installationsanleitung finden Sie unter Agent Substrate in GKE installieren.

Größe des Agent Substrate-Clusters anpassen

Legen Sie die Größe Ihres Clusters für die maximale Nebenläufigkeit und die maximale Wiederaufnahmerate fest, nicht für die Durchschnittswerte. Worker-Knoten müssen die maximale Anzahl von Akteuren enthalten, die gleichzeitig ausgeführt werden. Die Komponenten der Systeminfrastruktur und die Speicherpfade müssen mit der schnellsten Rate von Akteur-Fortsetzungen und -Aussetzungen Schritt halten.

Arbeitslastspitzen schätzen

Wenn Sie keine Produktionsmessungen haben, schätzen Sie die maximale Nebenläufigkeit und die Wiederaufnahmerate anhand der Gesamtzahl der registrierten Akteure (total_actors), des durchschnittlichen Anteils der gleichzeitig ausgeführten Akteure (average_active_fraction), des Traffic-Burst-Multiplikators (burst_factor) und der durchschnittlichen Dauer, die ein Akteur pro Runde aktiv bleibt (average_seconds_active_per_resume):

peak_running_actors = total_actors × average_active_fraction × burst_factor
peak_resume_rate    = peak_running_actors / average_seconds_active_per_resume

Wenn Sie beispielsweise insgesamt 100.000 Akteure haben, von denen durchschnittlich 10 % aktiv sind (10.000 Akteure), und einen Burst-Faktor von zwei haben, muss Ihr Cluster 20.000 gleichzeitig ausgeführte Akteure unterstützen. Wenn jeder Actor vor dem Anhalten durchschnittlich 100 Sekunden lang ausgeführt wird, sind für die Aufrechterhaltung dieses Spitzenwerts 200 Fortsetzungen pro Sekunde und 200 Anhaltungen pro Sekunde erforderlich.

Agent Substrate on GKE sperrt inaktive Akteure nicht automatisch. Die Sperrung muss von Ihrer Anwendung oder Ihrem Orchestrator ausgelöst werden.

Größe der Datenebene festlegen

In diesem Abschnitt werden Best Practices für die Dimensionierung der Datenebene beschrieben, einschließlich Worker-Pods, GKE-Knoten, Snapshot-Bandbreite und des atelet-Knoten-Agents.

Worker-Pods und GKE-Knoten berechnen

Jeder Worker-Pod in einem WorkerPool hostet mehrere Akteure. Ein Worker kann einen neuen Actor akzeptieren, wenn er weniger Actors hostet, als durch das Flag --max-actors im Container ateworker festgelegt ist (Standardwert 1000), und genügend CPU- und Arbeitsspeicherkapazität hat, um die ActorTemplate-Limits zu erfüllen. Weitere Informationen dazu, wie Worker-Limits mit Actor-Limits interagieren, finden Sie im Open-Source-Leitfaden Right-sizing resources in the Agent Substrate API.

Berechnen Sie die erforderliche Anzahl von Worker-Pods mit 20 % verfügbarer Planungskapazität (Faktor 0.8):

slots_per_worker = min(max_actors, worker_memory / actor_memory, worker_cpu / actor_cpu)
total_workers    = peak_running_actors / (slots_per_worker × 0.8)

In dieser Formel ist die Variable max_actors standardmäßig auf 1000 festgelegt (konfiguriert durch das Flag --max-actors). Subtrahieren Sie den Arbeitsspeicher, den der Worker für seinen eigenen Prozess reserviert, vom Wert worker_memory. Fügen Sie bei microVM-WorkerPool-Ressourcen den vom Worker gemeldeten VMM-Arbeitsspeicher-Overhead (Virtual Machine Monitor) pro Akteur zum Wert actor_memory hinzu, da die Platzierung diesen Overhead auf die Worker-Kapazität anrechnet.

Bei einem Worker-Pod pro Knoten entspricht die Anzahl der Worker der Anzahl der GKE-Worker-Knoten. Weisen Sie dem Worker-Pod nicht 100 % der zuweisbaren CPU und des zuweisbaren Arbeitsspeichers eines Knotens zu. Lassen Sie auf jedem Knoten Kapazität für das atelet-DaemonSet (im Namespace ate-system) und die GKE-System-Daemons frei. GKE Standard unterstützt bis zu 65.000 Knoten pro Cluster und bis zu 512 Pods pro Knoten. Die Standardhöchstzahl beträgt 110 Pods pro Knoten (konfigurierbar mit dem Flag --max-pods-per-node). Für große Cluster gelten zusätzliche Anforderungen.

Snapshot-Bandbreite und Knotenlaufwerke dimensionieren

Bei jeder Actor-Aussetzung wird ein Snapshot auf das lokale Knotenlaufwerk im Verzeichnispfad /var/lib/ate geschrieben. Im SYNCHRONOUS-Modus lädt der atelet-Agent den Snapshot in Cloud Storage hoch, bevor der Vorgang zum Sperren zurückgegeben wird. Im ASYNCHRONOUS-Modus plant der atelet-Agent den Upload in Cloud Storage nach einer Verzögerung, die ungefähr dem Wert des Flags --snapshot-upload-delay (Standardwert 5m) entspricht, ab dem Zeitpunkt, an dem der Snapshot erstellt wird. Agent Substrate speichert den neuesten Snapshot auf dem Knoten für den Zeitraum, der im Flag --snapshot-detach-delay konfiguriert ist. Der Standardwert ist 30m. Ein Actor, der innerhalb dieses Zeitfensters fortgesetzt wird, wird auf demselben Knoten geplant und von der lokalen Festplatte wiederhergestellt, anstatt den Snapshot aus Cloud Storage herunterzuladen.

Schätzen Sie die unkomprimierte Snapshot-Größe (snapshot_size) als das ActorTemplate-Speicherlimit plus alle Daten, die in das beschreibbare Stammdateisystem oder in langlebige Verzeichnisse geschrieben werden. Die Verarbeitung von dünnbesetzten Dateien und die zstd-Komprimierung reduzieren die Größe des komprimierten Snapshots (compressed_snapshot_size), der an und von Cloud Storage übertragen wird. Dort speichert Agent Substrate bis zu zwei Snapshots pro Actor (den vorherigen Snapshot und den Snapshot in Bearbeitung):

  • Maximale Cloud Storage-Bandbreite (pro Richtung): peak_resume_rate × compressed_snapshot_size
  • Maximaler Schreibdurchsatz pro Knoten: 2 × peak_resume_rate × snapshot_size / total_nodes (Sowohl das Fortsetzen von Downloads als auch das Sperren von Prüfpunkten schreiben auf das Laufwerk des Knotens).

Das standardmäßige 100-GiB-hyperdisk-balanced-Bootlaufwerk in GKE bietet 3.600 IOPS und 290 MiB/s Durchsatz (die Standardleistung skaliert mit der Laufwerksgröße), was Snapshot-Vorgänge bei hoher Gast-E/A einschränken kann. Wenn Sie Worker-Knotenpools erstellen, hängen Sie entweder ein dediziertes Laufwerk im Verzeichnispfad /var/lib/ate/snapshots an oder erhöhen Sie die Leistung des Bootlaufwerks, indem Sie die Flags --boot-disk-provisioned-iops und --boot-disk-provisioned-throughput mit dem Befehl gcloud container node-pools create verwenden.

Kontingent für Security Token Service prüfen

Für jede Snapshot-Übertragung zu oder von Cloud Storage ist ein Token erforderlich, das auf den Actor beschränkt ist. Dieses Token wird von der ate-api-server-Komponente von der Security Token Service (STS) API angefordert. Die Komponente ate-api-server stellt alle 20 bis 40 Minuten bis zu eine STS-Anfrage pro Akteur (normalerweise bei der ersten Wiederaufnahme in diesem Zeitfenster) und verwendet das Token bis 20 Minuten vor Ablauf wieder.

Das STS-Kontingent Exchange token global requests ist standardmäßig auf 6.000 Anfragen pro Projekt und Minute festgelegt und wird mit Workload Identity Federation for GKE geteilt:

  • Erforderliches STS-Kontingent (Anfragen pro Minute): Schätzung bis zum 60-fachen der Spitzenrate von Fortsetzungen für Akteure, deren letzte Snapshot-Übertragung mehr als 20 Minuten zurückliegt, plus Kapazität für Workload Identity Federation for GKE. Wenn Sie diese Rate nicht kennen, verwenden Sie die Formel 60 × peak_resume_rate als Fallback. Für 200 Fortsetzungen pro Sekunde sind beispielsweise bis zu 12.000 Anfragen pro Minute erforderlich.
  • Kontingent erhöhen: Beantragen Sie eine Kontingenterhöhung auf der Seite Kontingente und Systemlimits in der Google Cloud Console. Snapshot-Übertragungen funktionieren auch, wenn die Security Token Service API in Ihrem Projekt nicht aktiviert ist. Sie müssen die API jedoch aktivieren, damit das Kontingent auf der Seite Kontingente und Systemlimits angezeigt wird. Weitere Informationen finden Sie in der Dokumentation zu Workload Identity Federation for GKE unter Kontingent für die Exchange Token API im Security Token Service.

atelet-Knoten-Agent optimieren

Das DaemonSet atelet führt einen Pod pro Worker-Knoten aus, um Akteure wiederherzustellen und Prüfpunkte zu erstellen. In jedem atelet-Pod komprimiert der objectstore-plugin-Container Snapshots und überträgt sie an und von Cloud Storage.

In der folgenden Tabelle werden die wichtigsten Einstellungen für die Größenanpassung der Container atelet und objectstore-plugin beschrieben:

Einstellung Standard Größenberatung
atelet- und objectstore-plugin-Container-CPU und -Arbeitsspeicher Anfragen: 50 mCPU, 128 MiB Arbeitsspeicher; keine Limits Konfigurieren Sie die Bursting-fähige QoS ohne Speicherlimits, indem Sie die Speicherlimits für beide Container weglassen, da das Erreichen eines Speicherlimits den Knoten-Agent beendet und alle Fortsetzungen auf dem Knoten anhält. Erhöhen Sie die CPU- und Arbeitsspeicheranforderungen, um die gemessene Spitzenauslastung auf einem vollständigen Knoten bei Ihrer maximalen Fortsetzungsrate zu erreichen, damit Worker-Pods keine Ressourcen verbrauchen, die vom atelet-Agent benötigt werden.
--upload-memory-budget-Flag (objectstore-plugin-Container) und --snapshot-upload-workers-Flag (atelet-Container) 512 MiB Budget; 2 Upload-Worker

So verhindern Sie, dass gleichzeitige Snapshot-Uploads auf Knoten mit mehreren Akteuren und hohen Sperrraten in die Warteschlange gestellt werden:

  • Erhöhen Sie den Wert des Flags --upload-memory-budget und legen Sie die Speicheranfrage für den Container objectstore-plugin höher als dieses Budget fest.
  • Erhöhen Sie den Wert des Flags --snapshot-upload-workers.
Flag --drain-timeout und Feld terminationGracePeriodSeconds 5 Minuten (Flag --drain-timeout); 330 Sekunden (Feld terminationGracePeriodSeconds) Steuert, wie lange der atelet-Agent laufende Wiederherstellungen und Snapshot-Uploads abschließt, wenn sein Pod während eines Knoten-Drains oder -Upgrades beendet wird. Wenn Sie den Wert des Flags --drain-timeout für große Snapshots erhöhen, müssen Sie auch den Wert des Felds terminationGracePeriodSeconds im DaemonSet atelet erhöhen, damit der Agent kubelet den Agenten atelet nicht beendet, bevor die Uploads abgeschlossen sind.

Größe der Systeminfrastrukturkomponenten und der Datenbank festlegen

Schätzen Sie für zustandslose Systemkomponenten-Deployments im Namespace ate-system, die horizontal skaliert werden, die erforderliche Replikatanzahl mit 35 % verfügbarer Kapazität (Faktor 0.65) plus einem Ersatzreplikat (+ 1), um Knotenunterbrechungen zu tolerieren:

replicas = ceil(peak_load / (capacity_per_replica × 0.65)) + 1

Die horizontale Skalierung verbessert den Durchsatz nicht mehr, wenn eine gemeinsame Abhängigkeit (z. B. PostgreSQL-CPU- oder Verbindungslimits) die Kapazität erreicht. Dimensionieren Sie die Infrastrukturkomponenten und die Datenbank Ihres Systems gemeinsam. Weitere Informationen zu Komponenten-Flags finden Sie im Open-Source-Installationsleitfaden für Operatoren.

In der folgenden Tabelle werden die Ressourcen- und Skalierungsregeln für die einzelnen Komponenten der Systeminfrastruktur beschrieben:

Komponente QoS- und Ressourcenregeln Skalierung und Verbindungsoptimierung
Ingress-Router (atenet-router) Garantierten QoS konfigurieren: Legen Sie übereinstimmende CPU- und Arbeitsspeicheranfragen und ‑limits fest, damit die Go-Laufzeit die Threadanzahl an das CPU-Budget des Containers anpasst. Skalieren Sie Replikate horizontal basierend auf den Spitzenwerten für eingehende Anfragen pro Sekunde, dem mTLS-Overhead und den Größen der Anfrage-Nutzlasten.
API-Server (ate-api-server) Garantierten QoS konfigurieren: Legen Sie übereinstimmende CPU- und Arbeitsspeicheranfragen und ‑limits fest, damit die Go-Laufzeit die Threadanzahl an das CPU-Budget des Containers anpasst. Skalieren Sie Replikate basierend auf den Spitzenwerten für Fortsetzungs- und Sperrzyklen pro Sekunde (ca. 4 ms CPU pro Fortsetzungs- und Sperrzyklus) und der Last für die Suche nach eingehenden Anfragen. Legen Sie die Einstellung ateapi.postgres.poolMaxConns explizit fest. Jedes Replikat öffnet bis zu poolMaxConns + 6 Datenbankverbindungen. Die Summe aller Replikate muss unter der PostgreSQL-Einstellung max_connections liegen.
Datenbank (PostgreSQL) Burstable-QoS mit garantiertem Arbeitsspeicher konfigurieren: Legen Sie die Arbeitsspeicheranfragen so fest, dass sie den Limits entsprechen, um den shared_buffers-Cache im Arbeitsspeicher zu sperren und eine OOM-Entfernung (Out-of-Memory) zu verhindern. Lassen Sie CPU-Limits weg, wenn Sie auf einem dedizierten ate-postgres-Knoten arbeiten, damit die CPU-Drosselung des Kernels die Checkpoint- und Autovacuum-Bursts nicht verlangsamt. Skalieren Sie dieses StatefulSet mit einer einzelnen Instanz vertikal. Stellen Sie genügend CPU bereit, um bei Spitzenlast unter 80 % Auslastung zu bleiben, genügend RAM, um die Actor-Tabelle im Cache zu speichern (wobei der Parameter shared_buffers auf etwa 25 % des Arbeitsspeichers festgelegt ist), und eine SSD-gestützte StorageClass, die bei der Installation mit der Einstellung ateapi.postgres.storageClass festgelegt wird (z. B. die StorageClass dynamic-rwo auf C4 oder N4 oder die StorageClass premium-rwo auf C3 oder N2). Erhöhen Sie den Parameter max_connections in der ConfigMap postgres-config (Datei postgresql.conf), damit alle ate-api-server-Replikate Platz haben.
Proxy für ausgehenden Traffic (atenet-egress) Ressourcenregeln: Legen Sie eine CPU-Anfrage von 512 mCPU (Limit 8 vCPUs) und eine Speicheranfrage von 512 MiB (Limit 1 GiB) fest. Erhöhen Sie die Anfragen und Limits, wenn die Latenz des ausgehenden Actor-Traffics zunimmt. Skalieren Sie Replikate horizontal basierend auf dem ausgehenden Anfragetraffic von Akteuren.
Worker-Controller (ate-controller) Ressourcenregeln: Behalten Sie ein Replikat bei (keine Leader-Auswahl). Legen Sie CPU- und Arbeitsspeicheranfragen basierend auf der Spitzenauslastung während großer WorkerPool-Skalierungsereignisse fest. Wenn die Registrierung neuer Worker-Pods in großen Flotten zu lange dauert, erhöhen Sie den Wert des Flags --worker-sync-concurrency (Standardwert: 2).
Zertifikats-Controller (podcertificate-controller) Ressourcenregeln: Wird im Namespace podcertificate-controller-system ausgeführt, um mTLS-Zertifikate für neue Worker-Pods zu signieren, bevor sie Akteure akzeptieren können. Erhöhen Sie bei Flotten mit Tausenden von Workern die Werte der Einstellung podcert.workersPerSigner (Standardwert 0, wodurch der Manifeststandardwert von 1 Worker pro Signierer beibehalten wird), des Flags --kube-api-qps (Standardwert 5) und des Flags --kube-api-burst (Standardwert 10).
Identitätsanbieter (ate-idp-server) Ressourcenregeln: Stellt das OpenID Connect (OIDC)-Discovery-Dokument und das JSON Web Key Set (JWKS) im Namespace ate-system bereit, um Actor-JSON Web Tokens (JWTs) zu prüfen. Legen Sie CPU- und Speicheranforderungen basierend auf dem maximalen JWKS-Abfragevolumen fest. Skalieren Sie Replikate horizontal, wenn vertrauende Seiten den JWKS-Endpunkt mit hohen Anforderungsraten abfragen, ohne Schlüssel im Cache zu speichern.
Anmeldeinformationsanbieter (k8s-credential-provider) Ressourcenregeln: Wird im Namespace ate-system ausgeführt, wenn die Kubernetes-Secret-Anmeldedaten-Injektion aktiviert ist. Legen Sie CPU- und Arbeitsspeicheranfragen basierend auf dem Volumen der ausgehenden Anmeldedaten-Injektionen fest. Skalieren Sie Replikate horizontal basierend auf der Rate der ausgehenden Actor-Anfragen, die eine Kubernetes Secret-Anmeldedaten-Injektion am atenet-egress-Proxy erfordern.

Systeminfrastruktur und Worker-Knotenpools isolieren

In Produktionsclustern können die Planung von Akteuren mit hoher Fluktuation und der Snapshot-Traffic auf Worker-Knoten mit Systeminfrastrukturkomponenten um CPU, Arbeitsspeicher und Laufwerk-E/A konkurrieren. Teilen Sie Ihren GKE-Cluster in drei verschiedene Knotenpoolstufen auf:

  • Datenbankknotenpool (Label ate-postgres): Ein dedizierter Knotenpool für das PostgreSQL-StatefulSet, in dem alle Actor- und Worker-Metadaten gespeichert werden.
  • Knotenpool für die Systeminfrastruktur (Label ate-system-infra): Ein dedizierter Knotenpool für die verbleibenden Systeminfrastrukturdienste (die Komponenten atenet-router, ate-api-server, atenet-egress, ate-controller, ate-idp-server und k8s-credential-provider).
  • Worker-Knotenpools (WorkerPool): Dynamisch skalierte Knotenpools, die von benutzerdefinierten GKE-ComputeClasses und GKE-Kapazitätspuffern verwaltet werden, um aktive Actor-Sandboxes zu hosten.

Sie können die Datenbank- und Systeminfrastrukturkomponenten auf dedizierten Knoten isolieren, wenn Sie Agent Substrate in der GKE installieren. Verwenden Sie dazu die Einstellung cordonSystemInfraComponents (oder das Flag --cordon-system-infra-components). Vor der Installation müssen Sie beide Knotenpools mit den erforderlichen Labels und NoSchedule-Markierungen erstellen:

# 1. Create the dedicated PostgreSQL node pool
gcloud container node-pools create ate-postgres-pool \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --node-locations=POSTGRES_ZONE \
    --machine-type=POSTGRES_MACHINE_TYPE \
    --num-nodes=1 \
    --node-labels=ate.dev/workloadType=ate-postgres \
    --node-taints=ate.dev/workloadType=ate-postgres:NoSchedule

# 2. Create the dedicated system infrastructure node pool
gcloud container node-pools create ate-system-infra-pool \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=SYSTEM_INFRA_MACHINE_TYPE \
    --num-nodes=2 \
    --node-labels=ate.dev/workloadType=ate-system-infra \
    --node-taints=ate.dev/workloadType=ate-system-infra:NoSchedule

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: der Name Ihres GKE-Standardclusters.
  • LOCATION: die Compute Engine-Zone oder -Region der Steuerungsebene Ihres Clusters.
  • POSTGRES_ZONE: eine einzelne Compute Engine-Zone für das PostgreSQL-StatefulSet mit einem einzelnen Replikat. Geben Sie für einen regionalen Cluster eine Zone innerhalb der Region des Clusters an, damit der Knotenpool einen einzelnen Knoten in der Zone bereitstellt, in der der nichtflüchtige Speicher des StatefulSet erstellt wird. Geben Sie für einen zonalen Cluster die Zone des Clusters an.
  • POSTGRES_MACHINE_TYPE: Der Compute Engine-Maschinentyp, der für Ihre PostgreSQL-Instanz dimensioniert ist.
  • SYSTEM_INFRA_MACHINE_TYPE: Der Compute Engine-Maschinentyp, der für Ihre Systeminfrastrukturkomponenten dimensioniert ist (z. B. der Maschinentyp c3-standard-8).

In einem regionalen Cluster gilt das Flag --num-nodes pro Zone. Wenn Sie beispielsweise das Flag --num-nodes=2 für drei Zonen festlegen, werden insgesamt sechs Knoten erstellt. Wenn Sie den Knotenpool ate-system-infra-pool in bestimmten Zonen platzieren möchten, fügen Sie das Flag --node-locations hinzu.

Wenn Sie die Einstellung cordonSystemInfraComponents während der Installation aktivieren und einer der Knotenpools fehlt, bleiben die entsprechenden System-Pods im Status Pending.

Hardware-Targeting mit benutzerdefinierten ComputeClasses automatisieren

Mit benutzerdefinierten ComputeClasses von GKE können Sie priorisierte Listen von Compute Engine-Maschinenserien für Ihre WorkerPool-Knoten definieren und automatisch auf sekundäre Maschinenserien zurückgreifen, wenn in einer Zone Ressourcen nicht verfügbar sind.

Compute Engine-Maschinenreihe nach Laufzeit auswählen

Konfigurieren Sie für jede Sandbox-Laufzeit eine separate ComputeClass:

  • MicroVM-Laufzeit (Cloud Hypervisor): Legen Sie das Feld enableNestedVirtualization: true in Ihren ComputeClass-Prioritäten fest und verwenden Sie x86-Compute Engine-Maschinenserien, die die verschachtelte Virtualisierung unterstützen (z. B. N4, C3, C4 oder N2), oder verwenden Sie x86-Bare-Metal-Maschinentypen, die KVM nativ ausführen und das Feld enableNestedVirtualization nicht benötigen. Arm-basierte VMs und Maschinenserien, die unter Einschränkungen für die verschachtelte Virtualisierung aufgeführt sind, werden nicht unterstützt.
  • gVisor-Laufzeit: Ziel sind x86-Compute Engine-Maschinenserien für allgemeine Zwecke oder computing-optimierte x86-Compute Engine-Maschinenserien (z. B. N4, C3, C4 oder N2) ohne aktivierte verschachtelte Virtualisierung. Maschinenserien, die auf gemischten CPU-Mikroarchitekturen (z. B. E2) ausgeführt werden, und ARM-basierte VMs werden für Agent Substrate in der GKE nicht unterstützt. Alle WorkerPool-Ressourcen, die von einem ActorTemplate ausgewählt werden, müssen dieselbe CPU-Architektur haben.

Einen detaillierten Vergleich finden Sie unter Sandbox-Laufzeit auswählen.

Erforderliche ComputeClass-Regeln für Agent Substrate

Beachten Sie beim Erstellen einer ComputeClass für Agent Substrate auf GKE-Worker-Knoten die folgenden Regeln:

  • Knotenbasierte ComputeClasses verwenden: Verwenden Sie keine Pod-basierte Abrechnung (Feld podFamily), da diese die verschachtelte Virtualisierung nicht unterstützt.
  • Legen Sie das Feld nodePoolConfig.sandbox.type: microvm nicht fest: Mit dieser Einstellung wird die Kata-Laufzeit für GKE Sandbox für podbasierte Arbeitslasten aktiviert und eine sandbox.gke.io/runtime=microvm-Markierung angewendet, die verhindert, dass Agent Substrate auf GKE-Workern geplant wird. Agent Substrate in der GKE verwaltet seine eigene MicroVM-Laufzeit und erfordert nur die verschachtelte Virtualisierung von Compute Engine auf Standardknoten mit Container-Optimized OS (Image-Typ cos_containerd).

  • Linux-Kernel-sysctl-Einstellungen für eine hohe Sandbox-Dichte konfigurieren: Wenn auf einem Worker-Knoten mehr als etwa 800 gleichzeitige Sandboxes ausgeführt werden, müssen Sie die Linux-Kernel-Limits für das Monitoring des Dateisystems (fs.inotify.*-Parameter) und für die ARP-Nachbartabelle (Address Resolution Protocol) (net.ipv4.neigh.default.gc_thresh*-Parameter) erhöhen. Das Installationsprogramm wendet diese Einstellungen nur auf Cluster an, die es erstellt. Wenn Sie benutzerdefinierte ComputeClasses konfigurieren (mit dem Feld priorityDefaults.nodeSystemConfig.linuxNodeConfig.sysctls) oder Worker-Knotenpools vorab erstellen (mit dem Flag --system-config-from-file), wenden Sie die folgenden sysctl-Werte selbst an:

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

    Weitere Informationen zum Konfigurieren von sysctl-Parametern für Knoten finden Sie unter Sysctl-Konfigurationsoptionen.

Skalierungsmuster für microVM-WorkerPool-Ressourcen auswählen

MicroVM-Worker-Pods fordern die erweiterte Ressource ate.dev/kvm: 1 an, die vom Geräte-Plug-in atelet erst dann beworben wird, wenn ein Knoten gestartet und der Agent atelet gestartet wurde. Da die automatische Knotenbereitstellung von GKE die erweiterte Ressource ate.dev/kvm in nicht bereitgestellten Knotenvorlagen nicht sieht, kann ein ausstehender MicroVM-Worker-Pod GKE nicht dazu veranlassen, automatisch einen neuen Knotenpool mit null Replikaten zu erstellen. Wenn ein Knotenpool jedoch bereits mindestens einen laufenden Knoten hat, kann GKE diesen Knotenpool hochskalieren.

In der folgenden Tabelle werden die unterstützten Muster für die Skalierung von MicroVM-WorkerPool-Ressourcen in GKE verglichen:

Muster Funktionsweise Skalierung auf 0 Knoten? Fallback mit mehreren Prioritäten für die Nichtverfügbarkeit von Ressourcen? Am besten für diese Fälle geeignet
Automatisch erstellte Pools mit dem Feld minimumCapacity Legt die Felder nodePoolAutoCreation.enabled: true und minimumCapacity.targetNodeCount: 1 mit expliziten machineType-Prioritäten fest. Nein (1 warmer Knoten wird weiter ausgeführt) Nur bei der ersten Bereitstellung für das Feld minimumCapacity auf Klassenebene. Für den Fallback während des Bursts muss das Feld minimumCapacity.targetNodeCount: 1 für jeden Fallback-Eintrag im Feld spec.priorities[] festgelegt werden (wobei ein warmer Knoten pro Priorität beibehalten wird). Sie möchten, dass Knotenpools automatisch erstellt werden, und es soll immer mindestens ein Worker-Knoten ausgeführt werden.
Automatisch erstellte Pools mit Kapazitätspuffern Kombiniert das Feld nodePoolAutoCreation.enabled: true mit einem aktiven oder Stand-by-CapacityBuffer, dessen PodTemplate die erweiterte Ressource ate.dev/kvm weglässt. Wird in den Stand-by-Modus versetzt (z. B. etwa 8 % der laufenden Computing-Kosten auf einem c3-standard-4-Knoten mit einem Standard-Bootlaufwerk von 100 GiB) Ja (Pufferplatzhalter lösen bei der automatischen Knotenbereitstellung einen Fallback über Prioritäten hinweg aus) Sie möchten eine schnelle Burst-Skalierung (1 bis 4 Sekunden aktiv oder 20 bis 35 Sekunden, um Standby-Knoten fortzusetzen, und 50 bis 85 Sekunden, bis neue Worker bereit sind) mit niedrigen Kosten für inaktive Ressourcen.
Vorab erstellte Knotenpools mit 0 Knoten und Knotenvorlagenlabels Erstellt automatisch skalierte 0-Knoten-Pools mit dem Label clusterautoscaler-nodetemplate-resources.ate.dev/kvm=4096 vorab und verweist im Feld spec.priorities[].nodepools der ComputeClass auf sie. Ja (tatsächlich 0 Knoten, keine Kosten für inaktive Rechenressourcen) Ja, über die vorab erstellten Knotenpools hinweg Sie möchten echtes Scale-to-Zero ohne Standby-Kapazitätspuffer.

Beispiel: ComputeClass mit dem Feld minimumCapacity

Wenn Sie das Feld minimumCapacity verwenden, muss jeder Eintrag im Feld spec.priorities ein explizites machineType-Feld angeben, anstatt nur das Feld machineFamily anzugeben:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: substrate-microvm
spec:
  priorityDefaults:
    enableNestedVirtualization: true
    nodeSystemConfig:
      linuxNodeConfig:
        sysctls:
          fs.inotify.max_user_instances: 65536
          fs.inotify.max_user_watches: 1048576
          net.ipv4.neigh.default.gc_thresh1: 4096
          net.ipv4.neigh.default.gc_thresh2: 16384
          net.ipv4.neigh.default.gc_thresh3: 32768
  priorities:
  - machineType: n4-standard-4
  - machineType: c3-standard-4
  - machineType: n2-standard-4
  nodePoolAutoCreation:
    enabled: true
  minimumCapacity:
    targetNodeCount: 1
  nodePoolConfig:
    imageType: cos_containerd
  whenUnsatisfiable: DoNotScaleUp

Wenn Sie einen WorkerPool auf diese ComputeClass ausrichten möchten, fügen Sie das Feld nodeSelector: {cloud.google.com/compute-class: substrate-microvm} zur Pod-Vorlage des WorkerPools hinzu.

Wenn eine ComputeClass auf verschiedene x86-Maschinenserien zurückgreift (z. B. von N4 auf C3 oder N2), ist für die Wiederherstellung eines langlebigen Snapshots mit Speichergenauigkeit (Modus SNAPSHOT_FIDELITY_MEMORY) ein Worker erforderlich, dessen CPU-Features eine Obermenge der CPU-Features des Snapshots sind. Wenn kein kompatibler Worker Kapazität hat, stuft Agent Substrate die Wiederherstellung auf die Root-Dateisystem-Genauigkeit (den SNAPSHOT_FIDELITY_ROOTFS-Modus) herab. Dabei werden das Root-Dateisystem und die Daten des langlebigen Volumes beibehalten, während die Prozesse des Actors neu gestartet werden.

Beispiel: Von null skalieren mit vorab erstellten Pools mit 0 Knoten

  1. Speichern Sie die sysctl-Einstellungen des Linux-Kernels mit hoher Dichte als system-config.yaml-Datei:

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

  2. Erstellen Sie Ihre primären und Fallback-Knotenpools für die verschachtelte Virtualisierung mit 0 Knoten vorab. Verwenden Sie dazu das Flag --system-config-from-file=system-config.yaml und das Label clusterautoscaler-nodetemplate-resources.ate.dev/kvm=4096, damit das GKE-Cluster-Autoscaling weiß, dass der leere Pool die erweiterte Ressource ate.dev/kvm bereitstellt:

    # Primary N4 pool (0 nodes)
gcloud container node-pools create microvm-n4-pool \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=n4-standard-4 \
    --enable-nested-virtualization \
    --system-config-from-file=system-config.yaml \
    --num-nodes=0 \
    --enable-autoscaling --total-min-nodes=0 --total-max-nodes=10 \
    --node-labels=cloud.google.com/compute-class=substrate-microvm-zero,clusterautoscaler-nodetemplate-resources.ate.dev/kvm=4096 \
    --node-taints=cloud.google.com/compute-class=substrate-microvm-zero:NoSchedule

# Fallback C3 pool (0 nodes)
gcloud container node-pools create microvm-c3-pool \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=c3-standard-4 \
    --enable-nested-virtualization \
    --system-config-from-file=system-config.yaml \
    --num-nodes=0 \
    --enable-autoscaling --total-min-nodes=0 --total-max-nodes=10 \
    --node-labels=cloud.google.com/compute-class=substrate-microvm-zero,clusterautoscaler-nodetemplate-resources.ate.dev/kvm=4096 \
    --node-taints=cloud.google.com/compute-class=substrate-microvm-zero:NoSchedule

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name Ihres GKE-Standardclusters.
    • LOCATION: die Compute Engine-Zone oder -Region des Clusters. Mit den Flags --total-min-nodes und --total-max-nodes werden die Autoscaling-Grenzen für den gesamten Knotenpool und nicht pro Zone festgelegt.

  3. Verweisen Sie in Ihrer ComputeClass in der Reihenfolge ihrer Priorität auf die vordefinierten Pools:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: substrate-microvm-zero
spec:
  nodePoolAutoCreation:
    enabled: false
  priorities:
  - nodepools:
    - microvm-n4-pool
  - nodepools:
    - microvm-c3-pool
  whenUnsatisfiable: DoNotScaleUp

    Das Feld priorityDefaults gilt nicht für Prioritäten, die das Feld nodepools verwenden, da die Knoteneinstellungen aus den vorab erstellten Knotenpools stammen. Wie bei automatisch erstellten Fallback-Prioritäten wird beim Fortsetzen eines Actors auf einer Fallback-Maschinenserie, deren CPU-Features keine Obermenge der CPU-Features des Snapshots sind, die Wiederherstellung auf den Modus SNAPSHOT_FIDELITY_ROOTFS herabgestuft und die Prozesse des Actors werden neu gestartet.

Weitere Informationen zur ComputeClass-Konfiguration finden Sie unter Automatisch skalierte Knotenattribute mit benutzerdefinierten ComputeClasses steuern.

Kapazitätspuffer für die Burst-Skalierung von WorkerPools konfigurieren

Wenn ein Actor-Traffic-Spitzenwert die Kapazität Ihrer laufenden WorkerPool-Pods überschreitet, müssen neue Worker-Pods auf die Bereitstellung von Compute Engine-Knoten, die Initialisierung des atelet-Agents und das Vorwärmen von Sandbox-Assets warten, bevor sie Actors bedienen können. GKE-Kapazitätspuffer verschieben die Knotenbereitstellung und das Vorwärmen von atelet-Assets aus dem kritischen Pfad:

  • Aktive Kapazitätspuffer (Strategie buffer.x-k8s.io/active-capacity): Vorab bereitgestellte Knoten bleiben aktiv und bereit, sodass neue Worker-Pods in ein bis vier Sekunden geplant werden können. Dabei fallen die vollen Betriebskosten der Compute Engine-VM an.
  • Standby-Kapazitätspuffer (buffer.gke.io/standby-capacity-Strategie): Knoten bereitstellen und den atelet-Agenten Sandbox-Assets (die runsc-Binärdatei oder Cloud Hypervisor- und Kata-Images) während des Standby-Initialisierungsfensters auf dem Laufwerk initialisieren und vorwärmen lassen, bevor GKE die Compute Engine-VMs sperrt. Dieses Zeitfenster ist standardmäßig auf fünf Minuten (5m) festgelegt und wird durch die Annotation buffer.gke.io/standby-capacity-init-time im CapacityBuffer konfiguriert. Erhöhen Sie den Wert dieser Annotation, wenn das Vorwärmen von Assets länger als fünf Minuten dauert. Wenn ein Burst auftritt, setzt GKE die gesperrten Knoten in etwa 20 bis 35 Sekunden fort. Die End-to-End-Bereitschaft des WorkerPools (Planung von Worker-Pods, Ausstellung von Pod-Zertifikaten und Registrierung von Kapazität bei der ate-api-server-Komponente) ist in etwa 50 bis 85 Sekunden abgeschlossen. Während die VM gesperrt ist, zahlen Sie nur für den Speicher der gesperrten VM und den Speicher des Bootlaufwerks. Beispielsweise kostet der gesperrte Speicher etwa 8 % der laufenden Rechenkosten auf einem c3-standard-4-Knoten mit einem standardmäßigen 100-GiB-hyperdisk-balanced-Bootlaufwerk. Der genaue Prozentsatz variiert je nach Maschinenform, Bootlaufwerkgröße und bereitgestellten IOPS oder Durchsatz.

Weitere Informationen zu Pufferstrategien finden Sie unter Strategien zur Reduzierung der Startlatenz.

Einschränkungen und Regeln für Kapazitätspuffer

Wenn Sie Kapazitätspuffer für Agent Substrate in GKE konfigurieren, gelten die folgenden Regeln:

  • Compute Engine-Maschinenform-Einschränkungen für Standby-Puffer: Das Sperren von Compute Engine-Instanzen wird auf VMs mit angehängten lokalen SSDs oder auf Maschinenformen mit mehr als 208 GB Arbeitsspeicher (z. B. der Maschinentyp c3-highmem-88 oder Bare-Metal-Formen) nicht unterstützt. Verwenden Sie für große Worker-Knotenformen oder Knoten mit lokalen SSDs aktive Kapazitätspuffer anstelle von Standby-Puffern.
  • Vermeiden Sie es, das Feld scalableRef auf einen WorkerPool oder ein MicroVM-Deployment mit 0 Replikaten zu verweisen:
    • Der GKE-CapacityBuffer-Controller kann eine benutzerdefinierte Ressource (kind: WorkerPool) nicht auflösen, wenn der Pool auf 0 Replikate skaliert ist.
    • Verweisen Sie bei microVM-WorkerPool-Ressourcen auch nicht mit dem Feld scalableRef auf das zugrunde liegende Deployment, da die Deployment-Pod-Vorlage die erweiterte Ressource ate.dev/kvm: 1 enthält. Dadurch wird verhindert, dass die automatische Knotenbereitstellung einen leeren Pool horizontal skaliert. Konfigurieren Sie stattdessen Puffer, indem Sie im Feld podTemplateRef auf ein PodTemplate verweisen, das die ComputeClass auswählt, ohne die erweiterte Ressource ate.dev/kvm anzufordern.
    • Bei gVisor-WorkerPool-Ressourcen (die die erweiterte Ressource ate.dev/kvm nicht anfordern) können Sie das Feld scalableRef direkt auf das zugrunde liegende Deployment des WorkerPools verweisen oder ein PodTemplate verwenden.

Beispiel: Standby-CapacityBuffer mit einem PodTemplate

Das folgende Manifest definiert ein PodTemplate und einen Standby-CapacityBuffer, die entweder für MicroVM- oder gVisor-WorkerPool-Ressourcen funktionieren:

apiVersion: v1
kind: PodTemplate
metadata:
  name: substrate-worker-buffer-template
  namespace: WORKERPOOL_NAMESPACE
template:
  spec:
    nodeSelector:
      cloud.google.com/compute-class: COMPUTE_CLASS_NAME
    containers:
    - name: buffer-placeholder
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: "WORKER_CPU_REQUEST"
          memory: "WORKER_MEMORY_REQUEST"
---
apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: substrate-standby-buffer
  namespace: WORKERPOOL_NAMESPACE
spec:
  podTemplateRef:
    name: substrate-worker-buffer-template
  replicas: BUFFER_REPLICAS
  provisioningStrategy: buffer.gke.io/standby-capacity

Ersetzen Sie Folgendes:

  • WORKERPOOL_NAMESPACE: Der Kubernetes-Namespace Ihres WorkerPools (z. B. my-workerpool).
  • COMPUTE_CLASS_NAME: der Name der benutzerdefinierten ComputeClass, auf die Ihr WorkerPool abzielt (z. B. substrate-microvm).
  • WORKER_CPU_REQUEST und WORKER_MEMORY_REQUEST: die CPU- und Arbeitsspeicheranforderungen eines einzelnen Worker-Pods in Ihrem WorkerPool (z. B. 2 CPUs und 4Gi Arbeitsspeicher auf einem Knoten mit 4 vCPUs), wobei Knotenkapazität für den atelet-Agent und GKE-Systemdaemons übrig bleibt. Wenn Sie diese Werte mit den Anfragen eines Worker-Pods abgleichen, wird dafür gesorgt, dass jedes Pufferreplikat einen Standby-Worker-Knoten bereitstellt, anstatt mehrere Pufferplatzhalter auf einem einzelnen Knoten zu packen.
  • BUFFER_REPLICAS: die Anzahl der Standby-Worker-Knoten, die vorgewärmt bleiben sollen (z. B. 4 Knoten).

Wenn Sie Stand-by-Kapazitätspuffer verwenden, fügen Sie dem atelet-DaemonSet eine Toleranz für die Markierung buffer.gke.io/standby-capacity-node-suspended (mit dem Feld operator: "Exists") hinzu, damit Ersatz-atelet-Pods auf gesperrten Stand-by-Knoten geplant bleiben können (z. B. während eines rollierenden Updates des DaemonSets). Ein Beispiel für eine DaemonSet-Konfiguration finden Sie unter Images in Standby-Zwischenspeichern vorab laden.

Wenn mehrere Arbeitslasten dieselbe ComputeClass verwenden, fügen Sie sowohl der WorkerPool-Pod-Vorlage als auch der Puffer-PodTemplate entsprechende Toleranzen für die Arbeitslasttrennung und nodeSelector-Labels hinzu, damit GKE dedizierte markierte Knoten bereitstellt, die nicht von anderen Arbeitslasten beansprucht werden. Fügen Sie dem DaemonSet atelet außerdem eine entsprechende Toleranz hinzu, damit der atelet-Agent auf diesen dedizierten Knoten geplant werden kann. Eine detaillierte Anleitung finden Sie unter Kapazitätspuffer konfigurieren.

Upgrades und Autoscaling-Interaktionen verwalten

In diesem Abschnitt wird beschrieben, wie Sie atelet-DaemonSet-Updates, Ereignisse zum Herunterskalieren von Cluster Autoscaler und Knotenupgrades verwalten, ohne aktive Akteure zu unterbrechen.

DaemonSet atelet mit Standby-Zwischenspeichern aktualisieren

Gesperrte Standby-Pufferknoten haben die Markierung buffer.gke.io/standby-capacity-node-suspended und eine Markierung für nicht erreichbar, während sie gesperrt sind. Daher kann der kubelet-Agent auf einem gesperrten Knoten das Löschen von Pods nicht bestätigen. Achten Sie darauf, dass das DaemonSet atelet die Markierung buffer.gke.io/standby-capacity-node-suspended (mit dem Feld operator: "Exists") toleriert. Auch mit dieser Toleranz wechseln Pods auf gesperrten Knoten während eines standardmäßigen Rolling Updates des atelet-DaemonSets (mit dem Feld maxUnavailable: 1) in den Status Terminating und können das Update auf laufenden Knoten blockieren.

Bevor Sie das atelet-DaemonSet auf einem Cluster mit gesperrten Stand-by-Knoten aktualisieren, führen Sie einen der folgenden Schritte aus:

  • Damit nicht erreichbare Stand-by-Knoten das Update-Budget nicht erschöpfen, legen Sie das Feld spec.updateStrategy.rollingUpdate.maxUnavailable im DaemonSet atelet auf einen Wert fest, der größer ist als die maximale Anzahl der gesperrten Stand-by-Knoten.

  • Bevor Sie das DaemonSet atelet aktualisieren, skalieren Sie Ihre Standby-CapacityBuffer-Replikate vorübergehend auf 0 und warten Sie, bis der Cluster-Autoscaler alle ausgesetzten Standby-Pufferknoten entfernt hat (normalerweise 10 bis 15 Minuten). Führen Sie den folgenden Befehl aus, um zu prüfen, ob Knoten noch den Status True für die Bedingung Suspended melden:

    kubectl get nodes -o custom-columns='NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status'

Aktive Akteure beim Herunterskalieren und bei Upgrades schützen

Da aktive Akteure in Sandboxes ausgeführt werden, die vom atelet-Agent verwaltet werden, und nicht als einzelne Kubernetes-Pods, können die CPU- und Speicheranforderungen eines Knotens für den GKE-Cluster-Autoscaler niedrig erscheinen, selbst wenn ein Worker-Pod auf diesem Knoten aktive Akteure hostet. Wenn ein Knoten geleert wird, sendet der kubelet-Agent ein SIGTERM-Signal an den Worker-Pod und der Worker leitet das SIGTERM-Signal an den Hauptprozess jedes Containers jedes von ihm gehosteten Actors weiter. Jeder aktive Actor hat dann bis zu 30 Minuten Zeit, um gesperrt zu werden, bevor der Worker beendet wird. Geben Sie jedem zustandsorientierten Actor einen SIGTERM-Handler, der das Signal nicht beendet und die Methode SuspendActor mit dem Modus DURABILITY_MODE_SYNCHRONOUS aufruft. Ein Actor, dessen Hauptprozess beim Signal SIGTERM beendet wird, verliert sofort den nicht gespeicherten Status. Wenn der Worker-Pod beendet wird, während er noch einen aktiven Actor hostet, wechselt der Actor in den Status ACTOR_STATE_CRASHED.

Wenden Sie die folgenden Best Practices an, um Unterbrechungen bei Herunterskalierungsereignissen und GKE-Clusterupgrades zu minimieren:

  • Vermeiden Sie die Verwendung von Spot-VMs für zustandsorientierte WorkerPool-Knoten, da die vorzeitige Beendigung von Spot-VM nur 15 Sekunden bis 2 Minuten vor dem Beenden des Knotens angekündigt wird.
  • Koordinieren Sie das Entleeren in Ihrem Orchestrator, damit aktive Akteure vor dem Beenden von Worker-Pods Prüfpunkte erhalten und gesperrt werden, oder verhindern Sie, dass der Cluster-Autoscaler aktive Worker-Pods entfernt (z. B. mithilfe der Pod-Annotation cluster-autoscaler.kubernetes.io/safe-to-evict: "false"). Wenn Sie die Annotation safe-to-evict: "false" statisch in der WorkerPool-Pod-Vorlage festlegen, skaliert der Cluster-Autoscaler einen Knoten nicht herunter, während ein Worker-Pod darauf geplant ist – selbst wenn dieser Worker keine aktiven Akteure hostet. Wenn Sie inaktive Knoten freigeben möchten, müssen Sie die WorkerPool-Replikate herunterskalieren oder die Annotation dynamisch verwalten. Weitere Informationen zum Lebenszyklus der Worker-Entfernung und zum Wiederherstellen abgestürzter Akteure mit der Methode RevertActor finden Sie im API-Leitfaden für Agent Substrate im Abschnitt „Entfernung“.
  • Konfigurieren Sie GKE-Surge-Upgrades und lesen Sie den Abschnitt Upgrade in einer Umgebung mit eingeschränkten Ressourcen, damit neue Worker-Knoten bereitgestellt werden, bevor vorhandene Worker-Knoten gesperrt und geleert werden.

Nächste Schritte