mirror of
https://github.com/sredevopsorg/deepseek-kubernetes-sandbox.git
synced 2026-11-03 01:13:24 +00:00
96d3030a49
Update AGENT_SANDBOX_VERSION to v1.0.8 and the docs that quote the control-plane pin (example prerequisites, architecture, versioning table, minimal-single-tenant template comment, platform skill). The v1.0.8 release adds only one CRD field, spec.failedPodPolicy (Sandbox and SandboxTemplate, enum Retain|Recreate, default Retain), so the existing manifests keep their behavior: Retain is the default and neither the API version (v1beta1) nor any field we set changed. All five custom resources still validate against the v1.0.8 CRD schemas. Behavior changes in the controller itself (bounded MCP output, router kustomization, creation-latency metric timing) do not affect the platform because it uses neither the sandbox-router nor the MCP server. Co-authored-by: SREDevOpsAgents <agents@sredevops.org>
Examples
Every implementation in this repository is a self-contained example: one
directory, plain kubectl, an end-to-end README, and a cleanup command.
Examples consume the main DSH Web image; they are
reference material, not libraries.
| Example | What it demonstrates | Needs |
|---|---|---|
examples/dsh-agents-as-a-service/ |
The full multi-tenant platform pattern: one SandboxTemplate with per-user PVCs, a warm pool, one ~10-line SandboxClaim per user, suspend-when-idle / wake-on-return, and a browser gateway with signup, HttpOnly sessions, an HTTP + WebSocket proxy and two exposure variants (Ingress, or Gateway API + GitHub SSO). |
agent-sandbox with extensions; kind for the e2e script. |
examples/minimal-single-tenant/ |
The smallest useful setup: a single SandboxTemplate and one SandboxClaim, no gateway — reach DSH Web with a launch-token URL through kubectl port-forward. |
agent-sandbox with extensions. |
The multi-tenant example also documents opt-in gVisor, nodeSelector,
NetworkPolicy and extra provider-key hardening in
optional hardening.
The example contract (short version)
Full rules: docs/examples.md. scripts/check-examples.sh
enforces the layout, and make check runs it.
examples/<name>/
+-- README.md # walkthrough: prerequisites, steps, troubleshooting, cleanup
+-- manifests/ # NN-*.yaml, applied with plain kubectl
| +-- optional/<feature>/ # optional opt-in manifests...
| +-- optional/README.md # ...required whenever optional/ exists
| +-- exposure/<variant>/ # optional per-variant manifests...
| +-- exposure/README.md # ...required whenever exposure/ exists
+-- scripts/ # optional executable, idempotent, self-cleaning *.sh
+-- docs/ # optional architecture/ADR material
+-- <component>/ # optional component with Dockerfile + README + tests
- Secrets never ship populated: use
*.yaml.examplefiles with placeholders. - Manifests are numbered (
00-,10-, ...) and read as an ordered walkthrough. - Component images are published nested below the main image:
<registry>/<owner>/<repo>/<example>/<component>. - Every example must be listed above with its literal
examples/<name>/path. - Scripts under
scripts/must be executable, idempotent and clean up after themselves.
Running an example
# e.g. the multi-tenant platform example
kubectl apply -f examples/dsh-agents-as-a-service/manifests/
# or run the whole walkthrough (kind + agent-sandbox required) and let it clean up
examples/dsh-agents-as-a-service/scripts/e2e-kind.sh
kubectl apply -f manifests/ is non-recursive: optional/ and exposure/
subdirectories are applied explicitly. Each example README has the exact
prerequisites, optional hardening, exposure options and teardown.