Thoras Documentation

This page collects the Helm chart knobs you’re most likely to touch beyond a default install. For a quicker, higher-level guide to install and try out Thoras, check out the QuickStart Guide. Several install-time topics live on their own pages:

Persistent Storage – configuring the metrics-collector PV and, optionally, an external TimescaleDB.
Credentials – how to supply and rotate the credentials Thoras uses.
Private Container Registry – pulling images from your own registry, including air-gapped installs.

Installing the Thoras license

Thoras will provide you a license key which should be made available to your installation. You have two options for managing this value:

Pass the value into the Helm release via $.Values.imageCredentials.password, or
Reference an existing secret

Let’s review both options, choose whichever works best for you!

Option 1: Pass license in as Helm chart value

Pass the content of your license key file to $.Values.imageCredentials.password in your helm release

Reference an existing secret

If you’d prefer to reference a pre-existing secret object instead of passing values into your helm release, this option is for you! Ensure a secret of type docker-registry exists in the thoras namespace and that it’s structured correctly:

An example of how to create the secret manually:

kubectl create secret docker-registry thoras-license \
    --docker-server=us-east4-docker.pkg.dev/thoras-registry/platform \
    --docker-username=_json_key_base64 \
    --docker-password="{{ YOUR_LICENSE_KEY_CONTENT_HERE }}" \
    -n thoras

In the helm values file, reference this secret by setting .Values.imageCredentials.secretRef: "thoras-license".

Confirm license installed successfully

You can confirm the license has been installed successfully if the pods in the thoras namespace come up into Running status after one or two minutes. Pod error statuses such as ImagePullBackOff might indicate an issue.

Forecast worker capacity

Thoras runs a pool of forecast workers that produce predictions for your enrolled workloads. By default the chart runs a built-in scaler that grows the pool automatically as you enroll more AIScaleTargets, so most installs need no configuration here. How the built-in scaler works

Scaler settings live under thorasForecast.worker.scaler:
- minReplicas: 1: the floor.
- maxReplicas: 100: the ceiling.
- astsPerReplica: 67: the target ratio. The scaler adds a worker replica for roughly every 67 AIScaleTargets.
- interval: "1m": how often the scaler reconciles.
thorasForecast.worker.replicas is intentionally unset by default so the scaler is in charge.

Pinning a fixed number of workers Setting thorasForecast.worker.replicas to an explicit number disables the built-in scaler and pins the pool at that size. Use this only if you specifically want a static count (for example, to match a capacity plan or work around a scaler issue):

thorasForecast:
  worker:
    replicas: 3

Configuring Webhook Namespace Exclusions

By default, Thoras webhooks exclude the kube-system and kube-node-lease namespaces. You can customize which namespaces are excluded, or disable exclusions entirely, using the thorasOperator.webhooks.namespaceSelector Helm value.

Default Behavior

Out of the box, Thoras excludes system namespaces from webhook enforcement:

thorasOperator:
  webhooks:
    namespaceSelector:
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values:
            - kube-system
            - kube-node-lease

Customizing Excluded Namespaces

To exclude additional namespaces (e.g. a monitoring namespace), extend the values list:

thorasOperator:
  webhooks:
    namespaceSelector:
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values:
            - kube-system
            - kube-node-lease
            - monitoring

Disabling Namespace Exclusions

If you use an admission enforcer such as OPA Gatekeeper that manages namespace selection independently, you can disable the default exclusions by setting the selector to null so the chart omits it entirely:

thorasOperator:
  webhooks:
    namespaceSelector: null

Webhook TLS with cert-manager

By default the chart provisions its own webhook TLS material via a bundled cert-generator Job. If you already run cert-manager in your cluster, you can hand that job off to cert-manager instead:

thorasOperator:
  webhookCertGen:
    certManager:
      enabled: true

With this enabled, cert-manager provisions the thoras-tls-certs Secret and injects the CA bundle into the webhook configurations. The bundled kube-webhook-certgen Jobs, along with their RBAC and network policy, are skipped. This is the recommended setting for GitOps tools such as Argo CD and Flux, and for any helm template based workflow, since Helm hook Jobs are handled poorly outside of helm install. The chart uses a long-lived CA (10 years by default) that signs the webhook leaf cert, so routine leaf renewals don’t rotate the injected CA bundle. Adjust the CA lifetime via thorasOperator.webhookCertGen.certManager.ca.duration if your policy requires it.

