AKS rośnie — i rośnie problem niewykorzystanych zasobów

Klaster AKS z 70–80% zarezerwowanych zasobów i 20–30% faktycznego zużycia to nie wyjątek — to standard. Raport CAST AI z 2026 roku pokazuje, że średnie wykorzystanie CPU w klastrach Kubernetes wyniosło w 2025 roku zaledwie 8% (rok wcześniej 10%), a pamięci — 20% (rok wcześniej 23%). CPU jest nadmiernie provisionowane w 69% przypadków, pamięć — w 79%. Sharone Zitzman opisała ten problem szczegółowo na Cloud Native Now — i nikt kto zarządza AKS w środowisku produkcyjnym nie będzie zaskoczony tymi liczbami.

Dlaczego AKS ma problem z wykorzystaniem zasobów

Azure Kubernetes Service jest jednym z najszybciej rosnących produktów Microsoft — liczba klastrów AKS rośnie z kwartału na kwartał, podobnie jak ich rozmiar. I właśnie to jest źródłem problemu: im szybciej rośnie skala, tym trudniej utrzymać dyscyplinę w zarządzaniu zasobami.

Mechanizm, który napędza overprovisioning, jest dobrze znany każdemu, kto spędził wystarczająco dużo czasu z manifestami Kubernetes:

Żądania zasobów stają się wieczne. Zespół ustawia konserwatywne requests przy pierwszym wdrożeniu — z marginesem bezpieczeństwa, bo nikt nie chce incydentu produkcyjnego z powodu OOMKill. Te wartości trafiają do Helma,
z Helma do GitOps, z GitOps do kolejnych środowisk. Nikt ich nie weryfikuje, bo "działają". Tymczasem faktyczne zużycie jest wielokrotnie niższe.

Optymalizacja się dezaktualizuje. Nawet jeśli ktoś raz przeprowadził rightsizing — zmiana workloadu, aktualizacja aplikacji, nowy wzorzec ruchu
— i poprzednia optymalizacja przestaje być aktualna. Bez mechanizmu ciągłego dostosowania klaster wraca do stanu nadmiernego provisioningu.

GPU to skrajny przypadek. Raport CAST AI pokazuje, że średnie wykorzystanie GPU w klastrach Kubernetes wyniosło 5% — na AKS jeszcze mniej, bo 2%. Oznacza to, że na każdy wydany dolar 98 centów leży bezczynnie. Zmienne workloady AI — modele trenowane partiami, inference z nierównomiernym ruchem — często dostają dedykowany węzeł GPU, nawet jeśli faktycznie używają go przez kilkanaście minut dziennie.

Liczby, które trudno zignorować

Dane z raportu CAST AI za 2025 rok (dziesiątki tysięcy klastrów, mierzone przed włączeniem automatyzacji):

Organizacje, które wdrożyły automatyczny rightsizing, zmniejszyły provisionowane CPU średnio o 50%. Mniej niż 2% GPU działało na instancjach Spot w 2025 roku — mimo że Spot może oferować od 2x do prawie 5x niższe koszty w zależności od regionu.

Trzy warstwy odpowiedzi

Problem nie jest nowy — ale narzędzia dojrzały. W środowisku AKS dostępne są trzy komplementarne podejścia.

1. Automatyczne dostosowanie żądań — VPA i KEDA

Vertical Pod Autoscaler analizuje historyczne zużycie i rekomenduje lub automatycznie koryguje wartości requests i limits. W trybie Auto restartuje pody z nowymi wartościami — co w środowisku produkcyjnym wymaga ostrożności — ale w trybie Recommend dostarcza dane bez ingerencji, pozostawiając decyzję operatorowi.

KEDA (Kubernetes Event-driven Autoscaling) rozwiązuje komplementarny problem: skalowanie na podstawie metryk zewnętrznych — długości kolejki, liczby wiadomości w Service Bus, żądań do API. Dla workloadów AKS opartych na Azure Event Hub lub Azure Queue Storage KEDA potrafi skalować do zera podczas przestojów i z powrotem do wymaganej pojemności pod wpływem ruchu.

2. Node Auto Provisioning — właściwy węzeł dla właściwego workloadu

Node Auto Provisioning (NAP) w AKS — oparty na Karpenter — dobiera typ węzła do faktycznych potrzeb poda zamiast korzystać z predefiniowanego node pool. Jeśli pod potrzebuje 2 vCPU i 4 GB RAM, NAP może uruchomić węzeł dokładnie tej klasy, zamiast wrzucać go do puli z węzłami o 16 vCPU i 64 GB.

Kombinacja NAP ze Spot instances dla workloadów tolerujących przerwania — zadania CI, przetwarzanie wsadowe, część workloadów ML — może dramatycznie zmienić strukturę kosztów bez zmiany żadnego manifestu aplikacji.

3. Widoczność kosztów per namespace — narzędzie Burn

Tutaj pojawia się narzędzie, które zwróciło uwagę uczestników SREday London dwa tygodnie temu: Burn autorstwa Özlem Tanrikulu.

Burn to narzędzie CLI napisane w Go, które odpowiada na pytanie: "który namespace i który pod palą pieniądze i ile dokładnie?". Działa bez agenta w klastrze, bez konfiguracji — czyta dane z Kubernetes API, opcjonalnie z Prometheus dla faktycznego zużycia, i pobiera aktualne ceny z Azure Pricing API. Wynik to rozbicie kosztów per namespace, per pod, z widocznością różnicy między zarezerwowanymi a faktycznie używanymi zasobami

# Instalacja przez Homebrew
brew install tanrikuluozlem/tap/burn

# Analiza kosztów całego klastra
burn analyze

# Szczegółowy widok konkretnego namespace'u
burn analyze --namespace production

# Tygodniowe średnie zużycia z Prometheusa
burn analyze --period 7d

# Rekomendacje z kubectl commandami
burn analyze --ai

Kluczowa cecha: flaga --ai generuje nie tylko raport, ale konkretne polecenia kubectl do wdrożenia rekomendowanych zmian. Burn wskazuje też workloady nadające się do przeniesienia na Spot instances — z podaniem aktualnych rabatów i wskaźników przerwań dla danego regionu.

Dlaczego to ważne teraz

Rosnące klastry AKS to rosnące rachunki. Problem jest znany od lat, ale dotychczas wymagał albo drogich narzędzi komercyjnych (CAST AI, Kubecost, CloudHealth), albo znacznego nakładu manualnej pracy. Pojawiające się narzędzia open source, takie jak Burn, obniżają próg wejścia — każdy zespół może w kilka minut zobaczyć, ile faktycznie kosztuje jego klaster per namespace, bez podpisywania kontraktu z kolejnym SaaS.

Jednocześnie dane CAST AI pokazują, że problem nie rozwiązuje się sam: rok do roku marnotrawstwo zasobów rośnie o 20%, mimo że narzędzia do optymalizacji są powszechnie dostępne. Bez stałego mechanizmu monitorowania i korygowania — VPA, NAP, narzędzia do cost visibility — klaster będzie driftował w kierunku overprovisioning niezależnie od jednorazowych wysiłków optymalizacyjnych.

Podsumowanie

AKS rośnie — i razem z nim rośnie odległość między zarezerwowanymi a faktycznie używanymi zasobami. Średnie 8% wykorzystania CPU i 20% pamięci to nie problem jednej organizacji, to systemowa cecha ekosystemu Kubernetes przy obecnych praktykach zarządzania zasobami.

Odpowiedź składa się z trzech warstw: widoczność kosztów per namespace (Burn), ciągłe dostosowanie żądań (VPA) i właściwy dobór węzłów (NAP + Spot). Żadna z tych warstw samodzielnie nie rozwiązuje problemu — działają razem.

Źródła: Cloud Native Now — Sharone Zitzman, CAST AI: 2026 State of Kubernetes Optimization Report, Burn — github.com/tanrikuluozlem/burn