Tentang Agent Substrate di GKE

Agent Substrate di GKE menjalankan workload agentic dalam skala besar di cluster Kubernetes. Hal ini mengatasi inefisiensi resource yang umum: agen interaktif (seperti asisten pribadi dan agen coding) sering kali menghabiskan sebagian besar waktunya untuk menunggu input pengguna atau pemicu eksternal. Membiarkan agen yang tidak aktif ini terus berjalan akan menggunakan CPU dan memori yang seharusnya dapat dialokasikan untuk workload aktif.

Agent Substrate di GKE menyelesaikan masalah ini dengan memungkinkan aplikasi Anda menangguhkan agen yang tidak ada aktivitas. Saat aplikasi Anda menangguhkan agen, sistem akan mengambil snapshot memori aktif (RAM) dan file lokal agen. Saat agen yang ditangguhkan perlu bertindak lagi, sistem akan memulihkan status agen ke sandbox yang tersedia dalam waktu kurang dari satu detik.

Agent Substrate di GKE memanfaatkan kemampuan Agent Sandbox di GKE, dan meningkatkan kemampuan Agent Sandbox di GKE dengan mengabaikan bottleneck bidang kontrol Kubernetes standar. Hasilnya, Agent Substrate di GKE menjalankan lebih banyak agen serentak per mesin dan memulai agen lebih cepat daripada Agent Sandbox di GKE. Untuk membandingkan Agent Substrate di GKE dengan Agent Sandbox di GKE dan memilih arsitektur untuk workload agen AI Anda, lihat Merencanakan arsitektur untuk workload agen AI di GKE.

Deployment Kubernetes standar (termasuk Agent Sandbox di GKE) mengaitkan setiap workload agen dengan Pod khusus. Meskipun sangat skalabel, Kubernetes dibatasi oleh throughput penjadwalan dan latensi startup Pod. Selain itu, Kubernetes tidak mendukung hibernasi Pod, dan mempertahankan jutaan agen yang tidak ada aktivitas dalam cluster akan menghabiskan batas Pod dan memori bidang kontrol. Untuk menghindari pembayaran komputasi yang tidak digunakan, Anda harus menonaktifkan Pod dan mengelola status agen di penyimpanan eksternal. Agent Substrate di GKE mengatasi batasan penskalaan ini dengan memisahkan status agen dari Pod yang mendasarinya: Agent Substrate menyimpan jutaan snapshot agen yang ditangguhkan di penyimpanan dan memulihkannya sesuai permintaan ke kumpulan bersama Worker yang aktif.

Agent Substrate di GKE adalah sistem open source yang Anda deploy langsung ke cluster GKE Standard Anda sendiri. Meskipun project intinya dikembangkan di repositori Agent Substrate open source, Google menyediakan alat dan skrip deployment yang dioptimalkan untuk GKE di repositori substrate-gke, bagi pelanggan Google Cloud yang memenuhi syarat.

Manfaat Agent Substrate di GKE

Anda dapat menggunakan Agent Substrate di GKE untuk mencapai sasaran berikut:

  • Menjalankan kode yang tidak tepercaya dengan aman: Agent Substrate di GKE menerapkan isolasi kernel dan jaringan sehingga Anda dapat menjalankan kode yang dihasilkan AI tanpa membahayakan infrastruktur yang lebih luas.
  • Membangun agen stateful yang berjalan lama: memori kerja dan file agen dipertahankan di seluruh sesi. Agen akan melanjutkan dari titik yang tepat saat dijeda.
  • Merespons permintaan secara real time: saat permintaan baru memicu agen yang ditangguhkan, sistem akan memulihkan status agen dalam sepersekian detik.
  • Mengurangi biaya komputasi: Anda dapat menjalankan lebih banyak agen di lebih sedikit mesin dengan membagikan kumpulan sandbox Worker ke semua agen Anda. Karena agen yang tidak ada aktivitas akan ditangguhkan dan tidak menggunakan CPU dan memori, Anda hanya membayar komputasi saat agen aktif memproses tugas.

