Nasadenie AI agentov na Kubernetes: architektúra, škálovanie a kedy sa K8s oplatí

Nasadiť AI agentov na Kubernetes znamená prevádzkovať komponenty agentového systému (agentovú službu, tool servery resp. MCP servery, vektorovú databázu, inferenčný engine a message queue) ako kontajnerizované workloady na K8s klastri. Kubernetes zabezpečuje škálovanie, GPU scheduling, správu stavu, správu secrets a observability pre produkčnú prevádzku agentov so suverenitou v EÚ. Je to silný nástroj, ale nie samoúčel. Tento článok ukazuje architektúru, mechaniku škálovania a hlavne to, kedy sa táto námaha vôbec oplatí.

• Architektúra: Rozlož agentový systém na oddelené služby (orchestrátor, tool/MCP servery, inferenčný engine, vektorová databáza, queue) a každú prevádzkuj ako samostatný workload.
• Škálovanie: Stateless pody agentov škálujú elasticky cez Horizontal Pod Autoscaler; inferenčné GPU pody sa plánujú na dedikované GPU uzly a z nákladových dôvodov zostávajú trvalo spustené.
• Rozhodnutie: Kubernetes sa oplatí pri vysokej trvalej záťaži alebo pri prísnych požiadavkách na suverenitu či latenciu. Pod touto hranicou sa managed API a serverless dajú rýchlejšie spustiť do prevádzky a sú lacnejšie.

Kontajnerová architektúra agentového systému

Produkčný AI agent nie je monolit, ale súbor mikroslužieb. Toto rozdelenie nie je samoúčelné, ale vyplýva z rozdielnych profilov škálovania, stavu a bezpečnosti jednotlivých komponentov.

Agentová služba (orchestrátor)

Agentová služba je mozog systému: vykonáva orchestračnú logiku, rozhoduje o volaniach nástrojov a plánuje kroky. Zvyčajne stojí na frameworku ako LangGraph, CrewAI alebo AutoGen, prípadne na platforme dodávateľa ako PhariaAI (Heidelberg) alebo Microsoft Foundry Agent Service (predtým Azure AI Foundry Agent Service). Pre architektúru je rozhodujúce, aby táto služba zostala stateless. Len tak ju Kubernetes môže voľne škálovať, reštartovať a rozložiť na viacero replík. Celý stav sa presúva do externých úložísk.

Tool servery a MCP servery

Model Context Protocol (MCP) sa etabloval ako štandardné rozhranie, cez ktoré agenti pristupujú k externým nástrojom a dátovým zdrojom. V enterprise prostredí v regióne DACH bežia MCP servery väčšinou ako služby vo vnútri VPC (In-VPC), umiestnené spolu s runtime agentov a pripojené cez mTLS. To je predvolený vzor pre integrácie so SAP, Salesforce, ServiceNow, M365 a internými databázami. Pri scenároch vo výrobných závodoch alebo pobočkách sa MCP servery nasadzujú na edge, blízko dát, a centrálna orchestrácia ich volá cez dedikované linky (ExpressRoute, Direct Connect). Pri regulovaných workloadoch platí: namiesto jedného multi-tenant servera dedikované MCP servery pre každú obchodnú jednotku s oddelenými audit trailmi.

Inferenčný engine

Tu beží jazykový model. K roku 2026 je výber jasne ohraničený:

• vLLM (pôvodom z UC Berkeley) je de facto štandard pre produkčný self-hosting: PagedAttention, najširšia podpora hardvéru, endpointy kompatibilné s OpenAI.
• SGLang (LMSYS) podľa benchmarkov LMSYS dosahuje približne o 29 percent vyššiu priepustnosť na modeloch 7B–8B na H100 a lepšiu tail latenciu; ideálny pre multi-turn chat, RAG-intenzívne a štruktúrované workloady.
• NVIDIA NIM balí vLLM/TensorRT-LLM/SGLang do hotových kontajnerov a je najpragmatickejšou on-prem cestou pre stredné firmy v regióne DACH, je však viazaný na licenciu NVIDIA AI Enterprise.
• TensorRT-LLM dosahuje špičkovú priepustnosť na hardvéri NVIDIA, beží však len na NVIDIA a je prevádzkovo náročný.

