Container Resource based Autoscaling - Explore How This Works

In simple words, Container Resource Based Autoscaling scales pods in a deployment based on the resource usage of individual containers within those pods. We will explore it now. But before that:

I NEED YOUR HELP: Join me on Youtube if you resonate with my work. It means a lot to me. Thank You.

Ok, let's continue.

Regular Autoscaling: Normally, Horizontal Pod Autoscalers (HPAs) looks at the total resource usage of the entire pod (sum of all containers). And scale Pods based on average CPU or memory usage.

Here's how Container Resource Based Autoscaling works with 3 containers in a pod:

Let's say "main" container is CPU intensive, while "proxy" and "log" container not.

You can plan to scale pods if main container crosses 90%. But we can also choose to scale proxy container with different CPU range. Let's say at 70% for now.

Here's how you can create similar deployment. From the above diagram, we are trying to do the following.

• Scale based on CPU usage of main container.
• Scale based on CPU usage of proxy container separately.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: test-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: test-deployment
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: ContainerResource
    resource:
      name: cpu
      container: main # This is new. Targeting main container CPU.
      target:
        type: Utilization
        averageUtilization: 90
  - type: ContainerResource
    resource:
      name: cpu
      container: proxy # This is new. Targeting proxy container CPU.
      target:
        type: Utilization
        averageUtilization: 70        

Did you notice "container: main" in the config? It explicitly specifies we need to scale main container when it's average CPU crosses 90%. Here's a short summary of the deployment.

1. Main container ("main") scales based on CPU (90%).
2. Proxy container ("proxy") still scales based on CPU usage exceeding 70%.
3. Log container ("log") is excluded from scaling decisions.

If you want to test this, do use "kube-prometheus-stack" to monitor the entire activity. It has detailed container level cpu usage spec on each pod.

This feature is now graduated to stable in Kubernetes 1.30 release. Do try it and let me know how it goes. Hope this is useful, a repost is very much appreciated.

I will share more future learnings on Youtube, so consider checking it out. Thank You.

Consider checking my previous posts:

https://www.dhirubhai.net/pulse/kubernetes-network-speed-test-between-2-pods-mutha-nagavamsi-fdmrc/

https://www.dhirubhai.net/pulse/kubernetes-gateway-api-fascinating-topic-mutha-nagavamsi-nniec/