Resource Profile
Apiserver does not process high-volume telemetry directly. It handles UI and API requests, reads and writes metadata in PostgreSQL, queries telemetry from ClickHouse, and starts longer-running work in Temporal. Because most durable and expensive work happens in PostgreSQL, ClickHouse, and Temporal, Apiserver should usually stay low CPU and memory. Short request spikes are expected, but sustained high CPU, memory, or throttling is not the normal operating mode.Autoscaling
Leave Apiserver autoscaling enabled unless Metoro support recommends otherwise. The default chart values run multiple replicas and let Kubernetes adjust replica count as UI and API traffic changes. Manual changes to Apiserver CPU, memory, or replica bounds should be rare. Make them only when there is sustained Apiserver-specific pressure, such as persistent CPU throttling, OOM restarts, or request latency that is isolated to Apiserver itself.Restarts And Availability
Apiserver does not own durable local state. Pods can be killed, restarted, or recreated without losing application data. Kubernetes readiness, rolling updates, and multiple replicas keep the UI and API path available while individual pods are replaced. If all Apiserver pods are unavailable, users and exporters cannot reach the control plane, but data is not lost from Apiserver local storage because there is no durable local storage.Before Tuning Apiserver
If users report slow UI or API behavior, check dependencies before changing Apiserver resources:- ClickHouse query latency, CPU pressure, memory pressure, and replica health.
- PostgreSQL metadata latency, connection pressure, and primary/standby health.
- Temporal workflow health for background features.
- Ingress, load balancer, DNS, and TLS behavior on the user-facing path.
- Kubernetes node capacity, scheduling events, and pod restarts.