Merencanakan arsitektur untuk workload agen AI di GKE

Google Kubernetes Engine (GKE) menyediakan dua model orkestrasi untuk menjalankan agen AI di dalam sandbox yang diisolasi kernel (menggunakan microVM Cloud Hypervisor atau gVisor):

  • Agent Substrate di GKE (berbasis aktor, direkomendasikan): gunakan model ini untuk sebagian besar workload agen AI, terutama agen berbasis CPU stateful yang sering ditangguhkan dan dilanjutkan. Sesi agen aktif (aktor) berbagi kumpulan Pod worker hangat dan dapat dipulihkan dari Cloud Storage dalam waktu kurang dari satu detik.
  • Agent Sandbox di GKE (berbasis Pod): gunakan model ini jika setiap agen memerlukan Pod Kubernetes khusus. Pilih opsi ini untuk agen yang terus aktif atau workload yang memerlukan PodSpec Kubernetes lengkap (seperti sidecar), GPU atau TPU, node Arm, atau cluster GKE Autopilot.

Untuk ringkasan berdampingan dari kedua model orkestrasi, lihat Membandingkan Agent Substrate dan Agent Sandbox.

Baca dokumen ini untuk memilih model orkestrasi, runtime sandbox, kontrol isolasi, dan opsi penyimpanan sebelum Anda menyediakan cluster GKE. Dokumen ini ditujukan untuk arsitek solusi, developer AI, serta admin dan operator platform yang mendesain lingkungan eksekusi untuk agen AI di GKE.

Persyaratan arsitektur untuk workload agen AI di GKE

Menjalankan workload agen AI di GKE memungkinkan Anda menempatkan lingkungan eksekusi agen yang terisolasi di cluster dan perimeter jaringan yang sama dengan layanan Kubernetes pendukung, serta menggunakan GKE untuk penyediaan otomatis node, penskalaan burst, dan pengelolaan siklus proses.

Tidak seperti microservice yang terus aktif, workload agen AI memiliki persyaratan arsitektur berikut:

Model berbasis aktor: Agent Substrate di GKE (direkomendasikan)

Agent Substrate di GKE adalah runtime eksekusi yang memisahkan sesi agen (aktor) dari Pod Kubernetes yang mendasarinya. Aktor aktif berbagi kumpulan Pod worker yang telah di-warm up (resource WorkerPool) di seluruh template aktor (resource ActorTemplate). Saat aplikasi Anda menangguhkan aktor yang tidak ada aktivitas, Agent Substrate akan membuat checkpoint status aktor ke Cloud Storage dan merilis kapasitas worker-nya sehingga aktor lain dapat menggunakan node tersebut. Saat permintaan baru masuk, Agent Substrate akan memulihkan aktor ke worker yang tersedia dalam waktu kurang dari satu detik.

Gunakan Agent Substrate sebagai arsitektur default Anda untuk workload agen berbasis CPU, termasuk kasus penggunaan berikut:

  • Agen coding interaktif: Asisten AI yang menjalankan perintah terminal, membangun kode, dan mengedit file selama percakapan developer, serta menangguhkan di antara perintah.
  • Agen produktivitas yang berjalan lama: asisten latar belakang yang mempertahankan konteks selama berhari-hari atau berminggu-minggu sambil menghabiskan sebagian besar waktunya untuk menunggu input pengguna atau pemicu eksternal.
  • Sandbox kode dan browser sementara: lingkungan on-demand untuk menjalankan kode yang dihasilkan LLM, browser headless, atau panggilan alat yang dipulihkan dalam waktu kurang dari satu detik dan merilis komputasi setelah eksekusi.

Agent Substrate memerlukan cluster GKE Standard (versi 1.37 atau yang lebih baru di bidang kontrol dan node pool) dengan worker node CPU x86. GKE Autopilot tidak didukung karena agen node Agent Substrate (atelet) berjalan sebagai DaemonSet dengan hak istimewa, dan worker pool microVM memerlukan virtualisasi bertingkat atau node bare-metal. GPU dan TPU tidak didukung.

Identitas, kredensial, dan traffic keluar jaringan

Agent Substrate menyediakan sertifikat SPIFFE X.509 dan JSON Web Token (JWT) unik untuk setiap aktor guna mengautentikasi dan mengaudit permintaan dari setiap sesi. Karena beberapa aktor berbagi Pod worker dari waktu ke waktu, gunakan Workload Identity Federation untuk GKE level Pod hanya untuk tugas infrastruktur worker.

Untuk menyimpan kunci dan token API di luar sandbox, gateway egress bawaan memasukkan kredensial ke dalam permintaan keluar dalam pengiriman. Anda menyimpan secret di objek Secret Kubernetes atau di Secret Manager. Saat permintaan HTTP atau HTTPS keluar cocok dengan aturan egress, gateway akan mengautentikasi tunnel mTLS aktor dan mengganti header placeholder dengan secret yang diambil atau JWT aktor. Untuk mengetahui informasi selengkapnya, lihat dokumentasi injeksi kredensial egress Agent Substrate open source.

Secara default, Agent Substrate memblokir semua traffic keluar ke aktor lain, bidang kontrol Kubernetes, server metadata Compute Engine, dan internet. UDP non-DNS, koneksi TCP mentah arbitrer, dan upgrade WebSocket HTTP diblokir, dan DNS hanya me-resolve nama host yang diizinkan oleh resource EgressPolicy aktor. Untuk mengizinkan koneksi keluar, tentukan aturan passthrough HTTP, HTTPS, atau TLS di resource EgressPolicy menggunakan nama domain yang sepenuhnya memenuhi syarat (FQDN) atau nama host karakter pengganti. Alamat IP dan rentang CIDR tidak didukung. Untuk mengetahui informasi selengkapnya, lihat dokumentasi open source Agent Substrate terkait traffic egress dan keamanan.

Checkpoint sesi dan penyimpanan ruang kerja

Saat aplikasi Anda menangguhkan aktor (di gVisor atau microVM), Agent Substrate menyimpan snapshot ke Cloud Storage di tiga lapisan: memori aktif, perubahan sistem file root, dan direktori tahan lama (lapisan volume). Setiap volume CSI eksternal yang terpasang akan tetap ada di penyimpanan pendukungnya di luar snapshot dan dipasang kembali saat dilanjutkan.

Saat aktor yang ditangguhkan dilanjutkan, Agent Substrate akan memulihkan lapisan snapshot tertinggi yang cocok dengan lingkungan target:

  • Memori, sistem file root, dan volume: dipulihkan dalam waktu kurang dari satu detik saat aktor melanjutkan dengan hardware, runtime sandbox, dan image container yang sama.
  • Sistem file root dan volume: dipulihkan saat hardware node atau runtime sandbox berubah. Aktor memulai ulang prosesnya sambil mempertahankan perubahan sistem file root dan direktori yang tahan lama.
  • Hanya volume: dipulihkan saat Anda mengupdate image container di resource ActorTemplate saat aktor ditangguhkan. Pelanjutan berikutnya akan memulai container dari image yang diupdate dan memulihkan direktori yang tahan lama serta volume eksternal. Tulis data yang harus bertahan dari update image ke direktori yang tahan lama atau penyimpanan eksternal.

Latensi penangguhan dan melanjutkan diskalakan sesuai dengan ukuran snapshot. Untuk ruang kerja besar yang memerlukan pemasangan ulang lintas node yang cepat saat aktor melanjutkan di node yang berbeda, gunakan volume agen Filestore eksternal, bukan menyimpan data di dalam snapshot. Setiap volume CSI eksternal (Pratinjau) dalam resource ActorTemplate disediakan secara eksklusif untuk satu aktor (tidak dibagikan di seluruh aktor) dan dihapus bersama aktor tersebut. Dukungan produksi untuk volume agen Filestore ditawarkan melalui program GA terbatas yang memerlukan permintaan akses.

