Stop Your High-Traffic Apps from Killing Everything Else in AKS

13 Jun, 2025

Running multiple apps in the same Kubernetes cluster? Yeah, we've all been there. One app starts getting hammered with traffic and suddenly everything else slows to a crawl. Your admin panel times out, your monitoring goes wonky, and everyone's having a bad time.

Here's a simple fix I've been using: separate ingress controllers with their own node pools. It's like having different lanes on a highway - the sports cars don't get stuck behind the school bus.

The Problem

Picture this: You've got your main API handling thousands of requests per second, and your company admin dashboard that maybe 10 people use. Normally everything's fine, but then you hit the front page of Hacker News or get featured somewhere, and suddenly:

Your admin panel becomes unusable
Monitoring alerts start firing
Your CEO can't access the dashboard (this is never good)
Everything shares the same resources, so everything suffers

The Solution

Instead of one ingress controller handling all traffic, create two:

High-traffic ingress - Gets its own beefy node pool
Standard ingress - Smaller, cheaper nodes for everything else

When your API gets slammed, it only affects its own resources. Your other apps keep humming along like nothing happened.

Here's what the architecture looks like:

                        [Internet Traffic]
                              |
                        [API Gateway]
                              |
                    [Azure Load Balancer/DNS]
                         /            \
                High Traffic       Standard Traffic
                (api.myapp.com)    (admin.myapp.com)
                      |                    |
    ╔═══════════════════════════════════════════════════════╗
    ║                  AKS Cluster Network                  ║
    ║                                                       ║
    ║     [High-Traffic Ingress]  [Standard Ingress]        ║
    ║          (20.1.1.100)         (20.1.1.101)            ║
    ║               |                    |                  ║
    ║ ┌─────────────────────────┐  ┌───────────────────┐    ║
    ║ │  High-Traffic Node Pool │  │ Standard Node Pool│    ║
    ║ │                         │  │                   │    ║
    ║ │  [Node 1] [Node 2]      │  │  [Node 1]         │    ║
    ║ │  (Larger VMs)           │  │  (Smaller VMs)    │    ║
    ║ │                         │  │                   │    ║
    ║ │  • Backend Services     │  │  • Admin Panel    │    ║
    ║ │  • Payment Service      │  │  • Monitoring     │    ║
    ║ │  • User Service         │  │  • Internal Tools │    ║
    ║ └─────────────────────────┘  └───────────────────┘    ║
    ╚═══════════════════════════════════════════════════════╝

How to Set It Up

Step 1: Create Separate Node Pools

Create two node pools with different specs:

High-traffic pool: Bigger VMs, more nodes, aggressive auto-scaling
Standard pool: Smaller VMs, fewer nodes, gentle scaling

Tag them with labels so you can target them later.

Step 2: Deploy Two Ingress Controllers

Install two separate NGINX ingress controllers:

High-traffic ingress: More replicas, bigger resource limits, tuned for performance
Standard ingress: Smaller footprint, basic config

Each gets pinned to its respective node pool using node selectors.

Step 3: Route Traffic Appropriately

Point your high-traffic domains (like your API) to the high-traffic ingress controller, and everything else to the standard one. Use different static IPs or DNS entries to split the traffic.

Step 4: Configure Your Apps

Update your ingress resources to use the right ingress class:

High-traffic apps get kubernetes.io/ingress.class: "high-traffic"
Standard apps get kubernetes.io/ingress.class: "standard"

Your deployments also need node selectors to land on the right pools.

What You Get

Performance isolation: Your high-traffic app can max out its resources without affecting anything else.

Cost control: You're not over-provisioning everything just because one app needs big instances.

Better sleep: No more 3 AM pages because someone's admin panel is down due to API traffic.

Easier debugging: When something's slow, you know exactly which pool to look at.

Things to Watch Out For

DNS setup: Make sure your domains point to the right load balancer IPs.

Monitoring: You'll need separate dashboards for each ingress controller to keep track of what's happening.

Costs: You're running more infrastructure, but it's usually worth it for the isolation.

Complexity: More moving pieces means more things that can break. Keep good documentation.

When to Use This

This setup makes sense if you have:

Mixed traffic patterns (some high, some low)
Apps with different SLA requirements
A need to contain blast radius when things go wrong
Budget to run separate infrastructure

If all your apps have similar traffic patterns, you probably don't need this complexity.

The Bottom Line

Sometimes the simple solution is the best solution. Instead of trying to tune one ingress controller to handle everything perfectly, just give your different workloads their own space. Your future self (and your on-call team) will thank you.

Plus, when your startup gets that sudden traffic spike, you'll look like a hero for planning ahead.