Dôležitá poznámka pre existujúce systémy: Hugging Face 11. decembra 2025 presunul TGI (Text Generation Inference) do režimu údržby a pri nových nasadeniach odkazuje na vLLM alebo SGLang. Kto dnes používa TGI, nemusí v panike migrovať, nové projekty by však naň už stavať nemal.

Vektorová databáza a message queue

Vektorová databáza (Qdrant, Weaviate alebo pgvector) uchováva embeddingy pre RAG. Je typickým kandidátom na StatefulSet s PersistentVolumes, pretože embeddingy spolu s pôvodnými chunkami dosahujú veľkosti v terabajtoch a potrebujú stabilnú identitu podu aj perzistentné úložisko. Message queue (napríklad RabbitMQ, NATS alebo Redis Streams) oddeľuje dlho bežiace asynchrónne úlohy agentov (spracovanie dokumentov, dávkové analýzy) od synchrónnej cesty požiadaviek a umožňuje pooly workerov, ktoré škálujú nezávisle.

Mapovanie komponentov: čo patrí na ktorý K8s objekt

Nasledujúca tabuľka je kľúčovou referenciou pre nasadenie agentov. Každému komponentu priraďuje vhodný Kubernetes objekt a uvádza rozhodujúcu architektonickú poznámku.

Škálovanie: HPA, GPU scheduling a dve osi

Stacky agentov škálujú pozdĺž dvoch úplne odlišných osí, a to je najčastejší kameň úrazu.

Stateless os (CPU): Agentová služba, MCP servery a AI gateway sú lacné CPU workloady. Škálujú elasticky cez Horizontal Pod Autoscaler (HPA): pri špičkách záťaže pribúdajú repliky, pri nečinnosti sa rušia. Pre workery, ktoré spracúvajú úlohy z queue, sa hodí KEDA, ktorý škáluje podľa hĺbky queue, a nie iba podľa CPU.

GPU os (inferencia): Tu platí iná logika. GPU uzly sa klastru sprístupnia cez NVIDIA Device Plugin; pody si GPU vyžiadajú cez resource limit nvidia.com/gpu. Pomocou node selektorov, taints a tolerations sa inferenčné pody dostanú cielene na drahé GPU uzly, zatiaľ čo stateless workloady zostávajú na CPU uzloch. Zásadný rozdiel: GPU kapacita zostáva väčšinou trvalo spustená namiesto elastickej, pretože nečinné GPU sú vôbec najdrahší capex. Skutočná elasticita cez Cluster Autoscaler funguje len tam, kde cloudový poskytovateľ dodáva GPU uzly dostatočne rýchlo. Pri dedikovanej kapacite Blackwell (B200/GB200), ktorú poskytovatelia prideľujú len v pevných kontingentoch, to tak nie je.

Matematika GPU pamäte určuje, koľko modelov sa zmestí na jeden uzol. Orientačné pravidlo pre váhy: počet parametrov krát bajty na parameter. Model 70B potrebuje pri BF16 (2 bajty) približne 140 GB, pri FP8 približne 70 GB, pri AWQ-INT4 približne 35 GB. K tomu sa pridáva KV cache, ktorá rastie s veľkosťou batchu a dĺžkou sekvencie (v produkčnej prevádzke rádovo 10–40 GB). V praxi sa model 70B zmestí na jednu H200 (141 GB) len v kvantizovanej podobe, napríklad v FP8 s približne 70 GB plus KV cache. Pri BF16 nechávajú váhy pre KV cache sotva miesto. Vtedy treba tenzorový paralelizmus cez viacero GPU jedného uzla prepojených cez NVLink. Dve H100 (spolu 160 GB) na váhy plus KV cache podľa výpočtu nestačia. Pre produkčné veľkosti batchu sú preto potrebné dve H200 (282 GB) alebo štyri H100 (320 GB).

Stav, pamäť a región v EÚ