Kasus penggunaan

Agent Substrate di GKE dirancang untuk menjalankan agen dalam skala apa pun, mulai dari puluhan hingga jutaan agen serentak. Berikut adalah tiga contoh workload:

  • Agen produktivitas: asisten latar belakang jangka panjang yang mempertahankan konteks selama berminggu-minggu. Karena asisten ini menghabiskan sebagian besar waktu untuk menunggu pemicu, menangguhkan workload saat tidak digunakan akan mengurangi biaya komputasi.
  • Sandbox sementara: lingkungan sesuai permintaan yang terisolasi untuk mengeksekusi kode yang dihasilkan LLM yang tidak tepercaya, menjalankan panggilan alat, atau menganalisis data. Karena sandbox dapat dipulihkan dalam waktu kurang dari satu detik, sistem dapat menyediakan lingkungan sekali pakai untuk tugas yang berdurasi singkat dan merilis resource saat eksekusi selesai.
  • Agen coding: Asisten AI yang melakukan percakapan real-time dengan developer untuk menulis, membangun, dan menguji kode. Agen menjalankan perintah terminal dan mengubah file di dalam sandbox. Saat agen tidak ada aktivitas, aplikasi Anda akan menangguhkannya hingga developer mengirimkan perintah lain.

Cara kerja Agent Substrate di GKE

Agent Substrate di GKE dibangun di Kubernetes, tetapi Anda tidak perlu memahami Kubernetes untuk menggunakannya. Konsep inti Agent Substrate di GKE adalah sebagai berikut:

  • Actor: satu instance agen yang sedang berjalan.
  • ActorTemplate: blueprint konfigurasi (menentukan image container, variabel lingkungan, dan resource komputasi) yang digunakan untuk membuat instance Actor.
  • Worker: sandbox tempat Actor aktif berjalan.
  • WorkerPool: grup Worker yang sudah dimulai dan tidak ada aktivitas yang terus siap menerima Actor.

Karena Actor tidak terikat dengan Worker tertentu, sistem dapat menggunakan kembali komputasi yang dikosongkan oleh Actor saat aplikasi Anda menangguhkannya. Arsitektur ini memungkinkan sistem menjalankan jutaan agen di sejumlah mesin yang terbatas.

Siklus proses agen standar mengikuti langkah-langkah berikut:

  1. Perutean: setiap permintaan API yang masuk dari aplikasi Anda menentukan Actor targetnya. Misalnya, saat pengguna mengetik perintah baru ke dalam antarmuka chat, aplikasi Anda akan mengirimkan permintaan yang ditujukan kepada Actor tertentu yang mengelola sesi pengguna.
  2. Melanjutkan: jika permintaan ditujukan untuk Actor yang ditangguhkan, sistem akan mengklaim Worker hangat dari WorkerPool dan memulihkan snapshot Actor ke Worker tersebut.
  3. Executing: sistem mengarahkan permintaan ke Worker yang baru aktif ini, dan Actor memproses tugas.
  4. Menangguhkan: saat aplikasi Anda menangguhkan Actor yang tidak ada aktivitas, sistem akan mengambil snapshot baru dari memori dan file Actor, menyimpan snapshot ke penyimpanan, dan merilis Worker kosong kembali ke pool.

Isolasi workload dan GKE Sandbox

Agent Substrate di GKE menggunakan gVisor atau Cloud Hypervisor untuk menjalankan setiap workload di sandbox yang mengisolasi kode aplikasi dari kernel host. Penginstalan Agent Substrate di GKE menyertakan runtime gVisor-nya sendiri untuk Worker. Jangan aktifkan GKE Sandbox di node pool tempat Agent Substrate di GKE berjalan, karena Agent Substrate di GKE tidak dapat berjalan di node tersebut. Anda masih dapat menggunakan GKE Sandbox untuk workload lain, termasuk Agent Sandbox di GKE.

Batasan dan persyaratan

