GKE에서 AI 에이전트 워크로드를 위한 아키텍처 계획

Google Kubernetes Engine(GKE)은 커널 격리 샌드박스 내에서 AI 에이전트를 실행하기 위한 두 가지 조정 모델을 제공합니다(Cloud Hypervisor microVM 또는 gVisor 사용).

  • GKE의 에이전트 기판(액터 기반, 권장): 대부분의 AI 에이전트 워크로드, 특히 자주 정지 및 재개되는 스테이트풀(Stateful) CPU 기반 에이전트에 이 모델을 사용합니다. 활성 에이전트 세션(액터)은 웜 워커 포드 풀을 공유하며 1초 이내에 Cloud Storage에서 복원할 수 있습니다.
  • GKE의 에이전트 샌드박스(포드 기반): 각 에이전트에 전용 Kubernetes 포드가 필요한 경우 이 모델을 사용합니다. 지속적으로 활성 상태인 에이전트 또는 전체 Kubernetes PodSpec(예: 사이드카), GPU 또는 TPU, Arm 노드, GKE Autopilot 클러스터가 필요한 워크로드의 경우 이 옵션을 선택합니다.

두 조정 모델을 나란히 비교한 요약은 Agent Substrate와 Agent Sandbox 비교를 참조하세요.

이 문서를 읽고 GKE 클러스터를 프로비저닝하기 전에 조정 모델, 샌드박스 런타임, 격리 제어, 스토리지 옵션을 선택하세요. 이 문서는 GKE에서 AI 에이전트의 실행 환경을 설계하는 솔루션 설계자, AI 개발자, 플랫폼 관리자, 운영자를 대상으로 합니다.

GKE의 AI 에이전트 워크로드에 대한 아키텍처 요구사항

GKE에서 AI 에이전트 워크로드를 실행하면 지원 Kubernetes 서비스와 동일한 클러스터 및 네트워크 경계에 격리된 에이전트 실행 환경을 배치하고 GKE를 사용하여 노드 자동 프로비저닝, 버스트 확장, 수명 주기 관리를 수행할 수 있습니다.

지속적으로 활성 상태인 마이크로서비스와 달리 AI 에이전트 워크로드에는 다음과 같은 아키텍처 요구사항이 있습니다.

액터 기반 모델: GKE의 Agent Substrate(권장)

GKE의 Agent Substrate는 에이전트 세션(액터)을 기본 Kubernetes 포드에서 분리하는 실행 런타임입니다. 활성 작업자는 작업자 템플릿(ActorTemplate 리소스)에서 사전 준비된 작업자 포드(WorkerPool 리소스) 풀을 공유합니다. 애플리케이션이 유휴 액터를 정지하면 Agent Substrate는 액터의 상태를 Cloud Storage에 체크포인트하고 작업자 용량을 해제하여 다른 액터가 노드를 사용할 수 있도록 합니다. 새 요청이 도착하면 Agent Substrate는 1초 이내에 사용 가능한 작업자에 액터를 복원합니다.

다음 사용 사례를 포함하여 CPU 기반 에이전트 워크로드의 기본 아키텍처로 Agent Substrate를 사용합니다.

  • 대화형 코딩 에이전트: 개발자 대화 중에 터미널 명령어를 실행하고, 코드를 빌드하고, 파일을 수정하고, 프롬프트 간에 일시중지하는 AI 어시스턴트입니다.
  • 장기 실행 생산성 에이전트: 며칠 또는 몇 주 동안 컨텍스트를 유지하면서 대부분의 시간을 사용자 입력이나 외부 트리거를 기다리는 데 사용하는 백그라운드 어시스턴트입니다.
  • 임시 코드 및 브라우저 샌드박스: LLM 생성 코드, 헤드리스 브라우저 또는 도구 호출을 실행하기 위한 주문형 환경으로, 1초 이내에 복원되고 실행 후 컴퓨팅을 해제합니다.

Agent Substrate에는 x86 CPU 워커 노드가 있는 GKE Standard 클러스터(컨트롤 플레인 및 노드 풀 모두에서 버전 1.37 이상)가 필요합니다. 에이전트 기판 노드 에이전트(atelet)가 권한이 있는 DaemonSet로 실행되고 마이크로 VM 워커 풀에 중첩 가상화 또는 베어메탈 노드가 필요하므로 GKE Autopilot은 지원되지 않습니다. GPU 및 TPU는 지원되지 않습니다.

ID, 사용자 인증 정보, 네트워크 이그레스

