<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Autoscaling on Home</title><link>http://www.bala-krishnan.com/tags/autoscaling/</link><description>Recent content in Autoscaling on Home</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Tue, 13 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="http://www.bala-krishnan.com/tags/autoscaling/index.xml" rel="self" type="application/rss+xml"/><item><title>Narya - When Not to Scale</title><link>http://www.bala-krishnan.com/posts/23-narya/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><guid>http://www.bala-krishnan.com/posts/23-narya/</guid><description>The HPA has one job: keep resource utilization below a threshold. When it sees CPU pressure, it adds pods. This works great until the thing causing your CPU pressure isn&amp;rsquo;t your service being overwhelmed, it&amp;rsquo;s your service being blocked waiting on something else.
I&amp;rsquo;ve been on-call for incidents where the database connection pool saturated. Application pods queued up waiting for connections. The HPA saw CPU pressure and fired more pods. The new pods each opened a handful of database connections.</description></item></channel></rss>