Kubernetes na dedikované infrastruktuře — proč ne AWS?

Managed Kubernetes služby od AWS, Azure a Google Cloud vypadají na první pohled jednoduše — založíte cluster, nasadíte pody, platíte průběžně. Realita je jiná. EKS účtuje 73 USD/měsíc pouze za control plane, ale skutečné náklady se skrývají v NAT gateway (32+ USD/měsíc za AZ), cross-AZ data transferu (0,01 USD/GB), load balancerech (16+ USD/měsíc za každý) a EBS discích. Pro steady-state workloady — aplikace běžící 24/7 s předvídatelnými nároky na zdroje — dedikovaný Kubernetes na bare metal infrastruktuře přináší o 40–60 % nižší celkové náklady s lepším a předvídatelnějším výkonem.

Kolik EKS skutečně stojí nad rámec 73 USD/měsíc za control plane?

Amazon EKS inzeruje poplatek za control plane 0,10 USD/hodinu (73 USD/měsíc). To je nejviditelnější náklad a paradoxně nejmenší položka vašeho účtu. Skutečné náklady se kumulují v podpůrných službách, které jsou pro produkční cluster fakticky povinné.

Rozpis typického produkčního EKS clusteru s 10 worker nody (m5.xlarge) ve 3 availability zónách:

Cluster EKS za 73 USD/měsíc ve skutečnosti stojí přibližně 1 846 USD/měsíc pro skromný produkční setup. A to nezahrnuje slevy za Reserved Instance nebo Savings Plan — které vyžadují závazky na 1–3 roky a platby předem.

Odkud pocházejí skryté náklady?

Tři největší skryté nákladové faktory v managed Kubernetes:

1. Ceny NAT Gateway. Každý privátní subnet potřebuje NAT Gateway pro odchozí přístup k internetu (stahování kontejnerových obrazů, přístup k externím API). AWS účtuje 0,045 USD/hodinu (32,40 USD/měsíc) za NAT Gateway plus 0,045 USD/GB za zpracovaná data. Se 3 AZ pro vysokou dostupnost to je 97 USD/měsíc ještě před jakýmkoli významným přenosem dat.

2. Poplatky za přenos dat. AWS účtuje 0,01 USD/GB za cross-AZ provoz. V Kubernetes clusteru pody komunikují napříč AZ neustále — service mesh provoz, databázová spojení, distribuované cachování. Středně vytížený cluster snadno generuje 200+ GB/měsíc cross-AZ provozu. Přenos dat ven na internet stojí 0,09 USD/GB za prvních 10 TB.

3. Kumulace load balancerů. Každý Kubernetes Service typu LoadBalancer zřídí samostatný ALB nebo NLB. Za 16,20 USD/měsíc základní poplatek plus LCU poplatky za load balancer — cluster s 5 externě přístupnými službami stojí 81+ USD/měsíc jen za load balancery. Ingress controllery to redukují, ale přidávají vlastní složitost.

Jak si na skrytých nákladech stojí AKS a GKE?

Cenové struktury se mezi poskytovateli liší, ale vzorec je konzistentní: inzerovaná cena podhodnocuje skutečné náklady.

Srovnání nákladů: Managed Kubernetes služby (10 worker nodů, produkční setup)

Klíčový poznatek: AKS nabízí bezplatnou úroveň control plane (bez uptime SLA), čímž se jeví jako nejlevnější. Ale náklady Azure za NAT Gateway, load balancery a úložiště přivádějí celkový součet do srovnatelného rozmezí. Režim Autopilot u GKE zjednodušuje provoz, ale účtuje 23% přirážku na výpočetní zdroje.

U PROZETA jsou všechny infrastrukturní komponenty — compute, úložiště, síťování, load balancing, monitoring — zahrnuty v jediném předvídatelném měsíčním poplatku. Žádné poplatky za GB přenesených dat. Žádné poplatky za NAT Gateway. Žádná kumulace load balancerů.

Více o PROZETA Kubernetes a úložišti BlackStor.

Proč má dedikovaný Kubernetes lepší výkon pro steady-state workloady?

Steady-state workloady — databáze, aplikační servery, fronty zpráv, CI/CD runnery — běží nepřetržitě s předvídatelnými nároky na zdroje. Tyto workloady reprezentují 60–80 % enterprise computu v typických organizacích. Pro tyto workloady poskytuje dedikovaná infrastruktura měřitelné výkonnostní výhody oproti sdílené cloudové infrastruktuře.

