This document describes a conservative guideline for capacity planning of Tetrate Service Bridge (TSB) in Management and Control planes.
These parameters apply to production installations: TSB will run with minimal resources if you are using a demo-like environment.
The resource provisioning guidelines described in this document are very conservative.
Also please be aware that the resource provisioning described in this document are applicable to vertical resource scaling. Multiple replicas of the same TSB components do not share the load with each other, and therefore you cannot expect the combined resources from multiple components to have the same effect. Replicas of TSB components should only be used for high availability purposes only.
Recommended baseline production installation resource requirements
For a baseline installation of TSB with 1 registered cluster and 1 deployed service within that cluster, the following resources are recommended.
To reiterate, the amount of memory described below are very conservative. Also, the actual performance given by the number of vCPUs tend to fluctuate depending on your underlying infrastructure. You are advised to verify the results in your environment.
|Component||vCPU #||Memory MiB|
|TSB server (Management Plane) 1||2||512|
|XCP Central Components 2||2||128|
2 Including the Kubernetes operator.
Recommended scaling resource parameters
The TSB stack is mostly CPU-bound. Additional clusters registered with TSB via XCP increase the CPU utilization by ~4%.
The effect of additional registered clusters or additional deployed workload services on memory utilisation is almost negligible. Likewise, the effect of additional clusters or workloads on resource consumption of the majority of TSB components is mostly negligible, with the notable exceptions of TSB, XCP Central component, TSB UI and IAM.
Components that are part of the visibility stack (e.g. OTel/Zipkin, etc.) have their resource utilisation driven by requests, thus the resource scaling should follow the user request rate statistics. As a general rule of thumb, more than 1 vCPU is preferred. It is also important to notice that the visibility stack performance is largely bound by Elasticsearch performance.
Thus, we recommend vertically scaling the components by 1 vCPU for a number of deployed workflows:
Besides OAP, All components don't require any resource adjustment. Those components are architectured and tested to support very large clusters.
OAP in Management plane requires extra CPU and Memory ~ 100 millicores of CPU and 1024 MiB of RAM per every 1000 services. E.g. 4000 services aggregated in TSB Management Plane from all TSB clusters would require approximately 400 millicores of CPU and 4096 MiB of RAM in total.
Control Plane Resource Requirements
Following table shows typical peak resource utilization for TSB control plane with the following assumptions:
- 50 services with sidecars
- Traffic on entire cluster is 500 repository
- Zipkin sampling rate is 1% of the traffic
- Metric is captured for every request at every workload.
Note that average CPU utilization would be a fraction of the typical peak value.
|Component||Typical Peak CPU (m)||Typical Peak Memory (Mi)|
|Istio Operator - Control Plane||50m||100Mi|
|Istio Operator - Data Plane||150m||100Mi|
|TSB Control Plane Operator||100m||100Mi|
|TSB Data Plane Operator||150m||100Mi|
TSB/Istio Operator resource usage per Ingress Gateway
The following table shows the resources used by TSB Operator and Istio Operator per Ingress Gateways
Keep in mind that these are estimated numbers depending on your application deployed, this can vary, but you can have a general idea of the consumption with these values
|Ingress Gateways||TSB Operator CPU(m)||TSB Operator Mem(Mi)||Istio Operator CPU(m)||Istio Operator Mem(Mi)|
Component resource utilization
The following tables will show how the different components of TSB scale with 4000 services and peaking with 60 rpm, this is divided by information from the Management Plane, and the Control Plane.
|Services||Gateways||Traffic(rpm)||Central CPU(m)||Central Mem(Mi)||MPC CPU(m)||MPC Mem(Mi)||OAP CPU(m)||OAP Mem(Mi)||Otel CPU(m)||Otel Mem(Mi)||TSB CPU(m)||TSB Mem(Mi)||Zipkin CPU(m)||Zipkin Mem(Mi)|
IAM will peak at 509m/52Mi, LDAP at 2m/17Mi and XCP Operator at 9m/37Mi
|Services||Gateways||Traffic(rpm)||Edge CPU(m)||Edge Mem(Mi)||Istiod CPU(m)||Istiod Mem(Mi)||OAP CPU(m)||OAP Mem(Mi)||Otel CPU(m)||Otel Mem(Mi)||Zipkin CPU(m)||Zipkin Mem(Mi)|
Metric Server will peak at 11m/32Mi, Onboarding Operator at 6m/38Mi, and XCP-Operator at 11m/46Mi