Mendesain infrastruktur untuk Agent Substrate di GKE

Dengan Google Kubernetes Engine (GKE), Anda dapat menskalakan cluster Agent Substrate di GKE untuk mendukung workload agentic AI dengan konkurensi tinggi sekaligus meminimalkan biaya komputasi yang tidak digunakan. Dengan menggabungkan node pool infrastruktur sistem khusus dengan ComputeClass kustom dan buffering kapasitas, Anda dapat mengisolasi komponen sistem penting, mengotomatiskan penggantian hardware di seluruh seri mesin Compute Engine, dan menjaga kapasitas Worker standby tetap hangat.

Baca dokumen ini untuk menyesuaikan ukuran komponen cluster GKE, mengisolasi infrastruktur sistem dan node pool database, mengonfigurasi penyediaan node otomatis untuk resource WorkerPool, serta merencanakan pemeliharaan dan upgrade cluster. Dokumen ini ditujukan untuk administrator platform yang menyediakan dan mengelola Agent Substrate di infrastruktur GKE.

Sebelum memulai

Sebelum mengonfigurasi infrastruktur cluster untuk penskalaan, pastikan lingkungan Anda memenuhi persyaratan berikut:

  • Mode dan versi cluster GKE: Anda harus menggunakan cluster GKE Standard yang menjalankan versi 1.37 atau yang lebih baru pada bidang kontrol dan node pool. Cluster GKE Autopilot tidak didukung untuk Agent Substrate di GKE.
  • Penginstalan Agent Substrate di GKE: Anda harus memiliki penginstalan Agent Substrate di GKE yang sudah ada atau berencana menginstal Agent Substrate di GKE dengan isolasi node infrastruktur sistem diaktifkan. Untuk mengetahui langkah-langkah penginstalan, lihat Menginstal Agent Substrate di GKE.

Menyesuaikan ukuran cluster Agent Substrate Anda

Tentukan ukuran cluster Anda untuk konkurensi puncak dan tingkat kelanjutan puncak, bukan rata-rata. Worker node harus menampung jumlah maksimum Actor yang berjalan pada saat yang sama, dan komponen infrastruktur sistem serta jalur penyimpanan harus mengikuti kecepatan tercepat Actor melanjutkan dan menangguhkan.

Memperkirakan puncak workload Anda