Co je problém noisy neighbor v managed Kubernetes?

V prostředích hyperscalerů jsou vaše worker nody virtuální stroje sdílející fyzický hardware s dalšími tenanty. To vytváří efekt „hlučného souseda" (noisy neighbor):

• CPU steal time: Když ostatní tenanti na stejném fyzickém hostu spotřebovávají CPU burstově, vaše workloady zaznamenávají zvýšenou latenci. Instance AWS m5.xlarge pravidelně vykazují 2–5 % CPU steal time, se špičkami 10+ % během burst aktivity sousedů.
• Variabilita síťového I/O: Sdílená síťová rozhraní znamenají kolísavou šířku pásma. Benchmarkové testy konzistentně ukazují 15–30% varianci síťové propustnosti na sdílených cloudových instancích.
• Nepředvídatelnost storage I/O: I s provisioned IOPS na EBS se skutečný výkon liší, protože podkladová storage infrastruktura je sdílená. AWS dokumentuje, že gp3 disky dosahují svého základního výkonu „v průměru za čas" — což znamená, že jednotlivé operace mohou překročit provisioned latenci.
• NUMA efekty: VM umístěné přes NUMA uzly na fyzickém hostu zaznamenávají vyšší latenci přístupu k paměti u cross-NUMA operací.

Na dedikované infrastruktuře tyto problémy neexistují. Vaše Kubernetes nody běží na fyzických serverech dedikovaných vašim workloadům. CPU cykly, paměťová propustnost, síťová propustnost a storage IOPS jsou 100% dostupné vašim aplikacím. Žádný steal time, žádná konkurence o šířku pásma, žádná variabilita IOPS.

Jaké výkonnostní parametry lze očekávat na dedikovaném hardware?

PROZETA Kubernetes běží na serverech HPE ProLiant s:

• CPU: Nejnovější generace procesorů Intel Xeon nebo AMD EPYC, plná jádra dedikovaná vašim workloadům. Nulový CPU steal time.
• Paměť: DDR5 ECC RAM s konzistentní latencí přístupu — žádná NUMA překvapení z umístění VM.
• Úložiště: BlackStor NVMe úložiště dodávající konzistentní sub-milisekundovou latenci. Na rozdíl od cloudového blokového úložiště není BlackStor založen na Cephu — využívá proprietární architekturu optimalizovanou pro workloady s nízkou latencí.
• Síť: Dedikovaná rozhraní 25 Gbps s konzistentní propustností. Žádná sdílená šířka pásma, žádné výkonnostní tvrzení „až do".

Pro workloady citlivé na latenci (databáze, real-time zpracování, finanční aplikace) není rozdíl mezi dedikovanou a sdílenou infrastrukturou marginální — typicky jde o 2–5násobné zlepšení konzistence P99 latence.

Kdy má dedikovaný Kubernetes větší finanční smysl než EKS?

Bod zvratu závisí na charakteristikách workloadů, ale vzorec je konzistentní: steady-state workloady dosáhnou bodu zvratu rychle.

Profily workloadů, kde dedikovaný hardware vítězí

1. Produkční workloady běžící nepřetržitě. Pokud váš cluster běží 24/7/365 (a většina produkčních clusterů ano), platíte plné on-demand sazby, nebo se zavazujete k 1–3letým Reserved Instances. Dedikovaná infrastruktura nabízí srovnatelné nebo lepší ceny bez závazku RI.

2. Datově intenzivní aplikace. Každý GB přenesených dat na cloudovém Kubernetes má svou cenu. Pokud vaše aplikace zpracovávají významné objemy dat — agregace logů, analytické pipeline, zpracování médií — poplatky za přenos dat mohou překročit náklady na compute. Na dedikované infrastruktuře je interní přenos dat zdarma a externí šířka pásma je v ceně.

3. Storage-heavy workloady. EBS gp3 stojí 0,08 USD/GB/měsíc. Pro databázový cluster vyžadující 5 TB úložiště to je 400 USD/měsíc jen za úložiště — před poplatky za IOPS. BlackStor NVMe úložiště na infrastruktuře PROZETA je součástí compute balíčku s výrazně lepším výkonem.

4. Multi-cluster setupy. Organizace často provozují oddělené clustery pro vývoj, staging a produkci. Každý EKS cluster přidává 73 USD/měsíc za control plane plus duplicitní NAT Gateways a load balancery. Na dedikované infrastruktuře nemá provoz více Kubernetes clusterů na stejném hardware žádné dodatečné náklady za cluster.

