Kubernetes SIG Apps, AI 에이전트용 Agent Sandbox 프로젝트 공개
핵심 내용
v0.4.2 버전으로 공개된 Agent Sandbox는 StatefulSet 대비 운영 복잡도를 낮추고 커널 격리를 지원한다.
자세히 보기
자율형 AI 에이전트(AI v2)는 stateful 특성과 외부 코드 실행으로 인해 기존 Kubernetes 리소스인 StatefulSet 조합으로는 운영 복잡도가 급격히 상승한다. 이를 해결하기 위해 Kubernetes SIG Apps는 격리되고 상태를 유지하는 싱글톤 워크로드 관리를 위한 Agent Sandbox 프로젝트를 공개했다.
Namespace 격리의 한계와 커널 보안
Namespace는 API 레벨의 논리적 분리일 뿐, 컨테이너 내부 코드를 신뢰한다는 전제 위에 존재한다. AI 에이전트가 외부에서 유입된 임의의 코드를 실행할 경우, 커널 취약점을 exploited하여 호스트를 탈출할 수 있다. Agent Sandbox는 이를 방지하기 위해 gVisor 또는 Kata Containers 같은 커널 격리 런타임을 선택적으로 사용할 수 있도록 설계되었다. 기본 런타임은 runc이며, 비신뢰 코드 실행 시에만 runtimeClassName으로 강화된 격리를 지정한다.
Agent Sandbox 리소스 구조
Agent Sandbox는 크게 Core API와 Extensions API로 구성된다.
- Core API: 단일 에이전트 실행 환경인 Sandbox와 재사용 가능한 정의 템플릿인 SandboxTemplate을 포함한다. Sandbox는 고정 DNS 호스트명과 Scale-to-Zero 기능을 제공한다.
- Extensions API: 콜드 스타트 지연을 제거하기 위한 SandboxWarmPool과 즉시 할당 요청을 위한 SandboxClaim을 포함한다. WarmPool은 미리 Sandbox를 생성해 대기시켜 Pod 시작 오버헤드를 줄인다.
운영 방식 및 주의사항
기존 StatefulSet 방식은 StatefulSet, Service, PVC 3개 리소스를 동기화해야 하지만, Agent Sandbox는 SandboxTemplate과 WarmPool을 통해 더 간결하게 관리할 수 있다. 현재 최신 릴리스는 v0.4.2이며 v1alpha1 단계의 오픈소스 프로젝트다. Kubernetes 1.35 기준으로 빌드되어 1.32 미만 클러스터에서는 동작이 보장되지 않으며, gVisor/Kata 런타임이 설치되지 않은 노드에서 해당 런타임을 지정하면 Pod가 Pending 상태로 멈출 수 있다.
이 한국어 요약은 AI가 자동으로 만들었습니다. 원문의 주장과 맥락은 원문에서 확인해 주세요. 저작권은 원저작자에게 있습니다.