개요

결론부터

kagent를 설치하는 데서 멈추지 않고 우리 backend가 Agent를 배포·관찰·호출하고, 온프렘 운영과 Substrate 채택 여부까지 증거로 판정한다

kagent는 Agent와 model·tool 연결을 Kubernetes resource로 다룬다. 이 덱은 전용 kind 클러스터를 작은 실험실로 삼아 Agent와 MCP tool을 만들고, dashboard·CLI·A2A endpoint로 같은 runtime을 호출한다. 그다음 Node/TypeScript backend가 CRD를 관리하고 kagent-controller:8083으로 invoke하는 walking skeleton을 실행한다. 권한 우회와 온프렘 승격 조건을 검증한 뒤에는 같은 클러스터에 Agent Substrate를 추가해 일반 Agent와 SandboxAgent를 같은 조건에서 비교한다.

Docker·kind·kubectl의 일반 준비는 실습 환경 덱이 맡는다. kagent를 사내 포털과 권한 체계와 제품 중립 계약의 정본은 Agent 배포 플랫폼 덱이 맡는다. 이 덱은 그 설계의 핵심 가정을 실제 cluster와 backend probe로 깨뜨려 보는 companion lab이다.

실습 지도부터 보기

한 번 도는 흐름

기본 Agent·MCP·A2A
→ backend의 CRD apply·status·A2A invoke
→ Grant·RBAC·직접 우회 차단
→ 온프렘 staging 승격 조건
→ 같은 cluster의 Substrate 설치·SandboxAgent A/B
→ 맨 Kubernetes 기준선까지 포함한 채택 판정
→ 전체 cleanup

9장 BYO와 1112장 Substrate는 선택 경로다. 다만 Substrate를 실행한다면 반드시 78장의 일반 Agent backend 경로를 먼저 완주한다. 그래야 runtime 차이와 backend 계약 차이를 구분할 수 있다.

구성

1. 0~2장안전한 시작과 첫 호출

   전용 context · pinned 설치 · sample Agent · model과 tool evidence

   다른 cluster를 건드리지 않고 재현 가능한 기준선을 어떻게 만드나

2. 3~6장Agent·MCP·A2A와 진단

   명시적 runtime · tool allowlist · controller A2A route · condition과 log

   선언부터 실제 호출까지 어느 checkpoint에서 실패했는가

3. 7~8장Backend와 권한 경계

   Node/TypeScript · CRD apply·status · A2A invoke · Grant·RBAC·우회 차단

   우리 backend를 유일한 관리·호출 입구로 만들려면 무엇이 필요한가

4. 9~10장코드형과 온프렘 승격

   BYO image의 kind 배포 · external PostgreSQL · HA · namespace scope · upgrade

   로컬 데모를 비운영 온프렘 staging으로 옮길 때 무엇을 바꿔야 하나

5. 11~12장같은 cluster의 Substrate A/B

   Substrate control/data plane · WorkerPool · SandboxAgent · suspend·restore 관찰

   환경 차이를 제거하고 상주 Agent 대비 가치와 비용을 어떻게 측정하나

6. 13장채택 판정

   맨 Kubernetes · kagent · kagent+Substrate scorecard와 중단 조건

   기능 목록이 아니라 어떤 실행 증거로 도입 여부를 결정하나

7. 14장정리

   backend·BYO·SandboxAgent·Substrate를 포함한 선택 삭제와 cluster 전체 삭제

   실험의 blast radius를 끝까지 닫았는가

완료 기준

• kind-kagent-lab context에만 kagent가 설치되어 있다.
• Agent의 Accepted=True, Ready=True를 dashboard 밖에서도 확인한다.
• 조회 전용 Agent가 실제 cluster resource를 MCP tool로 읽는다.
• 같은 Agent의 card를 A2A endpoint에서 읽고 CLI로 호출한다.
• 잘못된 modelConfig를 condition과 controller log로 설명한다.
• Node/TypeScript backend가 Kubernetes API로 Agent 상태를 읽고 controller A2A route로 호출한다.
• 허용·거부 사용자의 Grant, backend ServiceAccount RBAC, controller 8083 직접 우회 차단을 각각 검증한다.
• kind values와 온프렘 staging values의 차이를 external PostgreSQL·HA·namespace scope·CA·registry·rollback으로 설명한다.
• Substrate를 선택했다면 일반 Agent와 SandboxAgent의 시작·유휴·복원·추가 구성 요소를 같은 cluster에서 비교한다.
• 맨 Kubernetes 기준선까지 포함한 scorecard를 남기고 전용 cluster를 삭제한다.

0. 실습 지도와 안전 경계클러스터·context·비밀·tool 권한을 먼저 고정하고 시작한다.