에이전트 기판은 개별 세션의 요청을 인증하고 감사하기 위해 각 행위자에게 고유한 SPIFFE X.509 인증서와 JSON 웹 토큰(JWT)을 프로비저닝합니다. 여러 행위자가 시간이 지남에 따라 워커 포드를 공유하므로 워커 인프라 태스크에만 포드 수준 GKE용 워크로드 아이덴티티 제휴를 사용합니다.

API 키와 토큰을 샌드박스 외부에 유지하기 위해 기본 제공 이그레스 게이트웨이는 전송 중인 아웃바운드 요청에 사용자 인증 정보를 삽입합니다. Kubernetes 보안 비밀 객체 또는 Secret Manager에 보안 비밀을 저장합니다. 아웃바운드 HTTP 또는 HTTPS 요청이 이그레스 규칙과 일치하면 게이트웨이가 작업자의 mTLS 터널을 인증하고 자리표시자 헤더를 가져온 보안 비밀 또는 작업자 JWT로 바꿉니다. 자세한 내용은 오픈소스 Agent Substrate 이그레스 사용자 인증 정보 삽입 문서를 참조하세요.

기본적으로 Agent Substrate는 다른 행위자, Kubernetes 컨트롤 플레인, Compute Engine 메타데이터 서버, 인터넷으로의 모든 아웃바운드 트래픽을 차단합니다. DNS가 아닌 UDP, 임의의 원시 TCP 연결, HTTP WebSocket 업그레이드가 차단되고 DNS는 작업자의 EgressPolicy 리소스에서 허용하는 호스트 이름만 변환합니다. 아웃바운드 연결을 허용하려면 정규화된 도메인 이름(FQDN) 또는 와일드 카드 호스트 이름을 사용하여 EgressPolicy 리소스에서 HTTP, HTTPS 또는 TLS 패스 스루 규칙을 정의합니다. IP 주소 및 CIDR 범위는 지원되지 않습니다. 자세한 내용은 오픈소스 Agent Substrate 이그레스 트래픽 및 보안 문서를 참조하세요.

세션 체크포인트 및 작업공간 스토리지

애플리케이션이 gVisor 또는 microVM에서 행위자를 정지하면 Agent Substrate는 활성 메모리, 루트 파일 시스템 변경사항, 영구 디렉터리(볼륨 레이어)의 세 가지 레이어에 걸쳐 스냅샷을 Cloud Storage에 저장합니다. 연결된 외부 CSI 볼륨은 스냅샷 외부의 지원 스토리지에 유지되며 재개 시 다시 연결됩니다.

정지된 행위자가 재개되면 Agent Substrate는 대상 환경과 일치하는 가장 높은 스냅샷 레이어를 복원합니다.

  • 메모리, 루트 파일 시스템, 볼륨: 액터가 동일한 하드웨어, 샌드박스 런타임, 컨테이너 이미지로 재개되면 1초 이내에 복원됩니다.
  • 루트 파일 시스템 및 볼륨: 노드 하드웨어 또는 샌드박스 런타임이 변경되면 복원됩니다. 액터는 루트 파일 시스템 변경사항과 영구 디렉터리를 유지하면서 프로세스를 다시 시작합니다.
  • 볼륨만: 액터가 정지된 동안 ActorTemplate 리소스에서 컨테이너 이미지를 업데이트하면 복원됩니다. 다음 재개 시 업데이트된 이미지에서 컨테이너를 시작하고 영구 디렉터리와 외부 볼륨을 복원합니다. 이미지 업데이트 후에도 유지되어야 하는 데이터를 내구성 있는 디렉터리나 외부 저장소에 작성합니다.

일시중지 및 재개 지연 시간은 스냅샷 크기에 따라 확장됩니다. 액터가 다른 노드에서 재개될 때 빠른 노드 간 재연결이 필요한 대규모 작업공간의 경우 스냅샷 내에 데이터를 저장하는 대신 외부 Filestore 에이전트 볼륨을 사용합니다. ActorTemplate 리소스의 각 외부 CSI 볼륨(프리뷰)은 단일 액터 전용으로 프로비저닝되며(액터 간에 공유되지 않음) 해당 액터와 함께 삭제됩니다. Filestore 에이전트 볼륨에 대한 프로덕션 지원은 액세스 요청이 필요한 제한된 정식 버전 프로그램을 통해 제공됩니다.

