rudderstack-helm

er, https://github.com/rudderlabs/rudderstack-helm. For now, all you need to understand is that the Network IO was the key concern in scaling as the system's primary job was to make API calls to various destination integrations. Throughput was more important than latency. # Solution Increasing CPU when needed. Kuberenetes Vertical Pod Autoscaler (VPA) was the key tool that helped me drive this optimization. VPA automatically adjusts the CPU and memory requests and limits for containers within pods. # What I liked about VPA * I like that VPA right-sizes from live usage and—on clusters with in-place pod resize—can update requests without recreating pods, which lets me be aggressive on both scale-up and scale-down improving bin-packing and cutting cost. * Another thing I like about VPA is that I can run multiple recommenders and choose one per workload via spec.recommenders, so different usage patterns (frugal, spiky, memory-heavy) get different percentiles/decay without per-Deployment knobs. # My challenge with VPA One challenge I had with VPA is limited per-workload tuning (beyond picking the recommender and setting minAllowed/maxAllowed/controlledValues), aggressive request changes can cause feedback loops or node churn; bursty tails make safe scale-down tricky; and some pods (init-heavy etc) still need carve-outs. That's all for today. Happy to hear your thoughts, questions, and probably your own experience with VPA. I did learn that k8s team is working on some of these feedback and we might see it get solved in 2026.

, here's the code for key components of the system (and architecture in readme) - * rudder-server - https://github.com/rudderlabs/rudder-server * rudder-transformer - https://github.com/rudderlabs/rudder-transformer * rudderstack-helm - https://github.com/rudderlabs/rudderstack-helm For now, all you need to understand is that the Network IO was the key concern in scaling as the system's primary job was to make API calls to various destination integrations. Throughput was more important than latency. ------ Solution Increasing CPU when needed. Kuberenetes Vertical Pod Autoscaler (VPA) was the key tool that helped me drive this optimization. VPA automatically adjusts the CPU and memory requests and limits for containers within pods. ------ What I liked about VPA * I like that VPA right-sizes from live usage and—on clusters with in-place pod resize—can update requests without recreating pods, which lets me be aggressive on both scale-up and scale-down improving bin-packing and cutting cost. * Another thing I like about VPA is that I can run multiple recommenders and choose one per workload via spec.recommenders, so different usage patterns (frugal, spiky, memory-heavy) get different percentiles/decay without per-Deployment knobs. ------ My challenge with VPA One challenge I had with VPA is limited per-workload tuning (beyond picking the recommender and setting minAllowed/maxAllowed/controlledValues), aggressive request changes can cause feedback loops or node churn; bursty tails make safe scale-down tricky; and some pods (init-heavy etc) still need carve-outs. ------ That's all for today. Happy to hear your thoughts, questions, and probably your own experience with tools like VPA, and dealing with challenges of scale.