Pod Resource Requirements and Limits

T4K Pod CPU and Memory Requirements

The table below provides resource request and limit information for Trilio for Kubernetes (T4K) pods.

This information can be leveraged to assign Resource Quotas and Limit Ranges for namespaces and resources within namespaces. User can later update this via Triliovault mnagaer.

Pod Name	CPU Request (milliCore)	CPU Limit (milliCore)	Memory Request	Memory Limit
Datamover, Image Backup, Retention	1	NA	2 Gi	NA
Exporter	50	NA	512 Mi	NA
Metadata Backup and Restore, Quiesce, Unquiesce, Target Browser, Backup Cleaner, Target Validation	200	NA	800 Mi	NA
Dex & Backup CronJob	10	200	10 Mi	512 Mi
Web, Ingress-controller	10	NA	10 Mi	NA
Resource Cleaner	400	NA	512 Mi	NA
Web-backend	400	NA	1 Gi	NA
Control-plane
- webhook-init	100	NA	512 Mi	NA
- triliovault-control-plane	400	NA	512 Mi	NA
Manager, Syncer	200	NA	800 Mi	NA
Operator	10	200	256 Mi	512 Mi

Estimating Memory and CPU Requirements

The overall resource requirements of T4K depend on the control plane pods plus the number of concurrent data protection and data management activities being performed. For example, a Kubernetes cluster with 10 BackupPlans may need more resources if all BackupPlans are configured to trigger at the same time, compared to 15 BackupPlans configured to trigger at staggered intervals.

Control Plane

These are the long-lived T4K install components (for example Control-plane, exporter, web, web-backend, ingress controller; Dex if enabled). Summing the requests for control plane, exporter, web, web-backend, and ingress-controller in the table gives about 970 milliCore CPU and 2080 Mi memory. Limits are not all fixed in the chart: use the table where a value is NA, optional, or taken from Helm deploymentLimits.

Data Plane

Depending on the number of concurrent backup, restore, and target operations and the features those operations use, CPU and memory requirements can be calculated at the data plane level:

1. Backup operations include: Metadata Snapshot, Quiesce (optional), Unquiesce (optional), Data Upload, Metadata Upload, Retention (optional), Backup Cleaner (optional)

2. Restore operations include: Restore Validation, Data Restore, Restore Metadata, Unquiesce (optional)

3. Target operations include: Target Validator, Target Browsing (optional)

Adding up the resource requirements for each phase of a particular operation provides the total requirements for that backup or restore.

Limiting pods in the TVK namespace with ResourceQuota

Kubernetes ResourceQuota limits how many resources a namespace can use across the cluster. Setting pods under spec.hard restricts the total number of Pods tthat can exist in that namespace at one time (both Running + Pending). When the quota limit is reached, new Pods stay in Pending until some existing Pods complete or are deleted—this is a common way to control how many Pods run at once without changing TVK settings.

Important: The quota counts every Pods in the namespace (including those from Deployments, Jobs, CronJobs, etc.). Choose the limit carefully so regular workloads can still run, or consider moving worker Jobs to another namespace (though this is not typical for TVK).

---

Example: limit at 30 pods

Replace tvk with your TrilioVault install namespace if different.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-quota
  namespace: tvk
spec:
  hard:
    pods: "30"

Apply:

kubectl apply -f pod-quota.yaml

Verify:

kubectl describe resourcequota pod-quota -n tvk

You will see Used vs Hard for pods. When usage reaches the limit, additional Pods remain Pending with an event indicating the quota was exceeded.

---

References

• Kubernetes Resource Quotas