HPA Was Scaling on the Sidecar's Share Too. The ContainerResource Blind Spot in Kubernetes

1. HPA's "Utilization" Includes the Sidecar's Share Too

Have you ever run Kubernetes HPA (HorizontalPodAutoscaler) and noticed it won't scale even though CPU usage should be over the threshold — or that it scales out earlier than you expected? More often than not, the cause is a core part of the spec itself: HPA's standard Resource metric sums the usage of every container in the Pod.

The standard Resource metric calculates utilization as sum(usage of all containers) / sum(requests of all containers) (Kubernetes official documentation). That's fine when a Pod runs a single application container, but now that multi-container Pods — with a service mesh sidecar proxy or a log-shipping agent riding along — are the norm, this aggregation can skew the decision.

Here's a concrete example. Say an API container requests 500m CPU and uses 350m, while a log agent requests 200m and uses only 20m. The Pod-wide utilization comes out to 370m ÷ 700m ≈ 52.9%, but the application container alone is at 350m ÷ 500m = 70% (oneuptime.com's analysis). Under the exact same load, the scaling decision changes entirely depending on what you measure.

2. Why It's Easy to Miss — The "Invisible Roommate" Called a Service Mesh

This problem tends to surface right after adopting a service mesh like Istio. According to Istio's official performance documentation, under typical load a single sidecar proxy consumes about 0.2 vCPU and 60MB of memory (Istio official documentation). That looks small on its own, but once it's folded into HPA's CPU utilization calculation, it obscures the application container's real load.

Google Cloud's Cloud Service Mesh operations guide likewise recommends explicitly defining resource requests and limits for sidecar proxies, precisely because their resource consumption affects HPA's calculation (Google Cloud official documentation). Yet many teams don't notice the dilution effect until after they've rolled out a service mesh and start wondering, "why did HPA's behavior change?" The more sidecar-pattern components you add — logging agents, security agents, and so on — the bigger this dilution effect gets.

Managed, K3s-based Kubernetes offerings like Kubo are frequently run with a service mesh or a logging stack on top of a built-in Prometheus + Grafana setup. Understanding the standard HPA spec correctly is unavoidable for production operations on stacks like this.

3. Letting ContainerResource Metrics Focus on "Just the One Container"

The official fix for this dilution problem is the ContainerResource metric type. This Kubernetes feature lets HPA base its scaling decision on the resource usage of one specific container, rather than the whole Pod (KEP-1610: Container Resource based Autoscaling).

The KEP's own motivation section spells out exactly this scenario: "sidecar containers consume resources that don't correlate with the main application's load." The feature was introduced as alpha in Kubernetes 1.20, moved to beta in 1.27, and reached Stable (GA) in 1.30 (Kubernetes official blog). Configuring it is as simple as naming the target container explicitly:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: ContainerResource
    containerResource:
      container: app-container
      target:
        type: Utilization
        averageUtilization: 70
      name: cpu

There's one practical catch worth knowing. If the target container doesn't have a resource request set, that Pod's utilization becomes "undefined" and HPA simply won't act on it. Also, if you ever rename the container, you need to update the HPA definition before the rollout goes out (Kubernetes official documentation) — forget that, and HPA quietly stops working, which makes it an easy trap to fall into. DoiT's blog walks through a similar configuration example, noting that it requires Kubernetes 1.27 or later plus Metrics Server installed (DoiT Cloud Intelligence).

Either way, HPA pulls its resource data through the Metrics API that Metrics Server provides (Kubernetes' resource metrics pipeline documentation). ContainerResource simply changes the granularity of that same pipeline from Pod-level to container-level — no extra agents or tooling required, as long as you already have Metrics Server running.

4. The K3s/Kubo Perspective — It's a Standard Kubernetes Feature, So It Just Works

Everything covered so far is about HPA, a core Kubernetes feature (kube-controller-manager) — it doesn't depend on any particular distribution. K3s bundles metrics-server as a standard component (K3s official repository), so ContainerResource metrics work there too, with no extra setup.

That's one of the reasons to choose a K3s-based managed Kubernetes like Kubo: because standard Kubernetes features work as-is, you can follow the official documentation for your HPA design without worrying about vendor-specific constraints. Kubo Cloud in particular ships with Prometheus + Grafana built in, so you can verify the effect of switching to ContainerResource metrics right away using your existing monitoring stack — a real practical advantage.

If you're currently designing a production setup that combines a service mesh with logging agents, or wrestling with HPA behavior that just doesn't match your expectations, it's worth considering Kubo as a cost-efficient foundation for running that kind of operation.

5. Summary

HPA's standard Resource metric calculates utilization by summing the usage of every container in a Pod. In modern Pod designs that include a sidecar proxy or logging agent, that spec dilutes the scaling decision. Switching to the ContainerResource metric (Stable since Kubernetes 1.30) lets you focus scaling purely on the main application container.

This mechanism is a core Kubernetes feature, so it applies just as well on managed K8s environments like K3s and Kubo. When designing production workloads that use a service mesh or an observability stack, it's worth always asking "a percentage of what, exactly?" If you're also reconsidering your underlying operations platform, a managed K3s service like Kubo — where standard Kubernetes features work at full strength — is worth a look. Starting at roughly ¥48,000/month, you can bring the same HPA design you'd use on EKS or AKS over as-is. Contact us if you'd like to talk through a specific setup.