1.3. Kubernetes
Why does an AgentOps course use Kubernetes?
Kubernetes makes workload identity, configuration, health, persistence, scheduling, and controlled rollout explicit. kagent adds an agent-specific custom resource, while the underlying container remains runnable without the operator.
The course uses Kubernetes only after the host-level agent, tests, and gateway concepts are clear. No cluster is created in Chapter 1; the runnable platform path begins in Chapter 6.
Why use k3d locally?
k3d runs lightweight k3s nodes inside containers. It is fast to create and delete and supports a local registry, which matches the image-push workflow used by Skaffold. The cluster is named local, producing the kubectl context k3d-local.
Which tools are required?
The root mise.toml pins k3d, kubectl, Helm, Helmfile, Skaffold, Kustomize, kubeconform, and kube-linter. Install them with mise install; use the container engine verified in 1.2.
How do you validate the platform prerequisites?
This checks the container engine and pinned platform CLIs without applying a manifest or creating cloud resources. The tracked configuration is infra/k3d.yaml; Chapter 6 uses the guarded root task that creates or resumes the local cluster and registry.localhost:5050.
What should you understand before Chapter 6?
- The expected kubectl context will be
k3d-local. - The registry will be available as
registry.localhost:5050. - The load balancer and Traefik are disabled; learners use temporary port-forwards.
- The cluster may be shared by other local projects, so course cleanup removes its namespace workloads rather than deleting the cluster.
- Cluster creation, kagent installation, verification, and teardown all belong to Chapter 6.
What is the Kubernetes setup checkpoint?
Continue when mise run doctor:platform passes and you can explain why no cluster has been created yet. Chapters 2-5 remain host-local; Chapter 6 is the first place where mise run cluster:start is part of the learner path.