Skip to Content

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

.veris/veris.yaml
services: - name: kubernetes

That’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 KUBECONFIGkubectl, 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 5m

There 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.