System requirements
What Telark needs from your cluster, what the chart installs, and how much capacity to reserve.
Cluster
| Requirement | Detail |
|---|---|
| Kubernetes | 1.30 or newer, enforced by the chart's kubeVersion. 1.33+ is the tested target; 1.30 to 1.32 work but are less tested. The floor is 1.30 because the CRD write guard uses ValidatingAdmissionPolicy, GA in that release. |
| APIs | Only GA APIs: apps/v1, autoscaling/v2, networking.k8s.io/v1, policy/v1, apiextensions.k8s.io/v1, admissionregistration.k8s.io/v1. |
| Distributions | EKS, GKE, AKS, OpenShift, and upstream Kubernetes. |
| Helm | 3.x. |
| Install permissions | cluster-admin. The chart registers CRDs, ClusterRoles, ValidatingAdmissionPolicies and Kyverno's admission webhooks. Afterwards Telark runs under its own service accounts. |
| Admission webhooks | Must be allowed. Some hardened distributions restrict them. |
| NetworkPolicy | Optional. The chart's ingress policies (on by default) only take effect with a CNI that enforces them, such as Calico or Cilium. |
Storage
The exporter mounts two PersistentVolumeClaims with the same class: one for snapshots and one for protection plan reports.
| Install | StorageClass | Snapshots | Reports |
|---|---|---|---|
standard (default) | ReadWriteMany, set with app.persistence.storageClass | 10 GiB | 2 GiB |
performance | ReadWriteMany | 50 GiB | 10 GiB |
minimal, or app.singleNode=true | Any, cluster default is fine | 1 GiB in minimal, else 10 GiB | 512 MiB in minimal, else 2 GiB |
standard and performance run two exporter replicas that share both volumes, which is why they need ReadWriteMany (efs-sc on EKS with the EFS CSI driver). The install fails early without one. The bundled Redis and NATS each add a 4 GiB volume, and the model runtime a 10 GiB volume.
Volume expansion is recommended: Settings → Governance → Snapshot storage shows how full the snapshot volume is.
Capacity
app.mode sizes every Telark service from one flag. You do not size services one by one.
| Mode | Replicas per service | Requests per pod | Limits per pod | For |
|---|---|---|---|---|
minimal | 1, fixed | 50m CPU, 64 MiB | 250m, 256 MiB | Evaluation and dev, up to a few hundred applications. Fits one 2 vCPU / 8 GiB node. |
standard (default) | 1, scales to 3 on CPU | 100m CPU, 128 MiB | 500m, 512 MiB | Production up to about 1,000 applications; verified at 2,000. |
performance | 1, scales to 5 on CPU | 500m CPU, 512 MiB | 2 CPU, 2 GiB | More than 1,000 applications or a high change rate. Disruption budgets on. |
The exporter never autoscales: it runs two replicas in standard and performance, one in minimal or with app.singleNode=true.
On top of Telark's own pods, the chart installs dependencies with fixed defaults that do not change with the mode:
| Dependency | Why | Opt out |
|---|---|---|
| Kyverno 3.9.1 (two admission replicas) | Enforces protection plans at admission | app.kyverno.enabled=false if you already run Kyverno |
| Redis | Leader election, queues, caches, insights | Required |
| NATS JetStream | Application change events from discovery to the notifier | Required |
| metrics-server | CPU metrics for autoscaling | metrics-server.enabled=false if the cluster ships one |
| Ollama | The local model runtime for Insights. Requests 250m CPU and 1.5 GiB memory, 2 CPU limit | app.ollama.enabled=false |
Network
The chart restricts ingress, not egress. If you add egress rules of your own, allow:
- The Kubernetes API server and DNS from every Telark pod.
- Traffic between Telark pods and to Redis and NATS in the release namespace.
- The auth service to Google, only if Google sign-in fetches Google's signing keys.
- The Ollama pod to the internet over HTTPS, only while
app.ollama.autoPull=true(the default) so it can download the model. Air-gapped installs set it tofalseand need no egress. - The analyzer to your own Ollama-API endpoint, only if you set
app.ollama.runtimeUrl.
Telark needs no managed database, no object store and no outbound connection to a Telark service.