Scheduling

The chart exposes standard Kubernetes scheduling primitives at both a global level and per-component. Component-specific settings take precedence over global ones. Global (applied to every component and to the chart’s hook Jobs):

nodeSelector:
  kubernetes.io/os: linux

tolerations:
  - key: dedicated
    operator: Equal
    value: thoras
    effect: NoSchedule

# Global affinity rules that components can opt into via useGlobalAffinity: true
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: node.kubernetes.io/instance-type
              operator: In
              values: [m5.large, m5.xlarge]

priorityClassName: thoras-high-priority

# Applied to all components; a component-specific list fully replaces this.
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway

Per-component overrides exist under each component block (thorasOperator, thorasApiServerV2, thorasWorker, thorasForecast, metricsCollector, thorasDashboard, thorasConfigController) as affinity, priorityClassName, and topologySpreadConstraints. Each component also has a useGlobalAffinity switch (default true) that controls whether the global affinity block is merged in on top of the component’s own.

NetworkPolicy

The chart can emit a least-privilege network policy for every Thoras component, in one of two flavors:

networkPolicy:
  enabled: true
  # kubernetes (default): standard networking.k8s.io/v1 NetworkPolicy, works
  #                       with any NetworkPolicy-capable CNI.
  # cilium:               CiliumNetworkPolicy (cilium.io/v2). Requires Cilium.
  flavor: kubernetes

Kubernetes API server ports. Standard NetworkPolicy is evaluated after kube-proxy translates the kubernetes Service address to a real endpoint, so the kubernetes flavor needs to know the port the API server actually listens on (networkPolicy.apiServerPorts, default [443, 6443]). Check with kubectl get endpoints kubernetes -n default and add the port if it’s non-standard. Minikube, for example, uses 8443. The cilium flavor targets the API server by identity and ignores this list. Extending the policies. Each component block accepts extraIngressRules and extraEgressRules, appended verbatim to the generated policy in either flavor. OIDC egress. When dashboard OIDC auth is enabled, the chart opens egress on port 443 from the dashboard pod so the sidecar can reach your identity provider. Tighten with a layered policy scoped to your IdP’s hostnames if required.

Egress proxy

If Thoras components must dial an outbound HTTP/HTTPS proxy, for example to reach console.thoras.ai for cloud sync, set the standard proxy environment variables globally:

proxy:
  httpProxy: "http://proxy.example.com:3128"
  httpsProxy: "http://proxy.example.com:3128"
  noProxy: ".svc.cluster.local,10.0.0.0/8"

The values are injected into every Thoras component as HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.

Prometheus scraping

Every Thoras component that emits Prometheus metrics has a prometheus.enabled toggle (default true) and a fixed prometheus.port. The chart can also emit a ServiceMonitor for the Prometheus Operator via the serviceMonitor values. See Monitoring Thoras for the full scraping configuration and the list of metrics.

Getting Started

Installation

Guides

Advanced Setup

Installing the Thoras license

Option 1: Pass license in as Helm chart value

Reference an existing secret

Confirm license installed successfully

Forecast worker capacity

Configuring Webhook Namespace Exclusions

Default Behavior

Customizing Excluded Namespaces

Disabling Namespace Exclusions

Webhook TLS with cert-manager

Scheduling

NetworkPolicy

Egress proxy

Prometheus scraping

​Installing the Thoras license

​Option 1: Pass license in as Helm chart value

​Reference an existing secret

​Confirm license installed successfully

​Forecast worker capacity

​Configuring Webhook Namespace Exclusions

​Default Behavior

​Customizing Excluded Namespaces

​Disabling Namespace Exclusions

​Webhook TLS with cert-manager

​Scheduling

​NetworkPolicy

​Egress proxy

​Prometheus scraping

Installing the Thoras license

Option 1: Pass license in as Helm chart value

Reference an existing secret

Confirm license installed successfully

Forecast worker capacity

Configuring Webhook Namespace Exclusions

Default Behavior

Customizing Excluded Namespaces

Disabling Namespace Exclusions

Webhook TLS with cert-manager

Scheduling

NetworkPolicy

Egress proxy

Prometheus scraping