14. 실습 정리와 다음 단계

결론부터

cleanup은 증거를 먼저 보존하고 정확한 소유 범위를 확인한 뒤 resource-only와 전용 cluster 삭제 중 하나를 선택하는 마지막 운영 실습이다

이 장에서 처음 나오는 말4개

resource cleanupSelective Cleanup

kagent·Substrate 설치는 남기고 이 덱이 만든 Agent·MCP·RBAC만 지우는 정리다.

cluster cleanupEnvironment Cleanup

전용 kind cluster와 그 안의 Secret·session·snapshot·workload를 통째로 지우는 정리다.

evidence retention

삭제 전에 측정값·version·실패 결과를 Secret 없이 decision record에 남기는 절차다.

uninstallProduct Uninstall

공유 cluster에서 chart·CRD·상태 저장소를 의존성 순서에 맞춰 제거하는 별도 변경 작업이다.

삭제 전에 증거부터 남기기

/tmp의 원본에는 Helm value·내부 주소·응답이 들어갈 수 있다. 그대로 Git에 넣지 말고 13장의 decision record에 필요한 숫자와 판정만 옮긴다.

kubectl config current-context
helm -n kagent list
helm -n ate-system list
kubectl -n kagent get agent,sandboxagent,mcpserver,workerpool
kubectl -n kagent get pods
kubectl -n ate-system get pods
ls -l /tmp/kagent-before-substrate-* /tmp/kagent-after-substrate-*

확인할 evidence는 다음과 같다.

• Kubernetes·kagent·Substrate version과 Helm release revision
• backend SSA 재실행 전후 Agent UID, Ready·A2A allow/deny 결과
• 일반 Agent와 SandboxAgent의 Ready·invoke·restore·burst·worker failure 측정값
• staging에서만 검증한 CNI packet deny, 외부 PostgreSQL·object storage·rollback 결과
• 채택·제한 채택·보류 결론, owner와 재개 조건

Secret value, browser token, model prompt 원문, tool input 전체, snapshot 파일은 decision record에 복사하지 않는다.

어느 정리를 할지 선택하기

다음 행동	선택
backend·Agent 실습을 다시 한다	선택 A — 이 덱의 custom resource만 삭제
Substrate 비교를 더 한다	선택 A — fixture만 삭제하고 chart·WorkerPool 유지
실습을 끝낸다	선택 B — 전용 kagent-lab kind cluster 전체 삭제
공유 staging에서 제품을 제거한다	이 장의 명령을 쓰지 않고 승인된 uninstall change를 별도로 계획

port-forward와 dashboard terminal은 각각 Ctrl+C로 종료한다. tunnel 종료는 Kubernetes resource 삭제가 아니다.

선택 A — 이 덱의 resource만 지우기

--ignore-not-found는 선택 장을 건너뛴 경우만 허용하기 위한 것이다. 다른 이름의 resource를 넓은 label이나 namespace 전체로 지우지 않는다.

1. 대상을 먼저 조회한다

   kubectl -n kagent get \
     agent/lab-reader agent/simple-fetch-agent agent/backend-reader \
     agent/lab-byo agent/resident-echo \
     sandboxagent/sandbox-echo \
     mcpserver/mcp-website-fetcher \
     --ignore-not-found
   kubectl -n kagent get serviceaccount,role,rolebinding,networkpolicy \
     --ignore-not-found

2. 실습 Agent·SandboxAgent·MCP를 정확한 이름으로 지운다

   kubectl -n kagent delete \
     agent/lab-reader agent/simple-fetch-agent agent/backend-reader \
     agent/lab-byo agent/resident-echo \
     sandboxagent/sandbox-echo \
     mcpserver/mcp-website-fetcher \
     --ignore-not-found

   SandboxAgent를 먼저 지우고 UI의 Substrate inventory에서 관련 actor·snapshot lifecycle이 정리되는지 본다. object storage의 실제 삭제·retention은 production policy와 controller 동작을 별도로 검증해야 한다.

3. backend 경계용 resource와 선택 BYO Secret을 지운다

   kubectl -n kagent delete \
     serviceaccount/agent-backend role/agent-backend rolebinding/agent-backend \
     networkpolicy/controller-approved-callers secret/lab-byo-model \
     --ignore-not-found

4. demo control plane과 Substrate를 남겼는지 확인한다

   kubectl -n kagent get agents,sandboxagents,mcpservers,workerpools
   kubectl -n kagent get pods
   kubectl -n ate-system get pods

broken-model-agent는 6장에서 이미 삭제했어야 한다. 남아 있다면 kubectl -n kagent get agent broken-model-agent로 정확히 확인한 뒤 그 이름만 삭제한다. default-model-config나 chart가 만든 sample Agent는 선택 A에서 지우지 않는다.

선택 A는 Substrate chart·CRD·Valkey·RustFS와 kagent-default WorkerPool을 남긴다. 제품 자체를 제거하려고 chart와 CRD를 수동으로 섞어 지우지 않는다.

선택 B — 전용 kind cluster 전체 지우기

실습 종료의 기본 경로다. cluster 안의 kagent resource·Secret·session·database·Substrate snapshot이 함께 사라지며 복구할 수 없다. 13장의 판정 증거를 보존한 뒤 실행한다.

1. 현재 context와 정확한 cluster 이름을 확인한다

   kubectl config current-context
   kind get clusters

   기대값은 context kind-kagent-lab, cluster 이름 kagent-lab이다.

2. 그 전용 cluster만 삭제한다

   kind delete cluster --name kagent-lab

3. 목록과 context에서 사라졌는지 확인한다

   kind get clusters
   kubectl config get-contexts

4. 현재 shell의 model credential을 해제한다

   unset OPENAI_API_KEY LITELLM_API_KEY LITELLM_BASE_URL LITELLM_MODEL

kind node image와 container는 cluster 삭제로 정리되지만 host의 kagent·kind·kubectl CLI와 Docker cache는 남는다. 여러 실습이 공유할 수 있으므로 이 장에서 자동 삭제하지 않는다.

/tmp/kagent-backend-probe와 /tmp/kagent-lab-byo도 자동으로 지우지 않는다. 필요한 code를 옮기고 credential file이 없음을 확인한 뒤, 더 필요 없을 때만 그 두 정확한 경로를 로컬에서 삭제한다.

공유 staging에서 uninstall은 별도 변경이다

공유 cluster의 uninstall은 다음 의존성을 가진다.

publication 차단
→ Agent·SandboxAgent·actor 정리와 snapshot retention 확인
→ kagent의 Substrate integration·WorkerPool 정리
→ kagent·Substrate chart 제거
→ 남은 CR·finalizer·PVC·외부 PostgreSQL/object storage 확인
→ 마지막에만 CRD 제거 여부 결정

chart version에 따라 finalizer와 generated resource가 달라질 수 있다. 그래서 이 덱은 helm uninstall·CRD 삭제 명령을 복사 가능한 한 줄로 제공하지 않는다. 현재 pinned version의 공식 uninstall, Helm release ownership, backup·rollback과 다른 tenant 영향까지 검토한 승인 change로 수행한다.

이번 실습에서 얻은 판단 기준

1. backend의 관리 port는 Kubernetes CRD, invocation port는 controller A2A다.
2. dashboard·CLI는 탐색 도구이고 production backend 계약이 아니다.
3. model·prompt·tool allowlist·runtime은 서로 다른 변경·권한 경계다.
4. MCP는 Agent가 tool을 부르는 안쪽 계약이고 A2A는 client가 Agent를 부르는 바깥쪽 계약이다.
5. Accepted, Ready, Agent Card, invoke 성공은 각각 다른 checkpoint다.
6. Kubernetes RBAC, 사용자 Grant, session ownership, tool action policy는 서로 대체하지 않는다.
7. BYO는 image·dependency·protocol·Secret·공급망 책임을 application team으로 넓힌다.
8. kind 성공은 외부 PostgreSQL·HA·CNI policy·사내 CA·registry·rollback의 staging 증거가 아니다.
9. Substrate는 필수가 아니라 idle 밀도·gVisor 요구가 restore 지연과 새 운영비보다 클 때 고르는 runtime이다.
10. AgentHarness는 coding workspace 요구가 생길 때 별도 신뢰 경계로 검토한다.

공식 Examples에서 더 해볼 것

kagent 공식 Examples는 A2A·agentgateway·외부 MCP client, ADK·CrewAI·LangGraph BYO, 문서 Agent, Slack·Discord·Telegram, Skills·HITL, Agent Harness·Substrate를 end-to-end walkthrough로 모아 둔 catalog다. 절차와 최신 manifest는 공식 문서를 정본으로 보고, 이 덱에서는 0~14장을 끝낸 뒤 실제 수요 하나만 골라 다음 실패 조건을 같이 시험한다. 별도 수요가 아직 없다면 HITL, agents via MCP, agentgateway 순서가 좋다. 8장의 권한 경계를 write 승인, 외부 client 호출, model egress 정책 순으로 확장할 수 있다.