Agenti sú na rozdiel od klasických webových aplikácií stateful: konverzačná pamäť, plány úloh a história volaní nástrojov musia prežiť, aj keď sa pod reštartuje alebo nastane failover regiónu. Pre architektúru to znamená: stav session patrí do regionálneho Redisu alebo Cosmos DB s georeplikáciou, dlhodobá pamäť a vektorová databáza sa replikujú synchrónne alebo asynchrónne podľa požadovaného RPO. Vektorová databáza je pritom hlavnou výzvou z hľadiska objemu dát, pretože embeddingy a chunky tvoria najväčšie množstvo dát.

Pri téme región v EÚ a suverenita číha najdôležitejšia pasca: frankfurtský región amerického hyperscalera prináša rezidenciu dát (data residency), nie suverenitu odolnú voči CLOUD Actu, pretože prevádzkovateľ zostáva americkou právnickou osobou. Pre managed Kubernetes so skutočnou suverenitou prichádzajú do úvahy suverénne cloudy: Infomaniak (Ženeva/Zürich, plne pod švajčiarskou kontrolou, FADP plus GDPR) a Exoscale (Švajčiarsko, základ na CloudStacku s vlastnými orchestrátormi, managed K8s) ponúkajú spravovaný Kubernetes bez expozície voči hyperscalerom; Swisscom má suverénnu K8s službu postavenú na Kubermaticu; STACKIT (Schwarz Digits, s dátovým centrom v Rakúsku) a Open Telekom Cloud stavajú na platformách založených na OpenStacku s GPU inštanciami. Pre workloady bez prísnych požiadaviek na suverenitu zostáva managed Kubernetes od hyperscalerov (AKS/EKS/GKE) v regióne EÚ pragmatickou štandardnou voľbou. Tak to rieši aj referenčná architektúra pre lean scale-upy.

Secrets, prístup k nástrojom a observability

Agenti majú nezvyčajne veľký blast radius: kompromitovaný agent môže volať množstvo nástrojov. Preto ako osvedčený postup platí jeden service account na každú dvojicu agenta a nástroja namiesto zdieľaného účtu, just-in-time elevácia oprávnení pre citlivé operácie a audit traily, ktoré cez reťazec token exchange siahajú až k identite používateľa.

Konkrétne na Kubernetes:

• Workload Identity namiesto statických prístupových údajov: Azure Managed Identity, AWS IRSA (IAM Roles for Service Accounts v EKS), GCP Workload Identity Federation, pri suverénnych cloudoch service accounty v Keystone resp. K8s. Cieľ je rovnaký: žiadny kľúč v kóde, žiadny človek v ceste k prístupovým údajom.
• Základ pre secrets: HashiCorp Vault je najrozšírenejšia vrstva pre secrets a PKI v platformových stackoch v regióne DACH; v BFSI a vo verejnom sektore s HSM seal voči HSM od Utimaco (Cáchy) alebo Thales. Vzor External Secrets ich synchronizuje do K8s secrets bez toho, aby ich ukladal v repozitári.
• Kontrola egressu: Vzor zavedený v DACH BFSI je deny-by-default s explicitným allowlistom FQDN modelových API, logovaný na gatewayi. To zabraňuje neúmyselnej exfiltrácii dát a núti všetok modelový traffic cez AI gateway (LiteLLM, Portkey, Kong), kde sa uplatňujú rate limity, PII filtre a rozpočty.

Pre health a observability dáva Kubernetes základ: liveness a readiness probes pre každý pod zabezpečia, že traffic dostávajú len zdravé inferenčné pody. Pri dlhých časoch načítania modelu je to kritické (readiness probe smie prejsť do zeleného stavu až vtedy, keď je model načítaný). Nad tým beží vrstva tracingu cez OpenTelemetry s atribúciou nákladov s presnosťou na tokeny a s backendom s rezidenciou v EÚ, napríklad Langfuse (self-hosted).

Kedy Kubernetes a kedy nie

Tu je úprimné varovanie pred komplexnosťou. Kubernetes s vlastnou GPU inferenciou nie je víkendový projekt. Oplatí sa, ak platí aspoň jeden z týchto faktorov:

