Configuration

This page summarizes the most common configuration surfaces.

Helm Values

The platform chart configures:

• scheduler and controller replicas,
• image repositories, tags, and pull policy,
• imagePullSecrets,
• leader election,
• service accounts and RBAC,
• security contexts,
• metrics Services,
• optional ServiceMonitor,
• node selectors, tolerations, and affinity.

Render chart output before applying:

helm template kruntimes ./charts/kruntimes --namespace kruntimes-system

Contributor-only Make variables and chart validation commands are documented in the Development Guide and Testing Guide .

Console TLS

The Console is installed with the kruntimes chart and exposes HTTPS only. By default, the chart generates a certificate suitable for local or explicitly trusted deployments:

console:
  tls:
    selfSigned: true

To mount an existing TLS Secret, select that source explicitly:

console:
  tls:
    selfSigned: false
    secretName: console-tls

To have cert-manager issue the certificate, disable chart generation and reference an existing Issuer or ClusterIssuer. The issuer may itself be a self-signed cert-manager issuer.

console:
  tls:
    selfSigned: false
    secretName: console-tls
    certManager:
      enabled: true
      issuerRef:
        name: platform-ca
        kind: ClusterIssuer

selfSigned, an existing Secret, and certManager.enabled are mutually exclusive choices. The Service is always ClusterIP; configure ingress or other external exposure separately.

Run Extension API

runExtensionAPI.enabled defaults to true independently of the always-installed Kruntimes Console. It installs the logs.kruntimes.io/v1alpha1 and sessions.kruntimes.io/v1alpha1 APIServices on a dedicated backend. This is the default transport for krt logs and Console: normal kubeconfig authentication, including client certificates, is verified by the Kubernetes API server. The caller needs get on the logs.kruntimes.io runs/log subresource; it never needs kruntimes.io/runs get or pods/log.

The APIServices are cluster-scoped, so a cluster can have one Run extension API backend for these group/versions. When installing a second kruntimes platform release in the same cluster, retain runExtensionAPI.enabled: true for the release that owns the API and set it to false for every other release.

runExtensionAPI:
  enabled: true

The former logAPI values key still overrides matching fields for existing Helm values files, except image: the old image contains a log-only binary. New configurations should use runExtensionAPI and the run-extension-apiserver image.

Console and krt logs always use this aggregated API. Console’s embedded Runtime access API continues to serve Session and Function endpoints, but does not serve Run logs.

krt session exec and krt session attach use the Session subresource through the Kubernetes API server. Callers need get on both the named kruntimes.io/runs resource and sessions.kruntimes.io/runs/session.

Public resource lists

Namespace, Run, Runtime, and WorkflowRun lists are available without a token by default. This is controlled by console.publicRead.enabled; set it to false to require a bearer token for every API request:

console:
  publicRead:
    enabled: false

The chart grants the Console ServiceAccount only get/list on namespaces, runs, runtimes, and workflowruns. Their details require the caller’s bearer token. Log requests require get on the logs.kruntimes.io runs/log subresource.

Runtime Capacity

Runtime capacity is declared on the Runtime CRD:

spec:
  capacity:
    resources:
      runs: 4
      gpu: 1

The controller copies declared static capacity to Runtime Pod annotations. The scheduler tracks fast-changing active usage from Run state.

Runtime Pod Template

Runtime Pod customization lives in Runtime.spec.template.

spec:
  template:
    spec:
      serviceAccountName: custom-runtime-sa
      nodeSelector:
        workload: kruntimes
      tolerations:
        - key: dedicated
          operator: Equal
          value: runtimes
          effect: NoSchedule

The controller reserves fields needed by kruntimes. Do not override the injected runtimed container or kruntimes-managed labels and annotations.

Artifact Stores

Artifacts are written below $KRUNTIME_ARTIFACTS_DIR by workloads and persisted through the Runtime artifact store.

Supported backends:

• filesystem/PVC,
• S3-compatible object storage.

Run status stores bounded metadata in status.artifactRefs, not full artifact contents.

Environment Variables Exposed to Runs

Benchmark Variables

See Performance Benchmarks .