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
| Component | Requirement |
|---|---|
| Kubernetes control plane | 1.27 or newer. telark uses dynamic informers and server-side apply features available from 1.27 onward. |
| API server | Reachable from the telark deployment pods (in-cluster service account). |
Anything older than 1.27 is unsupported. Anything past the current upstream-supported version is best-effort.
Cluster permissions
The install requires cluster-admin during the initial Helm release because telark registers CRDs and ClusterRole bindings. After install, day-to-day operations run as the telark service accounts (with the bindings the chart created).
CRDs
telark defines the following CRDs at install time (see Reference → CRD reference for the full surface):
applicationsasresources.erpi.telark/v1alpha1protectionplans.telarkusers.telarkuserpasskeys.telarkusersessions.telarkroles.telarkgroups.telarkcategories.telarkglobalconfigs.telark
The Helm chart applies these as part of the release; do not register them by hand.
Policy engine
Protection plans depend on a Kubernetes admission-policy engine
running in the cluster. telark today wires against Kyverno
(kyverno.io/v1 Policies + wgpolicyk8s.io/v1alpha2
PolicyReports).
| Component | Requirement |
|---|---|
| Kyverno | Recent stable release (verify against the changelog of the telark version you install). |
| Webhook failure policy | The release-manager chart sets kyverno.features.forceFailurePolicyIgnore.enabled=true on the admission path so a Kyverno outage cannot brick unrelated workloads. Keep this on. |
The chart can install Kyverno as a subchart; if you already have Kyverno installed, point the chart at the existing release.
Redis
telark uses Redis for three things:
- Discovery event coalescing + leader election + consumer groups.
- Exporter notifications + caches.
- Auth session cache + cleanup queue.
| Component | Requirement |
|---|---|
| Redis | 6.2 or newer. Single-replica is fine for non-HA installs. |
| Connectivity | Reachable from all three telark deployments. |
| Persistence | Optional. Notifications and session caches survive crashes if AOF or RDB is on; otherwise the stores reset. |
The chart can install Bitnami Redis as a subchart, or accept a URL to your own.
NATS (optional)
telark publishes change events on the
telark.applications.update NATS topic. If NATS_URL is
unset on the discovery deployment, event publishing is skipped
silently — every other feature still works.
| Component | Requirement |
|---|---|
| NATS | 2.x or newer. |
| Connectivity | Reachable from the discovery deployment. |
Storage
The exporter mounts a PersistentVolumeClaim for snapshot blobs.
| Component | Requirement |
|---|---|
| StorageClass | Any. The PVC is a single ReadWriteOnce volume. |
| Capacity | Minimum 20 GiB for a small cluster. Scale linearly with the average manifest size × spec.snapshots.maxPerApp × application count. |
| Volume expansion | Recommended — the dashboard's storage bar tells you when you are close to full. |
Resource sizing (small cluster baseline)
The numbers below are starting points for a cluster of ~100 workloads. Tune up for larger clusters.
| Deployment | Replicas | CPU req | Memory req |
|---|---|---|---|
| discovery | 2 | 200m | 256Mi |
| exporter | 1 | 200m | 256Mi |
| auth | 1 | 100m | 128Mi |
The chart's resources: block lives in the release-manager
values; expand based on the Prometheus metrics once the install
has been running for a week.
Network policy
telark pods need:
- Egress to the Kubernetes API server.
- Egress to Redis.
- Egress to NATS (if configured).
- Egress to the OIDC provider (if Google OIDC is enabled).
- Ingress from your ingress controller / load balancer on the dashboard's port.
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 CRDs
- Redis + 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 from the dashboard pods. Unless you enable AI enrichment with a hosted provider, telark's services do not call out.