5. Compliance-citlivé workloady. Pokud vaše workloady musí splňovat požadavky GDPR na datovou suverenitu, NIS2 na bezpečnost dodavatelského řetězce nebo DORA na řízení ICT rizik, český cloud s vlastním datacentrem eliminuje celou kategorii compliance rizik — a s nimi spojené náklady na audit a právní služby.

Příklad výpočtu bodu zvratu

Uvažujme středně velké nasazení: 20 worker nodů, 2 TB úložiště, 1 TB/měsíc data transfer:

I s 1letými Reserved Instances (které vyžadují platbu předem a závazek) se náklady EKS snižují přibližně o 30–40 % — stále výsledek 24 000–29 000 USD/rok za tuto konfiguraci. Dedikovaná infrastruktura od PROZETA typicky vychází o 40–60 % níže než on-demand cloudové ceny za ekvivalentní nebo lepší hardware.

A co flexibilita škálování — neškáluje se cloudový Kubernetes lépe?

Toto je nejčastější námitka proti dedikované infrastruktuře a zaslouží si nuancovanou odpověď.

Kdy cloudové auto-scaling skutečně pomáhá

Cloudové auto-scaling má hodnotu pro:

• Nepředvídatelný burst provoz: Flash sales v e-commerce, virální obsah, sezónní špičky. Pokud je váš provozní pattern skutečně nepředvídatelný a burstový, cloudová elasticita má reálnou hodnotu.
• Krátkodobé dávkové workloady: Úlohy zpracování dat, ML tréninky, CI/CD pipeline, které běží hodiny, nikoli dny. Pay-per-use zde dává smysl.
• Nové produkty s neznámou poptávkou: Startupy a nové produkty, kde vzorce poptávky nejsou ještě ustáleny.

Kdy cloudové auto-scaling nepotřebujete

Pro většinu enterprise workloadů „auto-scaling" řeší problém, který neexistuje:

• Většina produkčních workloadů je steady-state. Databázové servery, aplikační backendy, API gateways a message brokery běží na relativně předvídatelných úrovních zátěže. Průzkum Datadog z roku 2024 zjistil, že průměrný Kubernetes cluster běží na 30–50 % CPU utilizaci — což znamená, že většina organizací je již přeprovisovaná.
• Latence auto-scalingu je významná. Cluster Autoscaler v EKS trvá 3–10 minut na provisioning nových nodů. Karpenter to snižuje na 1–2 minuty. U většiny aplikací platí: pokud nedokážete zvládnout dopravní špičku ve stávající kapacitě po dobu 2+ minut, máte problém s architekturou, nikoli s infrastrukturou.
• Over-provisioning v cloudu je drahý. Protože cloudové škálování není okamžité, organizace over-provisionují o 50–100 % jako rezervu. Na dedikovaném hardware tento over-provisioning stojí výrazně méně.

Hybridní přístup: PROZETA podporuje hybridní architektury, kde steady-state workloady běží na dedikovaném Kubernetes a burst kapacita je dostupná na cloudu Tier5 OpenStack. To vám dává nákladové výhody dedikované infrastruktury s cloudovou elasticitou pro skutečné potřeby škálování — bez cenového modelu hyperscalerů.

Jak dedikovaný Kubernetes zjednodušuje compliance?

Provoz Kubernetes na dedikované infrastruktuře v českém datacentru řeší více compliance požadavků současně:

• Datová suverenita GDPR: Kontejnerové obrazy, persistentní volume, logy, metriky i secrets — vše zůstává v pražském datacentru. Žádné datové toky na infrastrukturu kontrolovanou z USA.
• NIS2 bezpečnost dodavatelského řetězce: Váš poskytovatel Kubernetes infrastruktury je česká společnost (PRO-ZETA a.s., certifikace ISO 27001) bez zahraniční mateřské entity. Posouzení rizik dodavatelského řetězce je přímočaré.
• DORA řízení ICT rizik: Pro finanční instituce dedikovaná infrastruktura snižuje koncentrační riziko oproti provozu všeho na jednom hyperscalerovi. Výstupní strategie jsou jednodušší, když infrastrukturu kontrolujete.
• Jednoduchost auditu: Fyzické a logické přístupové audity zahrnují jedinou jurisdikci, jediný právní rámec a přímý přístup do datacentra v Praze.

