Deploy CAIPE on Kubernetes

Lab B for CAIPE 101: Section 4 — "Deploy CAIPE on Kubernetes". Pairs with lesson L8 (deployment topology) and the L9-L13 sub-agent walkthroughs.

Beta lab — hands-on instructions, check scripts, and solve scripts are in place. Lesson videos in this section are still being recorded.

Scope. Lab A in Section 3 stood CAIPE up via the CNOE IDP Builder — a single-binary "kind plus everything wired" flow that is great for evaluation but hides the moving parts. Lab B takes the next step on the topology ladder: you provision a real Kubernetes cluster, install the CAIPE Helm chart directly, and treat CAIPE the way you would in a managed single-cluster production deployment (the topology-2 path from L8). The cluster is a kind cluster running locally on the lab VM — the chart install steps are identical on EKS, GKE, or AKS, and the closing task spells out exactly what changes when you move off kind.

Topology 2 honest scope. The chart at 0.4.10 ships under `helm/` in the upstream repo. It assumes a single Kubernetes cluster that hosts the supervisor, every enabled sub-agent, and (optionally) ArgoCD and Backstage. That is what you exercise here. The split platform-vs-workload topology (topology 3 in L8) is not on the chart's turnkey path at this release; the closing task points you at the CAIPE doc site for the current state of split-deployment guidance.

Agent validation pragmatics. Two sub-agents come up wired into the supervisor: PagerDuty (L12) and GitHub (L9-style on-call adjacent). Both agents need credentials to do real API work — a real PagerDuty API token for PagerDuty, a real GitHub PAT for any private GitHub call. Procuring those for a 90-minute lab is the wrong tradeoff, so we use synthetic credentials and exercise the wire path: the agent pod boots, the supervisor registers it on its agent card, supervisor routing reaches the agent, and the agent makes the outbound call. The outbound call will 401 against the real services (or, for GitHub against the public `octocat/Hello-World` repo, succeed unauthenticated) — that is the expected and documented behavior. In your own deployment you drop in your real tokens through the Helm values' `secrets` block or external secret references and the same wire path lights up green end to end.

Five tasks. Task 1 installs kind, kubectl, and Helm with pinned versions and brings up a two-node kind cluster (1 control plane + 1 worker). Task 2 clones the CAIPE repo at tag 0.4.10, lays down a values file that enables only the PagerDuty and GitHub agents (the rest are off to keep RAM happy on a lab VM), and runs `helm upgrade --install`. Task 3 walks the PagerDuty agent end to end: agent pod up, agent card reachable through the supervisor, prompt that exercises the PagerDuty skill at the supervisor and confirms the agent received the routed call. Task 4 does the same for the GitHub agent against the public `octocat/Hello-World` repo. Task 5 is a markdown-heavy callout that walks through what changes on EKS or AKS (IAM, ingress, persistent storage, DNS, secrets) and then tears the cluster down so the lab is replayable.

All commands are pinned. CAIPE is `0.4.10`. kind is `v0.24.0`. kubectl is `v1.30.4`. Helm is `v3.16.4`. The lab VM is `ubuntu2024` `large` — the same baseline used by Lab A so students can mentally substitute one lab for the other.