System requirements
What telark needs from your cluster to run cleanly.
telark is designed to install into clusters most platform teams already operate. It does not need exotic infrastructure — but there are a handful of hard requirements you should check before attempting the install.
Kubernetes version
telark installs on Kubernetes 1.30 or newer, enforced by the
chart's kubeVersion. It emits only GA APIs — apps/v1,
autoscaling/v2, networking.k8s.io/v1, policy/v1,
apiextensions.k8s.io/v1, admissionregistration.k8s.io/v1 — so
newer releases work as they ship.
| Tier | Kubernetes | Meaning |
|---|---|---|
| Supported | 1.33+ | The tested target. Bugs are fixed here. |
| Best-effort | 1.30 – 1.32 | Fully functional — every API telark uses is GA — but older and less tested. |
Anything below 1.30 is unsupported. The floor is 1.30 because the optional CRD admission guard uses ValidatingAdmissionPolicy, which went GA in that release.
Managed distributions: EKS, GKE, AKS, OpenShift.
| Component | Requirement |
|---|---|
| API server | Reachable from the telark pods (in-cluster service account). |
Cluster permissions
The install requires cluster-admin during the initial Helm release because telark registers CRDs, ClusterRoles, and an admission webhook. After install, day-to-day operations run as the telark service accounts, using the bindings the chart created.
CRDs
telark defines the following custom resources at install time. All of
them are v1alpha1 and namespace-scoped. See
Reference → CRD reference for the
full surface.
| Kind | Purpose |
|---|---|
ApplicationAsResource | A discovered application — a group of workloads treated as one unit. |
ProtectionPlan | Policy templates bound to a scope and a time window. |
GlobalConfig | Cluster-wide settings set from the dashboard at runtime. |
UserAsResource / GroupAsResource / RoleAsResource | The role model. |
UserPasskey / UserSession | Registered passkey credentials and active sessions. |
CategoryAsClassification | Classification categories applied to applications. |
The CRDs ship as a bundled subchart inside the same Helm release —
there is no separate install step. They carry
helm.sh/resource-policy: keep, so they survive helm uninstall. If
something else already manages them, install with
--set crds.enabled=false.
Policy engine
Protection plans are enforced by an admission-policy engine that
the chart bundles and installs for you (app.kyverno.enabled,
default true). telark renders policies into it while a plan is
active, and reads the resulting policy reports back to build the
violations feed.
| Component | Requirement |
|---|---|
| Admission webhooks | Must be permitted in the cluster. Some hardened distributions restrict them. |
| Failure policy | The chart configures the admission path so that a policy-engine outage cannot block unrelated workloads. Leave that default alone. |
Already running the same engine yourself? Install with
--set app.kyverno.enabled=false to skip the bundled copy.
Coordination and messaging
The chart bundles both, with production-grade defaults it owns. There is nothing for you to provide and nothing to tune.
| Component | Role |
|---|---|
| Coordination layer (Redis) | Discovery event coalescing, leader election, consumer groups, the enrichment job queue, auth session cache, and notification state. |
| Event stream | Carries application change events from discovery to the notifier, which persists them. |
Both are installed as subcharts with their own PersistentVolumeClaims (4 GiB each by default). Because Helm resolves subchart values before telark's sizing mode is known, these ship the same defaults in every mode.
Storage
The exporter mounts a PersistentVolumeClaim for snapshot blobs.
| Component | Requirement |
|---|---|
| StorageClass | A default StorageClass must exist. performance mode needs a ReadWriteMany class — pass --set app.persistence.storageClass=<rwx-class>. |
| Capacity | app.persistence.size, 10 GiB by default. Scale with average manifest size × retained versions × application count. |
| Access mode | ReadWriteOnce by default (app.persistence.accessMode). |
| Volume expansion | Recommended — the dashboard's storage bar tells you when you are close to full. |
Resource sizing
You do not size services individually. app.mode sets replicas,
resource requests, client rate limits, and disruption budgets for
every telark service from one flag.
| Mode | Replicas | For |
|---|---|---|
minimal | 1 | Dev, demos, evaluation. No disruption budgets. |
standard (default) | 2 | Small-to-mid production. |
performance | 3 | Large clusters. Autoscaling on automatically. |
See Guides → Installing for the full flag list and per-service autoscaling overrides.
Network policy
telark pods need:
- Egress to the Kubernetes API server.
- Egress to the in-namespace coordination and messaging services.
- Egress to your identity provider, if Google OIDC is enabled.
- Egress to your AI provider, if you enable AI insights with a hosted provider.
- Ingress from your ingress controller or load balancer on the dashboard's port, if you expose it that way.
If you run a default-deny NetworkPolicy in the telark namespace, add explicit allow rules for each of the above.
What telark does not need
- A managed database. telark stores everything in Kubernetes custom resources, the bundled coordination layer, and the snapshot PVC.
- An external object store. Backups should go to one — see Operations → Backups — but telark's runtime does not require one.
- Multi-cluster federation infrastructure. telark is single-cluster, single-tenant by design.
- Internet egress. Unless you enable AI insights with a hosted provider, telark's services do not call out.