Výhoda z hlediska compliance není jen teoretická. Organizace, které přešly na dedikovanou infrastrukturu, reportují 30–50% zkrácení času na přípravu compliance auditů, protože architektura infrastruktury eliminuje celé kategorie compliance otázek.

Jak vypadá migrace z EKS na dedikovaný Kubernetes?

Migrace z managed Kubernetes na dedikovaný Kubernetes je přímočará, protože Kubernetes je Kubernetes — API je stejné bez ohledu na podkladovou infrastrukturu.

Typické migrační kroky:

1. Provisioning infrastruktury (1–2 týdny): PROZETA provisionuje dedikované servery, instaluje Kubernetes (pomocí kubeadm nebo RKE2), konfiguruje síťování (Calico/Cilium) a nastavuje BlackStor storage classes.
2. Replikace konfigurace (1 týden): Export Kubernetes manifestů (Deployments, Services, ConfigMaps, Secrets, Ingress) z EKS. Adaptace cloud-specifických anotací (ALB Ingress → Nginx/Traefik Ingress, EBS StorageClass → BlackStor StorageClass).
3. Migrace dat (1–2 týdny): Migrace persistentních volume pomocí Velero backup/restore nebo přímého přenosu dat. Migrace databází může využít logickou replikaci pro cutover bez výpadku.
4. DNS cutover a validace (1 týden): Přesměrování provozu na nový cluster pomocí DNS blue/green deploymentu. Validace funkcionality aplikací, výkonu a monitoringu.

Celková doba: 4–6 týdnů pro typický produkční cluster. Inženýrský tým PROZETA zajišťuje setup infrastruktury a poskytuje migrační podporu po celou dobu procesu.

Hlavní adaptační body jsou cloud-specifické integrace: - AWS ALB Ingress Controller → Nginx Ingress Controller nebo Traefik (obojí open source, bez licenčních nákladů) - EBS CSI driver → BlackStor CSI driver - AWS IAM for ServiceAccounts (IRSA) → Standardní Kubernetes RBAC + externí správa secrets - CloudWatch Container Insights → Prometheus + Grafana (součást PROZETA Kubernetes)

Často kladené otázky

Je provoz dedikovaného Kubernetes složitější než EKS?

PROZETA spravuje Kubernetes control plane, OS patching a monitoring infrastruktury. Váš tým interaguje se stejným Kubernetes API jako u EKS. Provozní rozdíl je minimální — nasazujete stejné Helm charty, stejné kubectl příkazy, stejné CI/CD pipeline.

Mohu na dedikované infrastruktuře stále používat Kubernetes auto-scaling?

Ano. Horizontal Pod Autoscaler (HPA) a Vertical Pod Autoscaler (VPA) fungují na dedikovaném Kubernetes identicky. Cluster auto-scaling (přidávání nových nodů) lze nakonfigurovat s cloudem Tier5 od PROZETA pro burst kapacitu — cloudová elasticita pro skutečné potřeby škálování.

Co s managed add-ony jako AWS RDS, ElastiCache nebo SQS?

Dedikovaná infrastruktura nevylučuje managed databáze ani fronty zpráv. PROZETA nabízí managed PostgreSQL, Redis a další služby na dedikované infrastruktuře. Alternativně je provoz těchto služeb na vašem vlastním Kubernetes clusteru (pomocí operátorů jako CloudNativePG nebo Redis Operator) přímočarý na dedikovaném hardware s NVMe úložištěm.

Jak se BlackStor srovnává s EBS nebo Azure Disk?

BlackStor dodává konzistentní sub-milisekundovou latenci na NVMe úložišti bez variability sdíleného cloudového blokového úložiště. Na rozdíl od řešení založených na Cephu, běžných v OpenStack nasazeních, BlackStor používá proprietární architekturu, která se vyhýbá známým latenčním špičkám Cephu při těžkém zápisu. Pro databázové workloady je konzistentní I/O výkon nejvýznamnější výhodou.

Co když můj workload přeroste kapacitu dedikovaného clusteru?

PROZETA podporuje rozšíření kapacity s typickými dodacími lhůtami 1–2 týdny pro další fyzické servery. Pro okamžitou burst kapacitu mohou workloady přetéci na cloud Tier5 OpenStack. Tento hybridní model vám dává předvídatelnost nákladů dedikované infrastruktury s flexibilitou pro zvládnutí neočekávané poptávky.