Block storage (seperti Hyperdisk) digunakan untuk boot disk node dan caching snapshot lokal, bukan volume CSI per aktor, karena latensi pelepasan dan pemasangan blok lintas node memperlambat kelanjutan aktor. Untuk mengetahui informasi selengkapnya, lihat dokumentasi volume CSI Agent Substrate open source.

Model berbasis pod: Agent Sandbox di GKE

Agent Sandbox di GKE menjalankan setiap agen di Pod Kubernetes stateful khusus yang dikelola melalui resource kustom Kubernetes (Sandbox, SandboxClaim, SandboxTemplate, dan SandboxWarmPool). Resource SandboxWarmPool mengelola resource Sandbox yang telah dihangatkan dengan Pod yang berjalan untuk resource SandboxTemplate tertentu, sehingga pengontrol dapat menetapkan resource Sandbox yang siap dan Pod yang berjalan ke klaim dalam waktu kurang dari satu detik.

Pilih Agent Sandbox jika setiap agen memerlukan Pod khusus atau jika workload Anda memiliki salah satu persyaratan berikut:

  • Agen yang terus aktif dan layanan Pod tunggal: workload tanpa periode tidak ada aktivitas yang sering, atau sesi persisten (seperti lingkungan pengembangan cloud atau Jupyter Notebook) yang memerlukan nama host dan penyimpanan yang stabil tanpa kompleksitas StatefulSet.
  • Akselerator hardware (GPU atau TPU): agen yang memerlukan akses langsung ke GPU atau TPU di dalam sandbox. Akselerator hanya berfungsi dengan runtime gVisor pada model GPU dan versi TPU yang didukung. MicroVM tidak mendukung GPU atau TPU.
  • PodSpec Kubernetes lengkap, node Arm, atau GKE Autopilot: workload yang memerlukan sidecar kustom atau container init, API dan alat Kubernetes standar (misalnya, perintah kubectl, kontrol akses berbasis peran, dan pengontrol yang ada), CPU Arm, atau cluster GKE Autopilot.

Identitas, kredensial, dan kebijakan jaringan

Karena setiap agen berjalan di Pod khusus, Anda dapat memberikan izin Google Cloud Identity and Access Management (IAM) ke Pod menggunakan Workload Identity Federation for GKE atau Agent Identity (Pratinjau). Kedua opsi mengikat identitas ke ServiceAccount Kubernetes Pod saat pembuatan Pod, sehingga semua Pod yang telah di-warm up dalam resource SandboxWarmPool memiliki identitas yang sama. Untuk mengisolasi identitas per agen atau tenant, pertahankan resource SandboxWarmPool terpisah per identitas atau buat resource Sandbox sesuai permintaan tanpa warm pool.

Anda memasang secret ke Pod menggunakan objek Secret Kubernetes standar atau volume CSI. Agent Sandbox tidak menyertakan gateway untuk injeksi kredensial di luar sandbox. Untuk memasukkan kredensial dalam pengiriman, deploy proxy eksternal Anda sendiri.

Pengontrol membuat objek NetworkPolicy default-deny untuk setiap resource SandboxTemplate. Untuk resource Sandbox yang Anda buat langsung tanpa template, buat objek NetworkPolicy Anda sendiri. Anda membatasi traffic menggunakan kontrol jaringan GKE standar:

Penangguhan saat tidak ada aktivitas, snapshot Pod, dan penyimpanan

Pod agen yang tidak ada aktivitas akan mempertahankan CPU dan memori yang dicadangkan hingga aplikasi Anda menangguhkan resource Sandbox dengan menetapkan kolom spec.operatingMode ke Suspended. Menangguhkan resource Sandbox akan menghapus Pod sekaligus mempertahankan volume persistennya. Menghapus Pod akan menghapus data dalam memori dan perubahan sistem file container. Untuk menyimpan dan memulihkan status tersebut dari Cloud Storage, ambil snapshot Pod GKE sebelum menangguhkan agen. Snapshot pod memerlukan runtime gVisor dan tidak mendukung microVM atau TPU. Memulihkan Pod dari snapshot memerlukan waktu sekitar tiga hingga lima detik.

