nicolas-georger/deepseek-kubernetes-sandbox
1
0
Fork 0
mirror of https://github.com/sredevopsorg/deepseek-kubernetes-sandbox.git synced 2026-11-03 01:13:24 +00:00
Code Projects Releases Activity
Files
96d3030a4912856deaac5a5bc3d27c80fa41f3eb
deepseek-kubernetes-sandbox/examples/README.md
SREDevOps.org Agent 3e9ba38fc1 feat(example): add optional gVisor, nodeSelector, NetworkPolicy and provider keys (#21) 
Add opt-in hardening to the agents-as-a-service example:
- commented runtimeClassName/nodeSelector fields for sandboxes and Deployments
- optional sandbox NetworkPolicy plus exposure-variant policies
- optional dsh-provider-keys-extra Secret for extra provider keys
- docs/optional-hardening.md with verification, caveats and rollback

The base walkthrough stays portable; no gateway code, routes or auth changed.

Co-authored-by: SREDevOpsAgents <agents@sredevops.org>
2026-10-26 10:03:30 -03:00

3.0 KiB
Raw Blame History

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.example files 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.

View Git Blame Copy Permalink