Kubernetes
The Kubernetes service gives your simulation a real, lightweight Kubernetes control plane (kube-apiserver + etcd, no kubelet) rather than a hand-rolled REST mock. Your agent investigates it with genuine kubectl and client-go — so SRE tools like HolmesGPT and K8sGPT , which perform real API discovery and list/watch, work unmodified.
Enable the service
services:
- name: kubernetesThat’s all. At startup Veris boots the control plane, writes a kubeconfig, and exports KUBECONFIG=/tmp/veris/kubeconfig to your agent (the same way postgres injects DATABASE_URL). Any tool that honours KUBECONFIG — kubectl, client-go, HolmesGPT, K8sGPT — connects with no extra config.
The Kubernetes binaries (kube-apiserver, etcd, kubectl) are not baked into the base image. They are provisioned into your image at build time only when you request the kubernetes service, keeping the base image lean for everyone else.
How seeding works
Scenario “initial state” is expressed as ordinary Kubernetes manifests. From the scenario brief, Veris authors the cluster state — Deployments, Pods, Services, ConfigMaps, and Events — and applies them to the real apiserver. Because there is no kubelet, pod and deployment status (CrashLoopBackOff, OOMKilled, ImagePullBackOff, degraded rollouts, …) is injected directly via the /status subresource. The result is concrete, deterministic ground truth your graders can assert against:
$ kubectl get pods -n payments
NAME READY STATUS RESTARTS AGE
payments-api-7c9f-abcde 0/1 CrashLoopBackOff 7 5mThere is no LLM in the read path — every kubectl get / describe / discovery / watch is served by the genuine apiserver, so responses are exactly what a real cluster returns.
What’s supported
Core read-investigation surface: Namespaces, Deployments, Pods (with rich failure status), Services, ConfigMaps, and Events, plus full API discovery (/api, /apis, OpenAPI). There is no scheduler or kubelet, so pods do not actually run — their status reflects the seeded scenario.