Untuk penyimpanan persisten di luar snapshot Pod, pilih dari opsi berikut:

  • Filestore: memasang PersistentVolumeClaim (PVC) ReadWriteMany (RWX) bersama di beberapa Pod Sandbox untuk ruang kerja kolaboratif. Untuk mengetahui informasi selengkapnya, lihat Memilih penyimpanan untuk workload agentic AI.
  • Hyperdisk: gunakan Google Cloud Hyperdisk Balanced (mode akses ReadWriteOnce) untuk disk Pod yang terisolasi, atau Google Cloud Hyperdisk ML (mode akses ReadOnlyMany) untuk membagikan set data atau bobot model hanya baca di seluruh node. Untuk mengetahui informasi selengkapnya, lihat Memilih penyimpanan untuk workload agentic AI dan Tentang Hyperdisk untuk GKE.

Membandingkan Agent Substrate dan Agent Sandbox

Tabel berikut merangkum perbedaan arsitektur antara Agent Substrate di GKE dan Agent Sandbox di GKE:

Dimensi Agent Substrate di GKE (berbasis aktor) Agent Sandbox di GKE (berbasis Pod)
Workload agen AI yang direkomendasikan Sebagian besar agen berbasis CPU stateful yang sering ditangguhkan dan dilanjutkan Agen yang terus aktif, workload GPU atau TPU, PodSpec kustom, node Arm, atau GKE Autopilot
Unit penjadwalan Beberapa aktor berbagi kumpulan Pod hangat (WorkerPool) Satu Pod khusus per agen (Sandbox)
Runtime sandbox MicroVM gVisor dan Cloud Hypervisor (dikelola di dalam Pod WorkerPool) gVisor dan microVM di GKE Standard (dengan GKE Sandbox diaktifkan di node pool atau ComputeClass), atau gVisor di GKE Autopilot (diaktifkan secara default)
Warm pooling Resource WorkerPool bersama di seluruh template aktor dan image container Satu resource SandboxWarmPool per template dan image container
Jalur bidang kontrol Bidang kontrol dan database khusus di luar komponen kube-apiserver Pengontrol Kubernetes standar, kube-apiserver, dan etcd
Penanganan resource tidak ada aktivitas Menangguhkan aktor yang tidak ada aktivitas akan melepaskan CPU dan memori worker-nya Menangguhkan resource Sandbox yang tidak ada aktivitas akan menghapus Pod-nya dan mempertahankan volume persisten
Checkpoint status Snapshot Cloud Storage bawaan di gVisor dan microVM, yang dipulihkan dalam waktu kurang dari satu detik Snapshot pod GKE (hanya didukung di gVisor), yang dipulihkan dalam 3-5 detik
Mode cluster yang didukung GKE Standard (versi 1.37 atau yang lebih baru, node x86) GKE Standard dan GKE Autopilot
Akselerator hardware Tidak didukung (worker node khusus CPU) GPU dan TPU hanya didukung dengan runtime gVisor
Dukungan PodSpec Kubernetes Subset yang dibagi di seluruh resource ActorTemplate dan WorkerPool PodSpec lengkap, termasuk sidecar dan container init
Jaringan Gateway masuk dan keluar Envoy bawaan dengan tunnel mTLS per aktor Service Kubernetes, NetworkPolicy, dan FQDNNetworkPolicy
Model identitas Sertifikat SPIFFE X.509 dan JWT per aktor ServiceAccount Pod yang menggunakan Workload Identity Federation for GKE atau Agent Identity (Pratinjau), yang dibagikan di seluruh warm pool
Pengelolaan secret Diinjeksikan ke permintaan keluar di gateway keluar Dipasang di Pod menggunakan objek Secret Kubernetes atau volume CSI