교차 노드 블록 분리 및 연결 지연 시간으로 인해 액터 재개가 느려지므로 액터별 CSI 볼륨이 아닌 노드 부팅 디스크 및 로컬 스냅샷 캐싱에 블록 스토리지(예: Hyperdisk)가 사용됩니다. 자세한 내용은 오픈소스 Agent Substrate CSI 볼륨 문서를 참조하세요.

포드 기반 모델: GKE의 에이전트 샌드박스

GKE의 에이전트 샌드박스는 Kubernetes 커스텀 리소스(Sandbox, SandboxClaim, SandboxTemplate, SandboxWarmPool)를 통해 관리되는 전용 스테이트풀(Stateful) Kubernetes 포드에서 각 에이전트를 실행합니다. SandboxWarmPool 리소스는 특정 SandboxTemplate 리소스에 대해 실행 중인 포드가 있는 사전 준비된 Sandbox 리소스를 유지하므로 컨트롤러가 준비된 Sandbox 리소스와 실행 중인 포드를 1초 이내에 클레임에 할당할 수 있습니다.

각 에이전트에 전용 포드가 필요하거나 워크로드에 다음 요구사항이 있는 경우 Agent Sandbox를 선택하세요.

  • 지속적으로 활성 상태인 에이전트 및 단일 포드 서비스: 유휴 기간이 자주 발생하지 않는 워크로드 또는 StatefulSet 복잡성 없이 안정적인 호스트 이름과 스토리지가 필요한 영구 세션(예: 클라우드 개발 환경 또는 Jupyter Notebook)입니다.
  • 하드웨어 가속기(GPU 또는 TPU): 샌드박스 내에서 GPU 또는 TPU에 직접 액세스해야 하는 에이전트입니다. 가속기는 지원되는 GPU 모델 및 TPU 버전의 gVisor 런타임에서만 작동합니다. 마이크로 VM은 GPU 또는 TPU를 지원하지 않습니다.
  • 전체 Kubernetes PodSpec, Arm 노드 또는 GKE Autopilot: 커스텀 사이드카 또는 초기화 컨테이너, 표준 Kubernetes API 및 도구(예: kubectl 명령어, 역할 기반 액세스 제어, 기존 컨트롤러), Arm CPU 또는 GKE Autopilot 클러스터가 필요한 워크로드입니다.

ID, 사용자 인증 정보, 네트워크 정책

각 에이전트는 전용 포드에서 실행되므로 GKE용 워크로드 아이덴티티 제휴 또는 에이전트 ID(프리뷰)를 사용하여 포드에 Google CloudIdentity and Access Management(IAM) 권한을 부여할 수 있습니다. 두 옵션 모두 포드 생성 시 ID를 포드의 Kubernetes ServiceAccount에 바인딩하므로 SandboxWarmPool 리소스의 모든 사전 준비된 포드가 동일한 ID를 공유합니다. 에이전트 또는 테넌트별로 ID를 격리하려면 ID별로 별도의 SandboxWarmPool 리소스를 유지하거나 웜 풀 없이 필요에 따라 Sandbox 리소스를 만듭니다.

표준 Kubernetes 보안 비밀 객체 또는 CSI 볼륨을 사용하여 보안 비밀을 포드에 마운트합니다. 에이전트 샌드박스에는 샌드박스 외부 사용자 인증 정보 삽입을 위한 게이트웨이가 포함되어 있지 않습니다. 전송 중인 사용자 인증 정보를 삽입하려면 자체 외부 프록시를 배포합니다.

컨트롤러는 각 SandboxTemplate 리소스에 대해 기본 거부 NetworkPolicy 객체를 만듭니다. 템플릿 없이 직접 만드는 샌드박스 리소스의 경우 자체 NetworkPolicy 객체를 만듭니다. 표준 GKE 네트워크 제어를 사용하여 트래픽을 제한합니다.

  • 레이어 4: GKE 네트워크 정책(NetworkPolicy 객체)을 사용하여 포드 간 및 IP 트래픽을 제한합니다.
  • 레이어 7: FQDN 네트워크 정책(FQDNNetworkPolicy 객체)을 사용하여 승인된 도메인에 대한 아웃바운드 연결을 제한합니다.

유휴 정지, 포드 스냅샷, 스토리지

