For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt, and this page is available as Markdown at /reference/docs/decisions/0049-site-runtime-service.md.

0049 — The Kubernetes Site Runtime as the pharos-site-runtime service

Status: Proposed. Applies 0040 and 0041 to the Instantiate and Run epic's Kubernetes Site Runtime (subtask 5B). Date: 22 October 2026.

Context

The Kubernetes Site Runtime pulls its Site's commands from the Site API over HTTPS and creates Jobs, Deployments and InferenceServices in Project namespaces on behalf of their members. Its identity is a projected ServiceAccount token, which the Site API verifies through TokenReview and maps to the k8s stream. It holds no platform database or broker credentials, so it must not share a namespace with services that do. Until now, only the isolated test installations rendered its templates.

Decision

  1. The Runtime is one Argo CD service, pharos-site-runtime, in its own namespace under the services project: gitops/apps/base/pharos-site-runtime.yaml and gitops/manifests/pharos-site-runtime/overlays/devbox, built on its base with the templates' default names. Its account, runtime-k8s, is the subject the installed Site API already grants. The namespace, its Pod Security labels and the controller's Role stay in the Ansible bootstrap, and the project gains no kind.
  2. It syncs on wave 2, before pharos. Its namespace grants the platform namespace's credentials Job one Role, to create ConfigMaps and read site-api-trust. The Job copies the Site API's CA there once and never replaces it.
  3. It installs paused. Its production entry refuses to start until Project provisioning and the GitLab integration are connected. scripts/check_platform_gitops.py requires zero replicas, no platform credentials and a default deny in its namespace.
  4. Project namespaces and cluster-wide rules are not part of this service. Project provisioning renders each Project's member and Runtime grants. The bootstrap or later Applications install the admission policies and KServe.

Consequences

Positive: the Runtime's namespace, identity, storage, trust and network boundary install and update with every dev box.

Negative: before it can run, the Runtime needs per-Project grants from Project provisioning and its provider connections. The in-cluster build supplies its Metallo and batch image digests, an installation hook initialises its journals once, the bootstrap installs its admission policies and a liveness probe watches its worker.

Neutral: the isolated test installations still render the same templates with their own namespaces and names.

Update, 3 November 2026: KServe is a default platform dependency, with bootstrap-managed prerequisites and architecture-specific CPU serving. The native qualification lanes reuse that managed installation.

Page source

Source snapshot · Revision f928834c8.