3 · Lab 1 — Your first agent¶
30 minutes · hands-on
Goal¶
Get an agent to deploy a service, verify the result itself, and fix a fault it discovers
along the way — without you touching kubectl.
The tooling¶
The agent runtime is Claude Code (or Codex) plus a Kubernetes MCP server. We are not building an agent framework — see P4.
The MCP server exposes kubectl operations as typed tools, with safety flags we'll use
properly in Lab 2.
The task¶
Give the agent this:
Deploy an Nginx web server with 3 replicas, and expose it via a NodePort.
Don't give it manifests. Don't give it commands. Just the goal.
Validation — the agent checks its own work¶
The requirement is that the agent itself verifies pods are Running and reports back.
That lives in the system prompt:
You are a Kubernetes deployment agent.
After every change you MUST:
1. Run `kubectl get pods -n <ns> -o wide`
2. Wait until all pods are Running, or until 90 seconds have passed
3. On failure: fetch `kubectl describe` and `kubectl logs`, diagnose, and fix
4. Report in plain language what you did and what the status is
You must NEVER delete resources you did not create in this session.
The planted fault¶
This introduces an ImagePullBackOff (a wrong image tag). Now ask the agent:
The deployment doesn't look healthy. Work out what's wrong and fix it.
Expected behaviour:
kubectl get pods→ seesImagePullBackOffkubectl describe pod→ reads the event:Failed to pull image ... not found- Corrects the image tag
- Verifies again that pods are
Running
Watch the tool calls, not the answer
The interesting part isn't the final message — it's the order of tool calls. That's where you see whether the agent is actually debugging or just guessing and retrying.
Reflection¶
- How many attempts did it take?
- Did it do anything you didn't ask for?
- Would you let this run without approval?
Checkpoint¶
- 3/3 Nginx pods
Running - The NodePort service answers
curl - The agent reported the fault and the fix in plain language