Memilih runtime sandbox

Agent Substrate dan Agent Sandbox mengisolasi kode yang tidak tepercaya dari node host menggunakan microVM Cloud Hypervisor atau gVisor, tetapi Anda mengonfigurasi runtime secara berbeda di setiap model:

  • Agent Substrate: pilih runtime pada resource WorkerPool. Agent Substrate mengelola runtime microVM dan gVisor-nya sendiri di dalam Pod WorkerPool, bukan menggunakan fitur GKE Sandbox di level node. Jangan aktifkan GKE Sandbox di node pool worker Agent Substrate, karena taint node sandbox.gke.io/runtime mencegah Pod WorkerPool dijadwalkan.
  • Agent Sandbox: tetapkan kolom runtimeClassName ke gvisor atau microvm di template Pod resource SandboxTemplate Anda. Di GKE Standard, aktifkan juga GKE Sandbox di node pool atau di ComputeClass kustom. Di GKE Autopilot, gVisor tersedia secara default dan microVM tidak didukung.

Kedua runtime menjalankan kode yang tidak tepercaya dan browser headless:

  • MicroVMs: setiap sandbox berjalan di virtual machine ringan dengan kernel Linux tamu khusus. Pilih microVM saat Anda memerlukan isolasi tingkat VM, kompatibilitas syscall Linux penuh, atau batas CPU dan memori per container di dalam aktor multi-container.
  • gVisor: setiap sandbox berjalan di kernel ruang pengguna yang mencegat dan memfilter syscall Linux. Pilih gVisor untuk cold start yang lebih cepat, overhead memori yang lebih rendah, atau dukungan mesin Compute Engine yang lebih luas (termasuk GPU, TPU, node Arm, dan GKE Autopilot di Agent Sandbox).

Tabel berikut membandingkan microVM dan gVisor di GKE:

Fitur MicroVMs gVisor
Akses kernel Kernel Linux lengkap Subset syscall kernel Linux
Tingkat isolasi Virtualisasi hardware dengan kernel tamu khusus Intersepsi syscall di kernel ruang pengguna
Overhead CPU dan memori Memori VMM per aktor di Agent Substrate. Tetap 250 mCPU dan 130 MiB per Pod di GKE Sandbox. Overhead dinamis dengan memori dasar rendah
Waktu mulai 1 hingga 2 detik Kurang dari 100 md
Konfigurasi node GKE Node GKE Standard dengan virtualisasi bertingkat (kedua model), atau node bare-metal x86 (khusus Agent Substrate) Node pool GKE Standard (kedua model), atau node GKE Autopilot (khusus Agent Sandbox)
Dukungan image node Container-Optimized OS (cos_containerd) di Agent Substrate. Container-Optimized OS (cos_containerd) atau Ubuntu di GKE Sandbox. Khusus Container-Optimized OS (cos_containerd)
Kompatibilitas jenis mesin Seri mesin x86 yang mendukung virtualisasi bertingkat dan bare metal x86 (tidak didukung di E2 atau Arm) Seri x86 non-mixed-CPU di Agent Substrate. Sebagian besar seri x86, Arm, dan akselerator di Agent Sandbox.
Dukungan akselerator Tidak didukung Model GPU dan versi TPU yang didukung (khusus Agent Sandbox)
Contoh kasus penggunaan
  • Agen coding dan browser otonom
  • Workload yang memerlukan kompatibilitas kernel Linux penuh
  • Workload I/O tinggi dengan panggilan sistem yang sering
  • Aplikasi yang tidak tepercaya di Python, Node.js, Go, Java, atau Rust
  • Inferensi CPU, GPU, atau TPU dan sandbox eksekusi kode
  • Frontend, cache, dan proxy web

Untuk mengetahui informasi selengkapnya tentang teknologi isolasi ini, lihat GKE Sandbox.

Langkah berikutnya