Skip to content

docs: adr 0012 kubernetes execution backend#243

Draft
ncrmro wants to merge 3 commits into
mainfrom
docs/adr-0012-kubernetes-execution-backend
Draft

docs: adr 0012 kubernetes execution backend#243
ncrmro wants to merge 3 commits into
mainfrom
docs/adr-0012-kubernetes-execution-backend

Conversation

@ncrmro

@ncrmro ncrmro commented Jul 8, 2026

Copy link
Copy Markdown

No description provided.

ncrmro and others added 3 commits July 8, 2026 12:44
Four ways panopticon can create and deploy agents into a cluster for
long-running, dynamically scalable work (AutoML training loops, batch
jobs): a kubectl-driven KubernetesRunner behind the Runner ABC, an
in-cluster runner/operator (the M3 press-release shape), DevPod
providers as the spawn mechanism, and an agent-facing 'kubernetes'
capability that grants a scoped kubeconfig for burst Jobs.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The callback direction, control-plane lifecycle, and console reach all
hinge on where the task service runs, not on which backend option is
built; give the nuance its own section.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…hared cluster

Drop the backend survey (KubernetesRunner, operator, DevPod — future
ADRs) and commit to the smallest shape: the agent launches Jobs via a
scoped kubeconfig. Adds the multi-user isolation design: per-user
namespace template (ServiceAccount + Role/RoleBinding, ResourceQuota,
LimitRange, default-deny NetworkPolicies), short-lived tokens, and
labeling/naming conventions so users' workloads cannot collide.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant