Jak Kubernetes řídí škálování kontejnerů a vyvažování zátěže

Zvládnutí škálování a vyvažování zátěže v Kubernetes

Při nasazování kontejnerizovaných aplikací do produkce jsou dvěma nejkritičtějšími provozními úkoly zajištění schopnosti systému zvládat výkyvy provozu a udržování vysoké dostupnosti bez ručního zásahu. Kubernetes, de facto standard pro orchestraci kontejnerů, řeší tyto úkoly pomocí komplexní sady nástrojů pro správu, které automatizují jak škálování, tak distribuci provozu, ale mnoho týmů má potíže překročit základní konfigurace. Pochopením vnitřních mechanismů toho, jak Kubernetes řídí škálování kontejnerů a vyvažování zátěže, budete schopni navrhovat odolné systémy, které se přizpůsobují zátěži v reálném čase, optimalizují náklady na zdroje a odstraňují jednotlivé body selhání.

Co se naučíte

Porozumíte řídicím smyčkám, metrickým pipeline a síťovým proxy, které umožňují automatické škálování a objevování služeb v Kubernetes, a na konci budete schopni diagnostikovat úzká místa škálování, zvolit správnou strategii vyvažování zátěže pro vaše pracovní zatížení a implementovat konfigurace připravené pro produkci, které odolají náhlým špičkám provozu bez výpadků. Nejdůležitějším závěrem je, že efektivní škálování v Kubernetes vyžaduje holistický přístup, při kterém Horizontal Pod Autoscaler, cluster autoscaler a komponenty service mesh pracují v souladu, nikoli jako izolované funkce.

Dva pilíře: horizontální škálování a vyvažování zátěže služeb

Kubernetes zajišťuje elasticitu pomocí dvou vzájemně se doplňujících mechanismů: škálování počtu replik aplikace (podů) a distribuce síťového provozu mezi tyto repliky. Řídicí rovina nepřetržitě vyhodnocuje metriky zdrojů a uživatelské indikátory, aby rozhodla, kdy přidat nebo odebrat pody, zatímco datová rovina používá abstrakci služby založenou na virtuální IP pro směrování požadavků na zdravé koncové body. Toto rozdělení odpovědnosti – rozhodnutí o škálování přijímají kontroléry, zatímco směrování provozu řídí kube-proxy nebo sidecar-proxy service mesh – umožňuje každému subsystému vyvíjet se nezávisle, i když v praxi jsou hluboce propojeny.

Jak funguje Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA) je hlavním mechanismem toho, jak Kubernetes řídí škálování kontejnerů a vyvažování zátěže na úrovni podů. HPA pracuje jako řídicí smyčka, která periodicky dotazuje metrický server (obvykle Kubernetes Metrics Server pro metriky zdrojů nebo vlastní metrický adaptér pro signály specifické pro aplikaci) a porovnává pozorované hodnoty s cílovými. Pro škálování založené na CPU algoritmus vypočítá požadovaný počet replik podle vzorce:

desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))

Toto jednoduché proporcionální řízení funguje dobře pro stabilní pracovní zátěže, ale může způsobovat kmitání, pokud se metrika rychle mění. Pro zmírnění tohoto jevu HPA zahrnuje stabilizační funkce – ve výchozím nastavení se vyhýbá škálování dolů po dobu pěti minut a škáluje nahoru až po okně 3–15 sekund v závislosti na konfiguraci – aby se zabránilo „třepotání“. Podle oficiální dokumentace Kubernetes přijímá kontrolér HPA rozhodnutí o škálování na základě aritmetického průměru metrik podů, což znamená, že jeden „horký“ pod může zkreslit průměrnou hodnotu a způsobit zbytečné škálování nahoru (Kubernetes SIG-Autoscaling, 2023).

Vlastní a externí metriky pro pokročilé automatické škálování

Škálování založené na zdrojích (CPU a paměť) často nestačí pro moderní mikroslužby, jejichž úzká místa vznikají v hloubce front zpráv, fondech připojení k databázi nebo latenci požadavků. Kubernetes řeší tento problém pomocí Custom Metrics API a External Metrics API, které umožňují HPA konzumovat metriky z Prometheus, Datadog nebo monitorovacích systémů cloudových poskytovatelů. Například nasazení spotřebitele Kafka se může škálovat na základě zpoždění offsetů skupiny spotřebitelů, což zajišťuje, že výkon zpracování odpovídá objemu příchozích dat bez ohledu na zatížení CPU. Studie z roku 2022 publikovaná v IEEE Transactions on Cloud Computing ukázala, že automatické škálování založené na vlastních metrikách snížilo latenci na chvostu o 42 % ve srovnání se škálováním pouze podle CPU v architekturách řízených událostmi, i když vyžadovalo pečlivé nastavení intervalů sběru metrik (Chen et al., 2022). Při zavádění vlastních metrik se ujistěte, že váš metrický adaptér poskytuje data s dostatečnou granularitou – vzorkování každých 30 sekund je běžným základem, zatímco vysokofrekvenční obchodní systémy mohou vyžadovat rozlišení 5 sekund.

Cluster Autoscaler a škálování na úrovni uzlů

Zatímco HPA reguluje počet podů, Cluster Autoscaler reguluje počet pracovních uzlů v základní cloudové infrastruktuře. Tato dvouúrovňová hierarchie vytváří řetězec závislostí: Cluster Autoscaler spouští přidávání uzlů pouze tehdy, když existují neplánované pody kvůli nedostatku zdrojů, a odstraňuje uzly, když jsou nedostatečně vytížené a všechny jejich pody mohou být přeplánovány jinde. Oficiální FAQ Cluster Autoscaler uvádí, že rozhodnutí o škálování uzlů jsou přijímána s 10minutovým stabilizačním oknem, aby se zabránilo častým změnám velikosti, což může být problematické pro pracovní zátěže s náhlými trvalými špičkami, protože kumulativní latence (HPA škáluje pody nahoru + Cluster Autoscaler poskytuje uzly + načítání uzlů) může v mnoha cloudových prostředích přesáhnout pět minut. Pro aplikace citlivé na latenci zvažte použití fondů uzlů s předem přidělenou rezervou kapacity nebo zavedení proaktivního škálování založeného na predikované poptávce – tato metoda je zkoumána ve vědeckém článku „Proactive Autoscaling for Kubernetes“ (arXiv:2301.04567, 2023), kde bylo prokázáno snížení latence škálování o 30 % pomocí prediktivních modelů.

Směrování provozu: abstrakce Service a kube-proxy

Škálování podů je jen polovina řešení; je také nutné distribuovat příchozí provoz na správnou sadu zdravých replik. Každý objekt Service v Kubernetes funguje jako stabilní interní load balancer, poskytující pevnou IP adresu a DNS jméno, které abstrahují dynamické koncové body podů. Výchozí implementace používá kube-proxy, který běží na každém uzlu a udržuje pravidla iptables nebo IPVS, která převádějí IP adresy služeb na skutečné IP adresy podů. V režimu iptables každá služba vytváří pravděpodobnostní řetězec pravidel – rozdělení pravděpodobnosti je úměrné váze každého podu, což v podstatě zajišťuje vyvažování round-robin. Přístup iptables však může trpět snížením výkonu při škálování: cluster s 5000 službami a 50 000 koncovými body může zaznamenat zpoždění aktualizace pravidel 10–15 sekund, jak je zdokumentováno v testech výkonu Kubernetes. Režim IPVS, založený na modulu jádra Linux virtual server, poskytuje lepší škálovatelnost pro velké clustery a podporuje několik algoritmů vyvažování zátěže (round-robin, least connections, source hashing), které lze vybrat pomocí příznaku --ipvs-scheduler.

Typy služeb a externí přístup

Pro externí provoz přicházející do clusteru poskytuje Kubernetes tři typy služeb: NodePort, LoadBalancer a Ingress. NodePort otevírá statický port na IP adrese každého uzlu, vhodný pro vývoj nebo lokální prostředí, kde není samostatný externí load balancer. Typ LoadBalancer se integruje s API cloudových poskytovatelů (AWS ELB, Azure Load Balancer, GCP Cloud Load Balancing) pro poskytnutí vyhrazeného externího load balanceru, který přesměrovává provoz na NodePorts všech uzlů. Tento přístup přenáší kontroly stavu a ukončení SSL na cloudového poskytovatele, ale zahrnuje náklady na každý zdroj – například AWS Application Load Balancers stojí přibližně $0,0225 za hodinu plus poplatky za zpracování dat (AWS Pricing, 2024). Ingress na druhé straně pracuje na úrovni HTTP/HTTPS a poskytuje směrování na základě cesty a hostitele, což umožňuje jednomu load balanceru obsluhovat více služeb. Kontrolér Ingress (NGINX, Traefik nebo AWS ALB Ingress Controller) implementuje skutečná pravidla směrování a provádí ukončení TLS, ukládání do mezipaměti a omezování rychlosti.

Pokročilé vyvažování zátěže s Service Mesh

Pro týmy vyžadující jemnou kontrolu nad chováním provozu – jako jsou canary nasazení, circuit breaking nebo vnášení chyb – poskytuje service mesh, jako je Istio nebo Linkerd, výkonnější alternativu k kube-proxy. Tyto mesh nasazují sidecar-proxy (Envoy nebo Linkerd2-proxy) vedle každého podu, čímž tvoří vyhrazenou datovou rovinu, která zachycuje veškerý příchozí a odchozí provoz. Řídicí rovina spravuje distribuci konfigurace a sběr telemetrie, což umožňuje komplexní politiky vyvažování zátěže na aplikační úrovni. Podle analýzy z roku 2023 provedené komunitou koncových uživatelů Cloud Native Computing Foundation koreluje zavedení service mesh se snížením doby obnovy při částečných výpadcích o 45 %, což je vysvětlováno automatickými opakováními a detekcí odlehlých hodnot. Režie je však značná: proxy Envoy od Istio přidává přibližně 5–10 ms latence na každý skok a spotřebovává 0,5–1 vCPU na pod při mírném provozu. Při výběru mezi kube-proxy a service mesh zvažte, zda vaše požadavky přesahují základní round-robin distribuci – pokud potřebujete zrcadlení provozu, JWT autentizaci nebo vážené směrování na základě HTTP hlaviček, service mesh je opodstatněný; jinak stačí nativní zdroje Service a Ingress.

Horizontal Pod Autoscaling v praxi: konfigurace a nastavení

Pro ilustraci toho, jak Kubernetes řídí škálování kontejnerů a vyvažování zátěže v reálném nasazení, zvažte typickou webovou aplikaci s následující konfigurací HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "500"
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 2
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Pods
        value: 5
        periodSeconds: 30
      - type: Percent
        value: 100
        periodSeconds: 30
      selectPolicy: Max

Tento HPA používá jak zatížení CPU, tak vlastní metriku rychlosti HTTP požadavků, s oddělenými stabilizačními okny a politikami škálování. Politika scaleUp upřednostňuje nejagresivnější variantu (buď přidání 5 podů, nebo zdvojnásobení aktuálního počtu) každých 30 sekund, což umožňuje rychlou reakci na špičky provozu. Politika scaleDown omezuje odstraňování na 2 pody za minutu po 5minutovém ochlazení, čímž zabraňuje kmitání při proměnlivé zátěži. Stabilizační okna – 300 sekund pro škálování dolů a 30 sekund pro škálování nahoru – jsou převzata z výchozích doporučení v průvodci HPA od Kubernetes, upravených pro webovou aplikaci s předvídatelnými denními vzory provozu.

Běžné chyby a strategie jejich zmírnění

I při správné konfiguraci se týmy často setkávají s problémy škálování a vyvažování zátěže v Kubernetes. Jedním z běžných problémů je efekt „thundering herd“, kdy náhlá špička provozu způsobí, že HPA škáluje mnoho replik najednou, čímž přetíží plánovač a API server. Abyste tomu předešli, použijte spec.behavior.scaleUp.selectPolicy: Max s menší hodnotou periodSeconds, aby se události škálování rozložily do několika cyklů. Další chybou je spoléhání se pouze na metriky CPU u aplikací náročných na paměť – Java aplikace s velkými haldami mohou vykazovat vysoké využití paměti při nízkém zatížení CPU, což brání HPA spustit škálování. Řešením je použití metrik založených na paměti nebo vlastních metrik odrážejících propustnost aplikace. Kromě toho se ujistěte, že váš load balancer (kube-proxy nebo service mesh) provádí kontroly stavu s odpovídajícími prahy – výchozí práh pro readiness probe (3 selhání za 10 sekund) může být pro Java aplikace s latencí studeného startu příliš agresivní; zvažte zvýšení initialDelaySeconds na 60–120 sekund v závislosti na době spouštění vaší aplikace.

Monitorování a pozorovatelnost pro rozhodování o škálování

Efektivní škálování vyžaduje viditelnost jak metrik na úrovni systému, tak obchodních ukazatelů. Ekosystém Prometheus v kombinaci s dashboardy Grafana je de facto standardem pro pozorovatelnost Kubernetes. Klíčové metriky pro monitorování:

• Stav HPA: kube_horizontalpodautoscaler_status_desired_replicas a kube_horizontalpodautoscaler_status_current_replicas pro detekci zpoždění škálování
• Latence plánování: kube_scheduler_e2e_scheduling_duration_seconds pro identifikaci úzkých míst v umísťování podů
• Stav load balanceru: kube_service_status_load_balancer_ingress pro cloudové load balancery
• Latence požadavků a míra chyb: odvozené z metrik Istio nebo NGINX Ingress pro korelaci akcí škálování s uživatelskou zkušeností

Podle zprávy „State of Kubernetes Observability 2024“ od D2iQ týmy, které instrumentují vlastní obchodní metriky (např. aktivní relace, hloubka fronty, rychlost platebních transakcí), zaznamenávají o 38 % méně incidentů nadměrného přidělování zdrojů ve srovnání s týmy používajícími pouze metriky CPU/paměti. To je v souladu s doporučením Google Cloud Architecture Center definovat Service Level Objectives (SLO), které řídí akce škálování – například škálování, když 99. percentil latence překročí 200 ms po dobu delší než 2 minuty, nikoli reagování pouze na metriky zdrojů.

Často kladené otázky

Škáluje Kubernetes automaticky kontejnery na základě provozu nebo CPU? Ano, Kubernetes může automaticky škálovat kontejnery pomocí Horizontal Pod Autoscaler, který upravuje počet replik na základě pozorovaného zatížení CPU, spotřeby paměti nebo vlastních metrik, jako je rychlost požadavků. Automatické škálování však není ve výchozím nastavení zapnuto – musíte explicitně definovat zdroj HPA s politikami škálování a prahy metrik pro vaše nasazení.

Jak Kubernetes vyvažuje provoz mezi pody? Služby Kubernetes poskytují interní vyvažování zátěže pomocí kube-proxy, který udržuje síťová pravidla distribuující provoz na koncové body podů přes iptables nebo IPVS. Pro externí provoz zpracovávají směrování kontroléry Ingress nebo cloudové služby LoadBalancer. Vyvažování zátěže se obvykle provádí algoritmem round-robin, ale service mesh nabízejí pokročilejší algoritmy, jako je least-requests nebo consistent hashing.

Jaký je rozdíl mezi Horizontal Pod Autoscaler a Cluster Autoscaler? Horizontal Pod Autoscaler upravuje počet replik podů v rámci nasazení na základě metrik poptávky, zatímco Cluster Autoscaler upravuje počet pracovních uzlů v clusteru, když pody nelze naplánovat kvůli nedostatku zdrojů. Pracují vzájemně se doplňujícím způsobem: HPA reaguje na změny pracovního zatížení a Cluster Autoscaler poskytuje základní infrastrukturu pro podporu zvýšeného počtu podů.

Mohu škálovat pody Kubernetes na základě vlastních metrik aplikace? Rozhodně. Kubernetes podporuje vlastní a externí metriky prostřednictvím Custom Metrics API a External Metrics API. Musíte nasadit metrický adaptér, jako je Prometheus Adapter nebo Datadog Cluster Agent, který poskytuje metriky specifické pro vaši aplikaci kontroléru HPA. Běžné vlastní metriky zahrnují délku fronty, aktivní připojení nebo rychlost zpracování objednávek.

Jaké algoritmy vyvažování zátěže Kubernetes podporuje? Nativní služba (kube-proxy) podporuje round-robin a v režimu IPVS další algoritmy, jako je least connections, source hashing a vážený round-robin. Kontroléry Ingress a service mesh rozšiřují toto o HTTP směrování, canary nasazení a vzory circuit breaking. Volba závisí na vzorech provozu vaší aplikace – jednoduché bezstavové služby fungují dobře s round-robin, zatímco stavové scénáře nebo scénáře s lepivými relacemi vyžadují session affinity nebo consistent hashing.

Zdroje

1. Kubernetes SIG-Autoscaling. (2023). Horizontal Pod Autoscaler Walkthrough. Kubernetes Documentation. https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
2. Chen, L., et al. (2022). "Custom-Metric Autoscaling for Microservices: A Comparative Study." IEEE Transactions on Cloud Computing, 10(4): 2891-2905.
3. Kubernetes Cluster Autoscaler. (2024). FAQ and Best Practices. https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
4. Zhao, W., & Zhang, Y. (2023). "Proactive Autoscaling for Kubernetes Using Predictive Models." arXiv:2301.04567.
5. Cloud Native Computing Foundation. (2023). Service Mesh End-User Survey Report. CNCF Technical Advisory Group.
6. AWS Pricing. (2024). Elastic Load Balancing Pricing. https://aws.amazon.com/elasticloadbalancing/pricing/
7. D2iQ. (2024). State of Kubernetes Observability 2024. Industry Report.
8. Google Cloud Architecture Center. (2023). Scaling Microservices with Kubernetes. https://cloud.google.com/architecture/scaling-microservices

— Editorial Team