수요	공식 실습	이 덱에서 추가할 실패 조건
write tool을 연다	Human-in-the-Loop	requireApproval에서 빠진 write tool은 즉시 실행된다. 거절 후 미실행을 확인하고, HITL이 RBAC·Grant·action deny를 대체하지 않음을 시험한다.
Cursor·Claude 같은 MCP client에서 Agent를 부른다	Using kagent agents via MCP	local endpoint 포트가 엇갈리면 port-forward의 왼쪽 포트를 기준으로 맞춘다. 8083:8083이면 http://localhost:8083/mcp다. list_agents·invoke_agent를 노출하므로 controller를 공개 endpoint로 바로 열지 않는다.
model egress에 정책을 넣는다	Using agentgateway with kagent	gateway는 model 호출 경로를 다루지 A2A invocation ACL과 MCP action 권한을 막지 않는다. Agent의 provider 직접 egress를 차단하고 rate limit·guardrail·audit policy의 target과 bypass를 각각 검증한다.
행동 절차를 재사용한다	Add skills to agents	skill을 로드하면 bash·file read/write/edit tool이 추가되고, 공식 예제 Agent는 k8s_apply_manifest도 허용한다. latest·insecureSkipVerify는 전용 lab에만 두고, digest pin·서명·ServiceAccount·approval을 검증한다. skill image는 파일만 나르므로 script의 runtime·package는 Agent image에 있어야 한다. 일부러 빠뜨려 Agent가 script를 우회하고 결과를 직접 지어내지 않는지 확인한다.
특정 framework를 이식한다	ADK·CrewAI·LangGraph 중 하나	세 개를 다 돌리지 말고 실제 후보만 고른다. image digest·Secret·A2A port·health contract와 framework state/checkpoint의 session ownership·retention을 깨뜨려 본다.
chat channel을 입구로 쓴다	Slack·Discord·Telegram 중 하나	bot token 최소 scope, webhook·event 서명과 replay, workspace·channel·user identity를 Grant에 매핑한다. chat 입구가 controller 8083 직접 우회가 되지 않게 한다.
coding workspace가 필요하다	Agent Harness	OpenClaw·Hermes의 shell·source credential·workspace·Slack token과 shared actor snapshot을 하나의 신뢰 경계로 본다. 장기 session의 WorkerPool slot·snapshot 보존·삭제·복원을 따로 측정한다.

함정 — skill 예제의 local registry 주소는 그대로 동작하지 않는다

Add skills to agents 예제는 registry를 docker run --name local-registry로 띄우라고 안내하지만, 몇 줄 뒤 Agent manifest는 kind-registry:5000/...을 참조한다. 이름이 서로 다르고, 평범한 docker run이 붙는 기본 bridge network는 kind node가 있는 kind network가 아니다. 도커는 사용자 정의 network 안에서만 컨테이너 이름과 alias를 해석하므로 node에서 kind-registry가 풀리지 않는다. kind-registry라는 이름은 kind 공식 local registry 레시피의 관례이고, 예제는 그 레시피를 이미 돌렸다고 전제한 채 간단한 docker run을 준다.

host에서 push할 때의 localhost:5000과 manifest가 참조하는 이름이 다른 것 자체는 정상이다. image를 당기는 주체가 host가 아니라 cluster 안이기 때문이다. 이미 push한 registry를 살리려면 컨테이너를 다시 만들지 말고 network alias로 붙인다.

docker network connect --alias kind-registry kind local-registry

alias는 해당 network 안에서만 통하는 추가 이름이라 다른 곳에서는 원래 이름이 그대로 남는다. 확인할 것이 하나 더 있다. node containerd의 insecure registry 설정 없이 skills.insecureSkipVerify만으로 fetch가 된다면, skill artifact는 node가 일반 image처럼 pull하는 것이 아니라 kagent가 직접 가져온다는 뜻이다. 사내 private CA registry에서는 node에 CA를 배포하는 것만으로 부족할 수 있으므로 10장의 registry·CA preflight에서 두 경로를 나눠 시험한다.

5장은 공식 A2A 예제의 Agent Card·controller 8083·CLI 호출을 이미 포함하고, 11~12장은 공식 Substrate walkthrough을 A/B 비교로 확장한다. 두 예제는 추가 실습으로 중복하지 않는다.

다음에 이어갈 길

• 사내 platform 도입 판정: Agent 배포 플랫폼 — 단계적 도입
• 온프렘 배포 기반: 온프렘 Kubernetes
• model gateway와 비용·권한: LiteLLM
• LLM trace와 평가: Langfuse

참고 자료

• kagent uninstall — release별 제거 순서와 전체 resource 삭제 경고
• kagent Agent Substrate walkthrough — 전용 kind 실습의 cluster cleanup
• kind Quick Start — 이름 있는 cluster 삭제

Agent 배포 플랫폼 — 단계적 도입이 덱의 backend·보안·Substrate 측정값을 default target의 공통 acceptance test와 decision record로 가져간다.