Jika Anda tidak memiliki pengukuran produksi, perkirakan puncak penayangan serentak dan rasio melanjutkan dari total jumlah Actor yang terdaftar (total_actors), pecahan rata-rata Actor yang berjalan secara serentak (average_active_fraction), pengganda lonjakan traffic (burst_factor), dan durasi rata-rata Actor tetap aktif per giliran (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

Misalnya, jika Anda memiliki total 100.000 Actor dengan rata-rata 10% aktif (10.000 Actor) dan faktor burst dua, cluster Anda harus mendukung 20.000 Actor yang berjalan puncak. Jika setiap Actor berjalan rata-rata selama 100 detik sebelum ditangguhkan, mempertahankan puncak tersebut memerlukan 200 resume per detik dan 200 penangguhan per detik.

Agent Substrate di GKE tidak menangguhkan Actor yang tidak ada aktivitas secara otomatis; aplikasi atau orchestrator Anda harus memicu penangguhan.

Menentukan ukuran bidang data

Bagian ini membahas praktik terbaik untuk mengukur bidang data, termasuk Pod Worker, node GKE, bandwidth snapshot, dan agen node atelet.

Menghitung Pod Worker dan node GKE

Setiap Pod Worker di WorkerPool menghosting beberapa Actor. Worker dapat menerima Actor baru saat menghosting lebih sedikit Actor daripada batas yang ditetapkan oleh flag --max-actors pada container ateworker (default 1000) dan memiliki sisa kapasitas CPU dan memori yang cukup untuk memenuhi batas ActorTemplate. Untuk mengetahui informasi selengkapnya tentang cara batas Worker berinteraksi dengan batas Actor, lihat panduan Menyesuaikan ukuran resource di Agent Substrate API open source.

Hitung jumlah Pod Worker yang diperlukan dengan kapasitas penjadwalan yang tersedia sebesar 20% (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)

Dalam formula ini, variabel max_actors ditetapkan secara default ke 1000 (dikonfigurasi oleh flag --max-actors). Kurangi memori yang dicadangkan Worker untuk prosesnya sendiri dari nilai worker_memory. Untuk resource WorkerPool microVM, tambahkan overhead memori monitor virtual machine (VMM) per Aktor yang dilaporkan oleh Worker ke nilai actor_memory, karena penempatan memperhitungkan overhead tersebut terhadap kapasitas Worker.

Dengan satu Pod Worker per node, jumlah Worker sama dengan jumlah worker node GKE. Jangan alokasikan 100% CPU dan memori yang dapat dialokasikan node ke Pod Worker; sisakan kapasitas di setiap node untuk DaemonSet atelet (di namespace ate-system) dan daemon sistem GKE. GKE Standard mendukung hingga 65.000 node per cluster dan hingga 512 Pod per node. Maksimum defaultnya adalah 110 Pod per node (dapat dikonfigurasi dengan flag --max-pods-per-node), dan cluster besar memiliki persyaratan tambahan.

Menentukan ukuran bandwidth snapshot dan disk node

Setiap penangguhan Actor menulis snapshot ke disk node lokal di jalur direktori /var/lib/ate. Dalam mode SYNCHRONOUS, agen atelet mengupload snapshot ke Cloud Storage sebelum operasi penangguhan ditampilkan. Dalam mode ASYNCHRONOUS, agen atelet menjadwalkan upload ke Cloud Storage setelah penundaan sekitar nilai flag --snapshot-upload-delay (default 5m) dari saat snapshot diambil. Agent Substrate meng-cache snapshot terbaru pada node selama periode yang dikonfigurasi dalam flag --snapshot-detach-delay, yang secara default memiliki nilai 30m. Actor yang dilanjutkan dalam periode tersebut akan dijadwalkan ke node yang sama dan dipulihkan dari disk lokal, bukan mendownload snapshot dari Cloud Storage.

Perkirakan ukuran snapshot yang tidak dikompresi (snapshot_size) sebagai batas memori ActorTemplate ditambah data apa pun yang ditulis ke sistem file root yang dapat ditulis atau direktori yang tahan lama. Penanganan file sparse dan kompresi zstd mengurangi ukuran snapshot terkompresi (compressed_snapshot_size) yang ditransfer ke dan dari Cloud Storage, tempat Agent Substrate menyimpan hingga dua snapshot per Actor (snapshot sebelumnya dan snapshot yang sedang berlangsung):

  • Bandwidth Cloud Storage puncak (setiap arah): peak_resume_rate × compressed_snapshot_size
  • Throughput tulis disk node puncak per node: 2 × peak_resume_rate × snapshot_size / total_nodes (download resume dan checkpoint penangguhan menulis ke disk node).

Boot disk hyperdisk-balanced 100 GiB default di GKE menyediakan 3.600 IOPS dan throughput 290 MiB/dtk (performa default diskalakan dengan ukuran disk), yang dapat membatasi operasi snapshot di bawah I/O tamu yang berat. Saat Anda membuat worker node pool, pasang disk khusus di jalur direktori /var/lib/ate/snapshots atau tingkatkan performa boot disk menggunakan flag --boot-disk-provisioned-iops dan --boot-disk-provisioned-throughput dengan perintah gcloud container node-pools create.

Memeriksa kuota Security Token Service

Setiap transfer snapshot ke atau dari Cloud Storage memerlukan token yang dicakupkan ke Actor, yang diminta oleh komponen ate-api-server dari Security Token Service (STS) API. Komponen ate-api-server membuat hingga satu permintaan STS per Actor setiap 20 hingga 40 menit (biasanya pada resume pertama di jendela tersebut) dan menggunakan kembali token hingga 20 menit sebelum masa berlaku berakhir.

Kuota Exchange token global requests STS ditetapkan secara default ke 6.000 permintaan per project per menit dan digunakan bersama dengan Workload Identity Federation for GKE:

  • Kuota STS yang diperlukan (permintaan per menit): perkirakan hingga 60 kali tingkat puncak melanjutkan untuk Actor yang transfer snapshot terakhirnya lebih dari 20 menit yang lalu, ditambah kapasitas untuk Workload Identity Federation for GKE. Jika Anda tidak mengetahui tarif tersebut, gunakan formula 60 × peak_resume_rate sebagai pengganti. Misalnya, 200 resume per detik memerlukan hingga 12.000 permintaan per menit.
  • Cara meningkatkan kuota: minta penambahan kuota di halaman Quotas & System Limits di konsol Google Cloud . Transfer snapshot berfungsi tanpa mengaktifkan Security Token Service API di project Anda, tetapi Anda harus mengaktifkan API agar kuota muncul di halaman Quotas & System Limits. Untuk mengetahui informasi selengkapnya, lihat Kuota untuk Exchange Token API di Security Token Service dalam dokumentasi Workload Identity Federation for GKE.

Menyesuaikan agen node atelet

DaemonSet atelet menjalankan satu Pod per worker node untuk memulihkan dan membuat checkpoint Actor. Di setiap Pod atelet, container objectstore-plugin mengompresi dan mentransfer snapshot ke dan dari Cloud Storage.

Tabel berikut menjelaskan setelan ukuran kunci untuk container atelet dan objectstore-plugin:

Setelan Default Panduan ukuran
CPU dan memori container atelet dan objectstore-plugin Permintaan: 50 mCPU, memori 128 MiB; tanpa batas Konfigurasikan QoS Burstable tanpa batas memori dengan menghilangkan batas memori pada kedua container, karena mencapai batas memori akan menghentikan agen node dan menghentikan semua proses melanjutkan di node. Tingkatkan permintaan CPU dan memori agar sesuai dengan penggunaan puncak yang diukur pada node penuh pada tingkat resume puncak Anda, sehingga Pod Worker tidak menggunakan resource yang diperlukan oleh agen atelet.
Flag --upload-memory-budget (container objectstore-plugin) dan flag --snapshot-upload-workers (container atelet) Anggaran 512 MiB; 2 worker upload

Untuk mencegah upload snapshot serentak mengantre di node multi-Actor dengan tingkat penangguhan tinggi, lakukan hal berikut:

  • Tingkatkan nilai flag --upload-memory-budget (dan tetapkan permintaan memori container objectstore-plugin lebih tinggi dari anggaran ini).
  • Tingkatkan nilai flag --snapshot-upload-workers.
Flag --drain-timeout dan kolom terminationGracePeriodSeconds 5 menit (flag --drain-timeout); 330 detik (kolom terminationGracePeriodSeconds) Mengontrol berapa lama agen atelet menyelesaikan pemulihan dalam proses dan upload snapshot saat Pod-nya berhenti selama pengosongan atau upgrade node. Jika Anda meningkatkan nilai flag --drain-timeout untuk snapshot besar, tingkatkan juga nilai kolom terminationGracePeriodSeconds pada DaemonSet atelet agar agen kubelet tidak menghentikan agen atelet sebelum upload selesai.

Menentukan ukuran komponen infrastruktur sistem dan database

Untuk Deployment komponen sistem stateless di namespace ate-system yang diskalakan secara horizontal, perkirakan jumlah replika yang diperlukan dengan kapasitas yang tersedia sebesar 35% (faktor 0.65) ditambah satu replika cadangan (+ 1) untuk menoleransi gangguan node:

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

Penskalaan horizontal berhenti meningkatkan throughput setelah dependensi bersama (seperti CPU PostgreSQL atau batas koneksi) mencapai kapasitas. Tentukan ukuran komponen infrastruktur sistem dan database Anda secara bersamaan. Untuk mengetahui informasi selengkapnya tentang flag komponen, lihat panduan penginstalan operator open source.

Tabel berikut menjelaskan aturan resource dan penskalaan untuk setiap komponen infrastruktur sistem:

Komponen Aturan QoS dan resource Penskalaan dan penyesuaian koneksi
Router ingress (atenet-router) Konfigurasi QoS Guaranteed: tetapkan permintaan dan batas CPU serta memori yang cocok agar runtime Go menyelaraskan jumlah thread-nya dengan anggaran CPU container. Skalakan replika secara horizontal berdasarkan permintaan ingress puncak per detik, overhead mTLS, dan ukuran payload permintaan.
Server API (ate-api-server) Konfigurasi QoS Guaranteed: tetapkan permintaan dan batas CPU serta memori yang cocok agar runtime Go menyelaraskan jumlah thread-nya dengan anggaran CPU container. Skalakan replika berdasarkan siklus lanjutkan dan tunda puncak per detik (sekitar 4 md CPU per siklus lanjutkan dan tunda) dan beban pencarian permintaan masuk. Tetapkan setelan ateapi.postgres.poolMaxConns secara eksplisit. Setiap replika membuka hingga poolMaxConns + 6 koneksi database, dan jumlah di semua replika harus tetap kurang dari setelan max_connections PostgreSQL.
Database (PostgreSQL) Konfigurasikan QoS Burstable dengan memori yang dijamin: tetapkan permintaan memori yang sama dengan batas untuk mengunci cache shared_buffers dalam memori dan membantu mencegah pengeluaran karena kehabisan memori (OOM). Hilangkan batas CPU saat berjalan di node ate-postgres khusus sehingga throttling CPU kernel tidak memperlambat burst checkpoint dan autovacuum. Menskalakan StatefulSet instance tunggal ini secara vertikal. Sediakan CPU yang cukup untuk mempertahankan pemakaian kurang dari 80% pada beban puncak, RAM yang cukup untuk meng-cache tabel Actor (dengan parameter shared_buffers ditetapkan ke sekitar 25% memori), dan StorageClass yang didukung SSD yang ditetapkan pada waktu penginstalan dengan setelan ateapi.postgres.storageClass (misalnya, StorageClass dynamic-rwo di C4 atau N4, atau StorageClass premium-rwo di C3 atau N2). Tingkatkan parameter max_connections di ConfigMap postgres-config (file postgresql.conf) agar sesuai dengan semua replika ate-api-server.
Proxy egress (atenet-egress) Aturan resource: tetapkan permintaan CPU sebesar 512 mCPU (batas 8 vCPU) dan permintaan memori sebesar 512 MiB (batas 1 GiB). Tingkatkan permintaan dan batas jika traffic Actor keluar mengalami peningkatan latensi. Menskalakan replika secara horizontal berdasarkan traffic permintaan keluar Actor.
Worker controller (ate-controller) Aturan resource: pertahankan pada satu replika (tidak ada pemilihan pemimpin). Tetapkan permintaan CPU dan memori berdasarkan penggunaan puncak selama peristiwa penyebaran skala WorkerPool yang besar. Jika Pod Worker baru memerlukan waktu terlalu lama untuk mendaftar di fleet besar, tingkatkan nilai flag --worker-sync-concurrency (default 2).
Pengontrol sertifikat (podcertificate-controller) Aturan resource: berjalan di namespace podcertificate-controller-system untuk menandatangani sertifikat mTLS bagi Pod Worker baru sebelum dapat menerima Actor. Untuk fleet yang berisi ribuan Worker, tingkatkan nilai setelan podcert.workersPerSigner (default 0, yang mempertahankan default manifes 1 worker per penanda tangan), flag --kube-api-qps (default 5), dan flag --kube-api-burst (default 10).
Penyedia identitas (ate-idp-server) Aturan resource: menyajikan dokumen discovery OpenID Connect (OIDC) dan JSON Web Key Set (JWKS) di namespace ate-system untuk memverifikasi JSON Web Token (JWT) Aktor. Tetapkan permintaan CPU dan memori berdasarkan volume kueri JWKS puncak. Skalakan replika secara horizontal jika pihak tepercaya mengkueri endpoint JWKS dengan rasio permintaan tinggi tanpa kunci caching.
Penyedia kredensial (k8s-credential-provider) Aturan resource: berjalan di namespace ate-system saat injeksi kredensial Secret Kubernetes diaktifkan. Tetapkan permintaan CPU dan memori berdasarkan volume injeksi kredensial keluar. Menskalakan replika secara horizontal berdasarkan tingkat permintaan Actor keluar yang memerlukan injeksi kredensial Secret Kubernetes di proxy atenet-egress.

Mengisolasi infrastruktur sistem dan node pool worker

Dalam cluster produksi, penjadwalan Actor dengan churn tinggi dan traffic snapshot pada worker node dapat bersaing dengan komponen infrastruktur sistem untuk CPU, memori, dan I/O disk. Pisahkan cluster GKE Anda menjadi tiga tingkat node pool yang berbeda:

  • Node pool database (label ate-postgres): node pool khusus untuk StatefulSet PostgreSQL, yang menyimpan semua metadata Actor dan Worker.
  • Node pool infrastruktur sistem (label ate-system-infra): node pool khusus untuk layanan infrastruktur sistem yang tersisa (komponen atenet-router, ate-api-server, atenet-egress, ate-controller, ate-idp-server, dan k8s-credential-provider).
  • Worker node pool (WorkerPool): node pool yang diskalakan secara dinamis yang dikelola oleh ComputeClass kustom GKE dan buffering kapasitas GKE untuk menghosting sandbox Actor yang aktif.

Anda dapat mengisolasi komponen infrastruktur database dan sistem ke node khusus saat menginstal Agent Substrate di GKE menggunakan setelan cordonSystemInfraComponents (atau flag --cordon-system-infra-components). Sebelum menginstal, Anda harus membuat kedua node pool dengan label yang diperlukan dan taint NoSchedule:

# 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

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster GKE Standard Anda.
  • LOCATION: zona atau region Compute Engine bidang kontrol cluster Anda.
  • POSTGRES_ZONE: satu zona Compute Engine untuk StatefulSet PostgreSQL replika tunggal. Untuk cluster regional, tentukan satu zona dalam region cluster sehingga node pool menyediakan satu node di zona tempat persistent disk StatefulSet akan dibuat. Untuk cluster zona, tentukan zona cluster.
  • POSTGRES_MACHINE_TYPE: jenis mesin Compute Engine yang disesuaikan untuk instance PostgreSQL Anda.
  • SYSTEM_INFRA_MACHINE_TYPE: jenis mesin Compute Engine yang ukurannya disesuaikan untuk komponen infrastruktur sistem Anda (misalnya, jenis mesin c3-standard-8).

Dalam cluster regional, flag --num-nodes berlaku per zona (misalnya, menetapkan flag --num-nodes=2 di tiga zona akan membuat total enam node). Untuk menempatkan node pool ate-system-infra-pool di zona tertentu, tambahkan flag --node-locations.

Jika Anda mengaktifkan setelan cordonSystemInfraComponents selama penginstalan dan salah satu node pool tidak ada, Pod sistem yang sesuai akan tetap dalam status Pending.

Mengotomatiskan penargetan hardware menggunakan ComputeClass kustom

ComputeClass kustom GKE memungkinkan Anda menentukan daftar prioritas seri mesin Compute Engine untuk node WorkerPool dan otomatis beralih ke seri mesin sekunder jika zona mengalami ketidaktersediaan resource.

Memilih seri mesin Compute Engine berdasarkan runtime

Konfigurasikan ComputeClass terpisah untuk setiap runtime sandbox:

  • Runtime MicroVM (Cloud Hypervisor): tetapkan kolom enableNestedVirtualization: true di prioritas ComputeClass Anda dan targetkan seri mesin Compute Engine x86 yang mendukung virtualisasi bertingkat (seperti N4, C3, C4, atau N2), atau gunakan jenis mesin bare-metal x86, yang menjalankan KVM secara native dan tidak memerlukan kolom enableNestedVirtualization. VM berbasis Arm dan seri mesin yang tercantum dalam Batasan virtualisasi bertingkat tidak didukung.
  • Runtime gVisor: menargetkan seri mesin Compute Engine x86 tujuan umum atau yang dioptimalkan untuk komputasi (seperti N4, C3, C4, atau N2) tanpa mengaktifkan virtualisasi bertingkat. Seri mesin yang berjalan pada mikroarsitektur CPU campuran (seperti E2) dan VM berbasis Arm tidak didukung untuk Agent Substrate di GKE. Semua resource WorkerPool yang dipilih ActorTemplate harus memiliki arsitektur CPU yang sama.

Untuk perbandingan mendetail, lihat Memilih runtime sandbox.

Aturan ComputeClass yang diperlukan untuk Agent Substrate

Saat Anda membuat ComputeClass untuk Agent Substrate di worker node GKE, ikuti aturan berikut:

  • Gunakan ComputeClass berbasis node: jangan gunakan penagihan berbasis Pod (kolom podFamily), yang tidak mendukung virtualisasi bertingkat.
  • Jangan tetapkan kolom nodePoolConfig.sandbox.type: microvm: setelan tersebut mengaktifkan runtime Kata untuk GKE Sandbox pada workload berbasis Pod dan menerapkan taint sandbox.gke.io/runtime=microvm yang mencegah Agent Substrate di GKE Worker menjadwalkan. Agent Substrate di GKE mengelola runtime microVM-nya sendiri dan hanya memerlukan virtualisasi bertingkat Compute Engine pada node Container-Optimized OS standar (jenis image cos_containerd).

  • Konfigurasikan setelan sysctl kernel Linux untuk kepadatan sandbox yang tinggi: jika worker node menjalankan lebih dari sekitar 800 sandbox serentak, Anda harus meningkatkan batas kernel Linux untuk pemantauan sistem file (parameter fs.inotify.*) dan untuk tabel tetangga Address Resolution Protocol (ARP) (parameter net.ipv4.neigh.default.gc_thresh*). Penginstal menerapkan setelan ini hanya ke cluster yang dibuatnya. Saat Anda mengonfigurasi ComputeClass kustom (menggunakan kolom priorityDefaults.nodeSystemConfig.linuxNodeConfig.sysctls) atau membuat node pool worker terlebih dahulu (menggunakan flag --system-config-from-file), terapkan sendiri nilai sysctl berikut:

    • 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

    Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi parameter sysctl node, lihat Opsi konfigurasi Sysctl.

Memilih pola peningkatan skala untuk resource WorkerPool microVM

Pod Pekerja MicroVM meminta resource yang diperluas ate.dev/kvm: 1, yang diberitahukan oleh plugin perangkat atelet hanya setelah node melakukan booting dan agen atelet dimulai. Karena penyediaan otomatis node GKE tidak melihat resource yang diperluas ate.dev/kvm pada template node yang tidak disediakan, Pod Worker microVM yang tertunda tidak dapat memicu GKE untuk membuat node pool baru secara otomatis dari nol replika dengan sendirinya. Namun, jika node pool sudah memiliki setidaknya satu node yang berjalan, GKE dapat meningkatkan skala node pool tersebut.

Tabel berikut membandingkan pola yang didukung untuk menskalakan resource WorkerPool microVM di GKE:

Pola Cara kerjanya Menskalakan ke 0 node? Fallback multiprioritas untuk ketidaktersediaan resource? Waktu penggunaan terbaik
Pool yang dibuat otomatis dengan kolom minimumCapacity Menetapkan kolom nodePoolAutoCreation.enabled: true dan minimumCapacity.targetNodeCount: 1 dengan prioritas machineType eksplisit. Tidak (mempertahankan 1 node warm tetap berjalan) Hanya pada penyediaan awal untuk kolom minimumCapacity tingkat class; penggantian mid-burst memerlukan penetapan kolom minimumCapacity.targetNodeCount: 1 pada setiap entri penggantian di kolom spec.priorities[] (mempertahankan 1 node hangat per prioritas) Anda menginginkan pembuatan node pool otomatis dan selalu mempertahankan setidaknya 1 worker node yang berjalan.
Pool yang dibuat otomatis dengan buffering kapasitas Menggabungkan kolom nodePoolAutoCreation.enabled: true dengan CapacityBuffer aktif atau standby yang PodTemplate-nya menghilangkan resource yang diperluas ate.dev/kvm. Menangguhkan ke standby (misalnya, sekitar 8% dari biaya komputasi yang berjalan pada node c3-standard-4 dengan boot disk default 100 GiB) Ya (placeholder buffer memicu penggantian node auto-provisioning di seluruh prioritas) Anda menginginkan penskalaan burst yang cepat (aktif 1 hingga 4 detik, atau 20 hingga 35 detik untuk melanjutkan node standby dan 50 hingga 85 detik hingga Worker baru siap) dengan biaya tidak ada aktivitas yang rendah.
Node pool 0 yang telah dibuat sebelumnya dengan label node-template Membuat node pool 0 yang diskalakan otomatis dengan label clusterautoscaler-nodetemplate-resources.ate.dev/kvm=4096 dan mereferensikannya di kolom spec.priorities[].nodepools ComputeClass. Ya (benar-benar 0 node, tanpa biaya komputasi tidak ada aktivitas) Ya, di seluruh node pool yang telah dibuat sebelumnya Anda menginginkan penskalaan hingga nol yang sebenarnya tanpa mempertahankan buffering kapasitas standby.

Contoh: ComputeClass dengan kolom minimumCapacity

Saat Anda menggunakan kolom minimumCapacity, setiap entri di kolom spec.priorities harus menentukan kolom machineType eksplisit, bukan hanya menentukan kolom machineFamily:

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

Untuk menargetkan WorkerPool ke ComputeClass ini, tambahkan kolom nodeSelector: {cloud.google.com/compute-class: substrate-microvm} ke template Pod WorkerPool.

Saat ComputeClass beralih ke berbagai seri mesin x86 (seperti dari N4 ke C3 atau N2), memulihkan snapshot tahan lama pada fidelitas memori (mode SNAPSHOT_FIDELITY_MEMORY) memerlukan Worker yang fitur CPU-nya merupakan superset dari fitur CPU snapshot. Jika tidak ada Worker yang kompatibel yang memiliki kapasitas, Agent Substrate akan menurunkan kualitas pemulihan ke fidelitas sistem file root (mode SNAPSHOT_FIDELITY_ROOTFS), yang mempertahankan sistem file root dan data volume yang tahan lama saat memulai ulang proses Actor.

Contoh: Menskalakan dari nol dengan node pool 0 yang telah dibuat sebelumnya

  1. Simpan setelan sysctl kernel Linux kepadatan tinggi sebagai file system-config.yaml:

    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. Buat terlebih dahulu node pool virtualisasi bertingkat utama dan pengganti di 0 node dengan flag --system-config-from-file=system-config.yaml dan label clusterautoscaler-nodetemplate-resources.ate.dev/kvm=4096 sehingga autoscaler cluster GKE mengetahui bahwa pool kosong menyediakan resource yang diperluas ate.dev/kvm:

    # 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

    Ganti kode berikut:

    • CLUSTER_NAME: nama cluster GKE Standard Anda.
    • LOCATION: zona atau region Compute Engine cluster Anda. Menggunakan flag --total-min-nodes dan --total-max-nodes akan menetapkan batas penskalaan otomatis di seluruh node pool, bukan per zona.

  3. Referensi pool yang telah dibuat sebelumnya dalam urutan prioritas di ComputeClass Anda:

    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

    Kolom priorityDefaults tidak berlaku untuk prioritas yang menggunakan kolom nodepools, karena setelan node berasal dari node pool yang telah dibuat sebelumnya. Seperti prioritas penggantian yang dibuat otomatis, melanjutkan Actor pada seri mesin penggantian yang fitur CPU-nya bukan superset dari fitur CPU snapshot akan menurunkan versi pemulihan ke mode SNAPSHOT_FIDELITY_ROOTFS dan memulai ulang proses Actor.

Untuk mengetahui informasi selengkapnya tentang konfigurasi ComputeClass, lihat Mengontrol atribut node yang diskalakan otomatis dengan ComputeClass kustom.

Mengonfigurasi buffering kapasitas untuk penskalaan burst WorkerPool

Saat lonjakan traffic Actor melebihi kapasitas Pod WorkerPool yang sedang berjalan, Pod Worker baru harus menunggu penyediaan node Compute Engine, inisialisasi agen atelet, dan pra-pemanasan aset sandbox sebelum dapat menyajikan Actor. Buffering kapasitas GKE memindahkan penyediaan node dan pra-pemanasan aset atelet dari jalur kritis:

  • Buffering kapasitas aktif (strategi buffer.x-k8s.io/active-capacity): menjaga node yang telah disediakan sebelumnya tetap berjalan dan siap sehingga Pod Worker baru dijadwalkan dalam satu hingga empat detik, dengan biaya pengoperasian penuh VM Compute Engine.
  • Buffer kapasitas standby (strategi buffer.gke.io/standby-capacity): menyediakan node dan mengizinkan agen atelet melakukan inisialisasi dan melakukan pra-pemanasan aset sandbox (biner runsc atau Cloud Hypervisor dan image Kata) di disk selama jendela inisialisasi standby sebelum GKE menangguhkan VM Compute Engine. Periode ini ditetapkan secara default ke lima menit (5m) dan dikonfigurasi oleh anotasi buffer.gke.io/standby-capacity-init-time di CapacityBuffer. Tingkatkan nilai anotasi ini jika pra-pemanasan aset memerlukan waktu lebih dari lima menit. Saat terjadi burst, GKE akan melanjutkan node yang ditangguhkan dalam waktu sekitar 20 hingga 35 detik, dan kesiapan WorkerPool menyeluruh (menjadwalkan Pod Worker, menerbitkan sertifikat Pod, dan mendaftarkan kapasitas dengan komponen ate-api-server) selesai dalam waktu sekitar 50 hingga 85 detik. Saat ditangguhkan, Anda hanya membayar untuk memori VM yang ditangguhkan dan penyimpanan boot disk. Misalnya, biaya penyimpanan yang ditangguhkan sekitar 8% dari biaya komputasi yang berjalan pada node c3-standard-4 dengan boot disk hyperdisk-balanced 100 GiB default; persentase pastinya bervariasi sesuai dengan bentuk mesin, ukuran boot disk, dan IOPS atau throughput yang disediakan.

Untuk mengetahui informasi selengkapnya tentang strategi buffering, lihat Strategi untuk mengurangi latensi startup.

Batasan dan aturan untuk buffering kapasitas

Saat Anda mengonfigurasi buffering kapasitas untuk Agent Substrate di GKE, terapkan aturan berikut:

  • Batasan bentuk mesin Compute Engine untuk buffer standby: Penangguhan instance Compute Engine tidak didukung pada VM dengan SSD Lokal yang terpasang atau pada bentuk mesin dengan memori lebih dari 208 GB (seperti jenis mesin c3-highmem-88 atau bentuk bare metal). Untuk bentuk worker node yang besar atau node dengan SSD Lokal, gunakan buffering kapasitas aktif, bukan buffering standby.
  • Hindari mengarahkan kolom scalableRef ke WorkerPool atau Deployment microVM dengan 0 replika:
    • Pengontrol CapacityBuffer GKE tidak dapat me-resolve resource kustom (kind: WorkerPool) saat pool diskalakan ke 0 replika.
    • Untuk resource WorkerPool microVM, jangan arahkan kolom scalableRef ke Deployment yang mendasarinya, karena template Pod Deployment menyertakan resource yang diperluas ate.dev/kvm: 1 (yang mencegah node auto-provisioning melakukan penyebaran skala kumpulan kosong). Sebagai gantinya, konfigurasikan buffer dengan mereferensikan PodTemplate (di kolom podTemplateRef) yang memilih ComputeClass tanpa meminta resource yang diperluas ate.dev/kvm.
    • Untuk resource WorkerPool gVisor (yang tidak meminta resource tambahan ate.dev/kvm), Anda dapat mengarahkan kolom scalableRef langsung ke Deployment yang mendasari WorkerPool atau menggunakan PodTemplate.

Contoh: Standby CapacityBuffer menggunakan PodTemplate

Manifes berikut menentukan PodTemplate dan CapacityBuffer standby yang berfungsi untuk resource WorkerPool microVM atau gVisor:

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

Ganti kode berikut:

  • WORKERPOOL_NAMESPACE: namespace Kubernetes dari WorkerPool Anda (misalnya, my-workerpool).
  • COMPUTE_CLASS_NAME: nama ComputeClass kustom yang ditargetkan oleh WorkerPool Anda (misalnya, substrate-microvm).
  • WORKER_CPU_REQUEST dan WORKER_MEMORY_REQUEST: permintaan CPU dan memori dari satu Pod Worker di WorkerPool Anda (misalnya, CPU 2 dan memori 4Gi pada node 4 vCPU), menyisakan kapasitas node untuk agen atelet dan daemon sistem GKE. Mencocokkan nilai ini dengan permintaan satu Pod Worker membantu memastikan bahwa setiap replika buffer menyediakan satu worker node standby, bukan mengemas beberapa placeholder buffer ke dalam satu node.
  • BUFFER_REPLICAS: jumlah worker node standby yang akan tetap dipanaskan (misalnya, 4 node).

Saat Anda menggunakan buffering kapasitas standby, tambahkan toleransi untuk taint buffer.gke.io/standby-capacity-node-suspended (dengan kolom operator: "Exists") ke DaemonSet atelet agar Pod atelet pengganti dapat tetap dijadwalkan pada node standby yang ditangguhkan (misalnya, selama update bertahap DaemonSet). Untuk contoh konfigurasi DaemonSet, lihat Pramuat image pada buffer standby.

Jika beberapa workload menggunakan ComputeClass yang sama, tambahkan toleransi pemisahan workload dan label nodeSelector yang cocok ke template Pod WorkerPool dan PodTemplate buffer agar GKE menyediakan node khusus yang di-taint dan tidak diklaim oleh workload lain. Tambahkan juga toleransi yang cocok ke DaemonSet atelet agar agen atelet dapat menjadwalkan pada node khusus tersebut. Untuk mengetahui petunjuk langkah demi langkah, lihat Mengonfigurasi buffering kapasitas.

Mengelola interaksi upgrade dan autoscaler

Bagian ini menjelaskan cara mengelola update DaemonSet atelet, peristiwa penurunan skala autoscaler cluster, dan upgrade node tanpa mengganggu Actor yang aktif.

Mengupdate DaemonSet atelet dengan buffer standby

Node buffer standby yang ditangguhkan membawa taint buffer.gke.io/standby-capacity-node-suspended dan taint yang tidak dapat dijangkau saat ditangguhkan, sehingga agen kubelet pada node yang ditangguhkan tidak dapat mengonfirmasi penghapusan Pod. Pastikan DaemonSet atelet menoleransi taint buffer.gke.io/standby-capacity-node-suspended (dengan kolom operator: "Exists"). Meskipun dengan toleransi tersebut, selama update bertahap standar DaemonSet atelet (dengan kolom maxUnavailable: 1), Pod pada node yang ditangguhkan akan memasuki status Terminating dan dapat memblokir update agar tidak berlanjut pada node yang berjalan.

Sebelum Anda mengupdate DaemonSet atelet di cluster dengan node standby yang ditangguhkan, lakukan salah satu hal berikut:

  • Agar node standby yang tidak dapat dijangkau tidak menghabiskan anggaran update, tetapkan kolom spec.updateStrategy.rollingUpdate.maxUnavailable pada DaemonSet atelet ke nilai yang lebih besar dari jumlah maksimum node standby yang ditangguhkan.

  • Sebelum mengupdate DaemonSet atelet, skalakan sementara replika CapacityBuffer standby Anda ke 0 dan tunggu hingga autoscaler cluster menghapus semua node buffer standby yang ditangguhkan (biasanya 10 hingga 15 menit). Untuk memeriksa apakah masih ada node yang melaporkan status kondisi Suspended dari True, jalankan perintah berikut:

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

Melindungi Actor aktif selama penurunan skala dan upgrade

Karena Actor aktif dijalankan di dalam sandbox yang dikelola oleh agen atelet, bukan sebagai Pod Kubernetes individual, permintaan CPU dan memori node mungkin tampak rendah bagi autoscaler cluster GKE, meskipun Pod Worker di node tersebut menghosting Actor aktif. Saat node dikosongkan, agen kubelet akan mengirimkan sinyal SIGTERM ke Pod Worker, dan Worker akan meneruskan sinyal SIGTERM ke proses utama setiap container dari setiap Actor yang dihostingnya. Setiap Actor yang aktif kemudian memiliki waktu hingga 30 menit untuk ditangguhkan sebelum Worker berhenti. Berikan pengendali SIGTERM kepada setiap Actor stateful yang tidak keluar pada sinyal dan yang memanggil metode SuspendActor dengan mode DURABILITY_MODE_SYNCHRONOUS. Actor yang proses utamanya keluar pada sinyal SIGTERM akan langsung kehilangan status yang belum disimpan. Jika Pod Worker berhenti saat masih menghosting Actor aktif, Actor akan memasuki status ACTOR_STATE_CRASHED.

Untuk meminimalkan gangguan selama peristiwa penurunan skala dan upgrade cluster GKE, terapkan praktik berikut:

  • Hindari penggunaan Spot VM untuk node WorkerPool stateful, karena preemption Spot VM hanya memberikan pemberitahuan penghentian selama 15 detik hingga 2 menit sebelum menghentikan node.
  • Koordinasikan pengosongan di orchestrator Anda sehingga Actor aktif di-checkpoint dan ditangguhkan sebelum Pod Worker berhenti, atau cegah autoscaler cluster mengeluarkan Pod Worker aktif (misalnya, dengan menggunakan anotasi Pod cluster-autoscaler.kubernetes.io/safe-to-evict: "false"). Jika Anda menetapkan anotasi safe-to-evict: "false" secara statis di template Pod WorkerPool, autoscaler cluster tidak akan memperkecil skala node saat Pod Worker dijadwalkan di dalamnya—bahkan saat Worker tersebut menghosting nol Actor aktif. Untuk merilis node nonaktif, Anda harus memperkecil skala replika WorkerPool atau mengelola anotasi secara dinamis. Untuk mengetahui informasi selengkapnya tentang siklus proses pengeluaran Worker dan memulihkan Actor yang error dengan metode RevertActor, lihat Pengeluaran dalam panduan Agent Substrate API.
  • Konfigurasikan upgrade lonjakan GKE dan tinjau Upgrade di lingkungan dengan resource terbatas agar worker node baru disediakan sebelum worker node yang ada dibatasi dan dikosongkan.

Langkah berikutnya