• Vysoká, stála záťaž: Podľa orientačného pravidla, ktoré koluje medzi platformovými tímami v regióne DACH, je vlastná inferencia od približne 8–12 H100 ekvivalentov trvalej záťaže lacnejšia na token než managed API, ale so 6–9 mesiacmi inžinierskej prípravy. Pod touto hranicou majú managed API nižšie TCO.
• Prísna latencia: Latenčné rozpočty pod 200–500 ms s viacerými kolami volaní nástrojov vyžadujú inferenciu umiestnenú v tej istej lokalite; transatlantické volania API (Frankfurt → US-East: približne 85–95 ms round trip) sú potom vylúčené.
• Zmluvná suverenita: Keď právne oddelenie neakceptuje expozíciu voči CLOUD Actu alebo je záväzný BSI C5 Type 2.

Naopak, managed API a serverless sú lepšou voľbou, keď je záťaž nárazová (nečinné GPU sú najhorší capex), keď je potrebný veľký výber modelov (samotný Microsoft Foundry pridal v roku 2025 DeepSeek R1, GPT-4.1, Mistral Large 3, Claude Opus 4.5, Llama 4) alebo keď jednoducho chýba platformový tím. Prevádzku vLLM, GPU scheduling a chybové stavy NCCL v režime 24x7 zvládne interne len máloktorá stredná firma v regióne DACH. Práve tento nedostatok, nie samotná technika, je najčastejším dôvodom, prečo projekty so self-hostingom zlyhávajú.

Konkrétny príklad: lean klaster pre B2B agenta

Typický stack scale-upu (podľa referenčnej architektúry „Lean Cloud“) vyzerá takto:

```text
Managed Kubernetes (AKS/EKS v regióne EÚ alebo suverénne Exoscale/Infomaniak)
├── Deployment: agent-orchestrator (LangGraph, 3 repliky, HPA 2-10, CPU uzly)
├── Deployment: mcp-tools-sap (mTLS, 1 service account na nástroj)
├── Deployment: ai-gateway-litellm (failover: Azure OpenAI EU -> Mistral La Plateforme)
├── StatefulSet: qdrant (3 repliky, PVC, vektorová databáza)
├── StatefulSet: redis (stav session, georeplikácia)
└── Worker-Deployment: doc-processor (KEDA, škáluje podľa hĺbky RabbitMQ queue)
Inferencia modelu: managed API (žiadny vlastný GPU uzol) -> cez gateway
```

Tu nebeží žiadna vlastná GPU. Inferenciu zabezpečuje managed API v regióne EÚ a gateway ju abstrahuje. Je to zámer: pri miernej záťaži je pay-per-token lacnejší a v prevádzke za týždne namiesto mesiacov. Až keď mesačné výdavky na API prekročia run-rate približne 10 H100 ekvivalentov v suverénnom cloude alebo keď nová požiadavka regulátora vyžaduje kontrolné opatrenie (control), ktoré managed API nedokáže preukázať, oplatí sa migrácia na vlastné GPU uzly s vLLM alebo NIM v tom istom klastri. Presne na to je Kubernetes ideálny: architektúra zostáva rovnaká, len inferenčný komponent sa presunie z „managed API za gatewayom“ na „GPU deployment v klastri“.

Pre agentúry a B2B rozhodovateľov

Kubernetes je správny základ pre agentové systémy, ktoré majú dlhodobo rásť, zostať suverénne v EÚ alebo dodržať prísnu latenciu. Začať by si však mal takmer vždy s managed API a managed Kubernetes, s jasne zdokumentovaným spúšťačom migrácie na vlastnú GPU inferenciu. Kto túto hranicu nedefinuje presne, postaví drahý GPU klaster buď príliš skoro, alebo príliš neskoro, keď sa účty za API už vymkli kontrole. Blck Alpaca sprevádza firmy a marketingové agentúry v regióne DACH presne pri tomto architektonickom rozhodnutí: od hodnotenia make-buy-rent pre každý komponent až po návrh suverénneho klastra pripraveného na observability. Ozvi sa nám, skôr než objednáš prvú GPU.