유휴 에이전트의 포드는 애플리케이션이 spec.operatingMode 필드를 Suspended로 설정하여 샌드박스 리소스를 정지할 때까지 예약된 CPU 및 메모리를 유지합니다. 샌드박스 리소스를 정지하면 영구 볼륨을 유지하면서 포드가 삭제됩니다. 포드를 삭제하면 메모리 내 데이터와 컨테이너 파일 시스템 변경사항이 삭제됩니다. Cloud Storage에서 해당 상태를 저장하고 복원하려면 에이전트를 정지하기 전에 GKE 포드 스냅샷을 만듭니다. 포드 스냅샷에는 gVisor 런타임이 필요하며 마이크로 VM 또는 TPU는 지원되지 않습니다. 스냅샷에서 포드를 복원하는 데 약 3~5초가 걸립니다.

포드 스냅샷 이외의 영구 스토리지를 사용하려면 다음 옵션 중에서 선택하세요.

  • Filestore: 공동작업 작업공간을 위해 여러 샌드박스 포드에 공유 ReadWriteMany(RWX) PersistentVolumeClaim(PVC)을 마운트합니다. 자세한 내용은 AI 에이전트 워크로드용 스토리지 선택을 참조하세요.
  • Hyperdisk: 격리된 포드 디스크에는 Google Cloud Hyperdisk Balanced(ReadWriteOnce 액세스 모드)를 사용하고, 노드 간에 읽기 전용 데이터 세트 또는 모델 가중치를 공유하려면 Google Cloud Hyperdisk ML(ReadOnlyMany 액세스 모드)을 사용합니다. 자세한 내용은 AI 에이전트 워크로드용 스토리지 선택 및 GKE용 Hyperdisk 정보를 참조하세요.

Agent Substrate와 Agent Sandbox 비교

다음 표에는 GKE의 Agent Substrate와 GKE의 Agent Sandbox 간의 아키텍처 차이점이 요약되어 있습니다.

측정기준 GKE의 Agent Substrate(액터 기반) GKE의 Agent Sandbox(포드 기반)
Recommendations AI 에이전트 워크로드 자주 정지 및 재개되는 대부분의 스테이트풀(Stateful) CPU 기반 에이전트 지속적으로 활성 상태인 에이전트, GPU 또는 TPU 워크로드, 커스텀 PodSpec, Arm 노드 또는 GKE Autopilot
예약 단위 여러 작업자가 웜 포드 풀(WorkerPool)을 공유합니다. 에이전트당 전용 포드 1개(샌드박스)
샌드박스 런타임 gVisor 및 Cloud Hypervisor 마이크로 VM(WorkerPool 포드 내에서 관리됨) GKE Standard의 gVisor 및 마이크로 VM(노드 풀 또는 ComputeClass에서 GKE Sandbox가 사용 설정됨) 또는 GKE Autopilot의 gVisor(기본적으로 사용 설정됨)
웜 풀링 작업자 템플릿 및 컨테이너 이미지 간에 공유되는 WorkerPool 리소스 템플릿 및 컨테이너 이미지당 SandboxWarmPool 리소스 1개
컨트롤 플레인 경로 kube-apiserver 구성요소 외부의 전용 컨트롤 플레인 및 데이터베이스 표준 Kubernetes 컨트롤러, kube-apiserver, etcd
유휴 리소스 처리 유휴 상태의 액터를 정지하면 작업자 CPU 및 메모리가 해제됩니다. 유휴 샌드박스 리소스를 정지하면 포드가 삭제되고 영구 볼륨이 유지됨
상태 체크포인트 gVisor 및 마이크로 VM에 내장된 Cloud Storage 스냅샷, 1초 이내에 복원 GKE 포드 스냅샷(gVisor에서만 지원됨), 3~5초 내에 복원
지원되는 클러스터 모드 GKE Standard(버전 1.37 이상, x86 노드) GKE Standard 및 GKE Autopilot
하드웨어 가속기 지원되지 않음(CPU 전용 워커 노드) gVisor 런타임에서만 지원되는 GPU 및 TPU
Kubernetes PodSpec 지원 ActorTemplate 및 WorkerPool 리소스 간에 분할된 하위 집합 사이드카 및 초기화 컨테이너를 포함한 전체 PodSpec
네트워킹 액터별 mTLS 터널이 있는 기본 제공 Envoy 인그레스 및 이그레스 게이트웨이 Kubernetes 서비스, NetworkPolicy, FQDNNetworkPolicy
ID 모델 액터별 SPIFFE X.509 인증서 및 JWT GKE용 워크로드 아이덴티티 제휴 또는 에이전트 ID(프리뷰)를 사용하는 포드 ServiceAccount, 웜 풀에서 공유됨
Secret Manager 이그레스 게이트웨이에서 아웃바운드 요청에 삽입됨 Kubernetes 보안 비밀 객체 또는 CSI 볼륨을 사용하여 포드에 마운트됨