Agent Substrate di GKE memiliki batasan dan persyaratan berikut:

  • Mode, versi, dan saluran rilis cluster: Agent Substrate di GKE mendukung cluster GKE Standard yang bidang kontrol dan node pool-nya menjalankan versi 1.37 atau yang lebih baru. Cluster Autopilot dan versi sebelum 1.37 tidak didukung. Pada versi 1.37 dan yang lebih baru, GKE menyajikan Kubernetes API podcertificaterequests dan clustertrustbundles serta memungkinkan node memasang sertifikat Pod dan paket kepercayaan ke dalam Pod, sehingga Anda tidak perlu mengaktifkan versi beta API ini sendiri. Namun, penginstal mengaktifkan versi beta di setiap cluster yang dibuat atau dikonfigurasinya. Karena saluran rilis Extended tidak mendukung API beta yang diaktifkan secara eksplisit, Anda tidak dapat menggunakan penginstal dengan cluster yang terdaftar di saluran rilis Extended.

  • Workload Identity Federation for GKE: Cluster GKE harus mengaktifkan Workload Identity Federation for GKE. Agent Substrate di GKE menggunakan Workload Identity Federation for GKE untuk melakukan autentikasi ke API Google Cloud , seperti Cloud Storage untuk menyimpan snapshot agen. Untuk menyimpan dan memulihkan snapshot, sistem menggunakan akun layanan khusus bernama ate-snapshot-transfer. Kredensial untuk setiap operasi simpan atau pulihkan hanya dapat mengakses snapshot dari satu Actor. Oleh karena itu, Anda tidak perlu memberikan akses ke bucket snapshot kepada node GKE Anda. Penginstal membuat akun layanan ate-snapshot-transfer dan memberinya akses ke bucket snapshot. Jika Anda menyiapkan izin sendiri, berikan peran IAM berikut:

    • Di bucket snapshot, berikan peran Storage Object Admin (roles/storage.objectAdmin) dan Storage Bucket Viewer (roles/storage.bucketViewer) kepada akun layanan ate-snapshot-transfer dan akun layanan Kubernetes ate-api-server.
    • Di akun layanan ate-snapshot-transfer, berikan peran Service Account Token Creator (roles/iam.serviceAccountTokenCreator) kepada akun layanan Kubernetes ate-api-server. Akun layanan ate-api-server meniru akun layanan ate-snapshot-transfer untuk menerbitkan kredensial bagi setiap Actor.
    • Jika Anda menggunakan runtime microVM, berikan peran Storage Object Viewer (roles/storage.objectViewer) kepada akun layanan Kubernetes atelet di bucket aset.

    Untuk mengetahui daftar lengkap binding dan perintah gcloud yang setara, lihat Apa yang sebenarnya diberikan oleh create iam di README setup-gcp.

  • Kelompok VM:

    • Arsitektur CPU campuran: Agent Substrate di GKE tidak mendukung seri mesin tujuan umum yang berjalan pada arsitektur CPU campuran (seperti jenis mesin E2) karena masalah umum di gVisor.
    • Jenis VM yang seragam per template Actor: semua Actor yang Anda buat dari satu ActorTemplate harus berjalan pada jenis VM yang sama. ActorTemplate bukan resource Kubernetes dan tidak memiliki pemilih node. Sebagai gantinya, kolom workerSelector dari ActorTemplate memilih resource WorkerPool berdasarkan labelnya. Setiap WorkerPool dapat memilih node untuk Worker-nya menggunakan kolom spec.template.nodeSelector. Misalnya, jika cluster Anda memiliki node pool yang menggunakan VM C4 dan VM N2, konfigurasikan setiap WorkerPool untuk memilih node dari satu jenis VM saja. Kemudian, tetapkan kolom workerSelector dari ActorTemplate agar hanya cocok dengan resource WorkerPool yang menggunakan VM C4.
    • Virtualisasi bertingkat atau bare metal untuk runtime microVM: runtime microVM menjalankan setiap sandbox di virtual machine-nya sendiri, sehingga Worker yang menggunakan runtime ini memerlukan node yang dapat menjalankan virtual machine. Node ini harus menggunakan arsitektur CPU x86, bukan Arm. Saat penginstal membuat cluster, node pool yang dibuatnya akan mengaktifkan virtualisasi bertingkat. Jika Anda menginstal Agent Substrate di GKE dalam cluster yang ada atau menambahkan node pool Anda sendiri untuk Worker microVM, gunakan node pool yang mengaktifkan virtualisasi bertingkat atau yang menggunakan jenis mesin bare-metal x86. Anda hanya dapat mengaktifkan virtualisasi bertingkat saat membuat node pool. Untuk memeriksa seri mesin yang mendukung virtualisasi bertingkat, seperti C3, C4, N2, dan N4, lihat Perbandingan seri mesin.

  • Dukungan GPU: Passthrough perangkat GPU ke container Actor tidak didukung. Menentukan nvidia.com/gpu hanya menempatkan Pod pada node yang mendukung GPU, tetapi tidak meneruskan perangkat GPU ke container Actor. Selain itu, gVisor tidak dapat membuat snapshot konteks CUDA aktif.

  • Koneksi jaringan terbuka: koneksi jaringan terbuka (seperti sesi database atau koneksi ke server MCP) tidak dipertahankan saat agen ditangguhkan. Kode agen Anda harus menangani koneksi ulang ke layanan eksternal saat agen melanjutkan.

  • Kemampuan Observasi dan OpenTelemetry Terkelola: OpenTelemetry Terkelola untuk GKE memiliki batasan berikut:

    • Konektor kolektor tidak didukung, sehingga memerlukan penggunaan meteran proxy eksternal untuk tolok ukur telemetri.
    • Deployment kolektor menimbulkan overhead cache memori yang diskalakan secara linear dengan jumlah Pod di cluster besar.
    • TLS tidak didukung di OpenTelemetry Terkelola untuk GKE.

  • Penyimpanan: Agent Substrate di GKE menggunakan bucket Cloud Storage berikut, yang dibuat oleh penginstal jika belum ada:

    • Bucket snapshot: menyimpan snapshot semua agen di cluster Anda. Bucket ini wajib diisi.
    • Bucket aset: menyimpan file yang diperlukan runtime microVM, seperti kernel Linux dan sistem file root. Runtime microVM menggunakan file ini untuk menjalankan setiap sandbox di virtual machine-nya sendiri. Nama bucket ini adalah nama bucket snapshot yang diikuti dengan -assets. Misalnya, jika bucket snapshot Anda diberi nama example-snapshots, bucket aset akan diberi nama example-snapshots-assets. Jika Anda tidak menggunakan runtime microVM, bucket ini akan tetap kosong.

  • Setelan kernel untuk kepadatan sandbox yang tinggi: menjalankan lebih dari sekitar 800 sandbox serentak pada satu node akan melebihi batas default di kernel Linux untuk pemantauan sistem file (inotify) dan untuk tabel tetangga Address Resolution Protocol (ARP). Tanpa batas yang lebih tinggi, sandbox dapat gagal dimulai dan jaringan dapat terhenti. Penginstal menerapkan setelan kernel yang diperlukan ke cluster yang dibuatnya. Jika Anda menginstal Agent Substrate di GKE dalam cluster yang ada atau menambahkan node pool Anda sendiri, Anda harus menerapkan setelan ini sendiri. Untuk mengetahui nilai yang diperlukan, lihat Persyaratan cluster dan Mendesain infrastruktur untuk Agent Substrate di GKE.

  • Lingkungan penginstalan: Anda tidak dapat menginstal Agent Substrate di GKE di Cloud Shell. Cloud Shell memiliki batas penyimpanan persistent disk sebesar 5 GB yang tidak menyediakan kapasitas disk yang cukup untuk penginstalan. Anda harus menginstal Agent Substrate di GKE dari workstation lokal atau virtual machine (VM) yang memiliki kapasitas disk yang cukup.

Langkah berikutnya