샌드박스 런타임 선택

에이전트 기판과 에이전트 샌드박스 모두 Cloud Hypervisor microVM 또는 gVisor를 사용하여 호스트 노드에서 신뢰할 수 없는 코드를 격리하지만 각 모델에서 런타임을 다르게 구성합니다.

  • 에이전트 기판: WorkerPool 리소스에서 런타임을 선택합니다. 에이전트 서브스트레이트는 노드 수준 GKE Sandbox 기능을 사용하는 대신 WorkerPool 포드 내에서 자체 microVM 및 gVisor 런타임을 관리합니다. sandbox.gke.io/runtime 노드 taint로 인해 WorkerPool 포드가 예약되지 않으므로 에이전트 기판 워커 노드 풀에서 GKE Sandbox를 사용 설정하지 마세요.
  • 에이전트 샌드박스: SandboxTemplate 리소스의 포드 템플릿에서 runtimeClassName 필드를 gvisor 또는 microvm로 설정합니다. GKE Standard에서는 노드 풀 또는 커스텀 ComputeClass에서 GKE Sandbox를 사용 설정합니다. GKE Autopilot에서는 gVisor가 기본적으로 제공되며 마이크로 VM은 지원되지 않습니다.

두 런타임 모두 신뢰할 수 없는 코드와 헤드리스 브라우저를 실행합니다.

  • MicroVMs: 각 샌드박스는 전용 게스트 Linux 커널이 있는 경량 가상 머신에서 실행됩니다. VM 수준 격리, 전체 Linux syscall 호환성 또는 멀티 컨테이너 행위자 내의 컨테이너별 CPU 및 메모리 한도가 필요한 경우 microVM을 선택합니다.
  • gVisor: 각 샌드박스는 Linux 시스템 호출을 가로채고 필터링하는 사용자 공간 커널에서 실행됩니다. 더 빠른 콜드 스타트, 더 낮은 메모리 오버헤드 또는 더 광범위한 Compute Engine 머신 지원(GPU, TPU, Arm 노드, Agent Sandbox의 GKE Autopilot 포함)을 원한다면 gVisor를 선택하세요.

다음 표에서는 GKE의 마이크로 VM과 gVisor를 비교합니다.

기능 MicroVMs gVisor
커널 액세스 전체 Linux 커널 Linux 커널 syscall의 하위 집합
격리 수준 전용 게스트 커널을 사용한 하드웨어 가상화 사용자 공간 커널의 Syscall 가로채기
CPU 및 메모리 오버헤드 Agent Substrate의 액터별 VMM 메모리 GKE Sandbox에서 포드당 250mCPU 및 130MiB로 고정됩니다. 기본 메모리가 적은 동적 오버헤드
시작 시간 1~2초 100밀리초 미만
GKE 노드 구성 중첩 가상화가 있는 GKE Standard 노드(두 모델 모두) 또는 x86 베어메탈 노드(에이전트 기판만 해당) GKE Standard 노드 풀(두 모델 모두) 또는 GKE Autopilot 노드(Agent Sandbox만 해당)
노드 이미지 지원 에이전트 기판의 Container-Optimized OS(cos_containerd) GKE Sandbox의 Container-Optimized OS(cos_containerd) 또는 Ubuntu Container-Optimized OS(cos_containerd)만 해당
머신 유형 호환성 중첩된 가상화를 지원하는 x86 머신 시리즈 및 x86 베어메탈(E2 또는 Arm에서 지원되지 않음) Agent Substrate의 비혼합 CPU x86 시리즈 에이전트 샌드박스의 대부분의 x86, Arm, 가속기 시리즈
가속기 지원 지원되지 않음 지원되는 GPU 모델 및 TPU 버전(Agent Sandbox만 해당)
사용 사례
  • 자율 코딩 및 브라우저 에이전트
  • 전체 Linux 커널 호환성이 필요한 워크로드
  • 시스템 호출이 빈번한 높은 I/O 워크로드
  • Python, Node.js, Go, Java 또는 Rust의 신뢰할 수 없는 애플리케이션
  • CPU, GPU 또는 TPU 추론 및 코드 실행 샌드박스
  • 웹 프런트엔드, 캐시, 프록시

이러한 격리 기술에 대한 자세한 내용은 GKE Sandbox를 참조하세요.

다음 단계