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

Nasadiť AI Agents na Kubernetes znamená prevádzkovať komponenty agentového systému – agent-service, tool- resp. MCP-server, vektorový store, inferenčný engine a message-queue – ako kontajnerizované workloady na K8s-clustri. Kubernetes poskytuje škálovanie, GPU-scheduling, prácu so stavom, správu secrets a observability pre produktívnu, EÚ-suverénnu prevádzku agentov. Je mocný, ale nie je samoúčelný – tento článok ukazuje architektúru, mechaniku škálovania a predovšetkým to, kedy sa námaha vôbec oplatí.

• Architektúra: Rozložte agentový systém na oddelené služby – orchestrátor, tool-/MCP-server, inferenčný engine, vektorový store, queue – a prevádzkujte každú ako samostatný workload.
• Škálovanie: Stateless agent-pody škálujú elasticky cez Horizontal Pod Autoscaler; GPU-inferenčné pody sú scheduleované na dedikované GPU-nody a z dôvodu nákladov zostávajú teplé.
• Rozhodnutie: Kubernetes sa oplatí pri vysokej trvalej záťaži alebo prísnych požiadavkách na suverenitu/latenciu – pod touto hranicou sú managed API a serverless rýchlejšie nasaditeľné a lacnejšie.

Kontajnerová architektúra agentového systému

Produktívny KI-agent nie je monolit, ale zoskupenie mikroslužieb. Toto rozdelenie nie je samoúčelné, ale vyplýva z rôznych profilov škálovania, stavu a bezpečnosti jednotlivých komponentov.

Agent-service (orchestrátor)

Agent-service je mozog: vykonáva orchestračnú logiku, rozhoduje o tool-volaniach a plánuje kroky. Typicky sa stavia na frameworku ako LangGraph, CrewAI alebo AutoGen, alebo na vendor-platforme ako PhariaAI (Heidelberg) resp. Azure AI Foundry Agents. Architektonicky rozhodujúce: táto služba musí zostať stateless, aby ju Kubernetes mohol voľne škálovať, reštartovať a distribuovať cez viaceré replicy. Všetok stav sa presúva do externých stores.

Tool- a MCP-server

Model Context Protocol (MCP) sa etabloval ako štandardné rozhranie, cez ktoré agenti oslovujú externé nástroje a dátové zdroje. V DACH enterprise prostredí bežia MCP-servery väčšinou ako In-VPC služby, co-located s agent-runtime a pripojené cez mTLS – to je default vzor pre integrácie do SAP, Salesforce, ServiceNow, M365 a interných databáz. Pre továrenské alebo pobočkové scenáre sú MCP-servery nasadené na edge, blízko k dátam, a centrálna orchestrácia ich volá cez dedikované linky (ExpressRoute, Direct Connect). Pri regulovaných workloadoch platí: dedikované MCP-servery na business-unit s oddelenými audit-trailmi namiesto multi-tenant servera.

Inferenčný engine

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

• vLLM (pôvod UC Berkeley) je de-facto štandard pre produktívny self-hosting – PagedAttention, najširšia hardvérová podpora, OpenAI-kompatibilné endpointy.
• SGLang (LMSYS) poskytuje podľa benchmarkov LMSYS približne o 29 percent vyšší throughput na modeloch 7B–8B na H100 a lepšiu tail-latenciu; ideálne pre multi-turn chat, RAG-náročné a štruktúrované workloady.
• NVIDIA NIM balí vLLM/TensorRT-LLM/SGLang do predpripravených kontajnerov a je najpragmatickejšia on-prem cesta v DACH strednom segmente – viaže však na licenciu NVIDIA AI Enterprise.
• TensorRT-LLM poskytuje špičkový throughput na NVIDIA hardvéri, je však NVIDIA-only a operačne náročný.

Dôležitá poznámka pre existujúce systémy: Hugging Face previedol TGI (Text Generation Inference) 11. decembra 2025 do maintenance režimu a nové nasadenia odkazuje na vLLM alebo SGLang. Kto dnes beží na TGI, nemusí panicky migrovať, no nové vývoje by už na ňom nemal stavať.

Vektorový store a message-queue

Vektorový store (Qdrant, Weaviate alebo pgvector) drží embeddingy pre RAG. Je klasickým kandidátom na StatefulSet s PersistentVolumes, pretože embeddingy plus originálne chunky dosahujú terabajtové veľkosti a potrebujú stabilnú identitu podu, ako aj perzistentné úložisko. Message-queue (napríklad RabbitMQ, NATS alebo Redis Streams) oddeľuje dlhotrvajúce, asynchrónne agentové úlohy – spracovanie dokumentov, batch-analýzy – od synchrónnej request-cesty a umožňuje worker-poole, ktoré škálujú nezávisle.

Mapovanie komponentov: čo patrí na ktorý K8s-resource

Nasledujúca tabuľka je hlavnou referenciou pre agentové nasadenie. Priraďuje každý komponent k vhodnému Kubernetes-resource a uvádza rozhodujúcu architektonickú poznámku.

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

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

Stateless os (CPU): Agent-service, MCP-server a AI-gateway sú lacné CPU-workloady. Škálujú elasticky cez Horizontal Pod Autoscaler (HPA) – pri záťažových špičkách pribúdajú replicy, pri nečinnosti sa odbúravajú. Pre queue-riadené workery sa hodí KEDA, ktorý škáluje podľa hĺbky queue namiesto len podľa CPU.

GPU os (inferencia): Tu platí iná logika. GPU-nody sa clustru sprístupnia cez NVIDIA Device-Plugin; pody si žiadajú GPU cez resource-limit nvidia.com/gpu. Pomocou node-selektorov, taints a tolerations sa inferenčné pody dostanú cielene na drahé GPU-nody, zatiaľ čo stateless-workloady zostávajú na CPU-nodoch. Zásadný rozdiel: GPU-kapacita zostáva väčšinou teplá namiesto elastickej, pretože nečinné GPU sú vôbec najdrahší capex. Skutočná elasticita cez cluster-autoscaler funguje len tam, kde cloud-provider dodáva GPU-nody dostatočne rýchlo – pri dedikovanej, alokáciou riadenej Blackwell-kapacite (B200/GB200) to neplatí.

Matematika GPU-pamäte určuje, koľko modelov sa zmestí na nod. Orientačné pravidlo pre váhy: parametre 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 (rádovo 10–40 GB v produktívnej prevádzke). Prakticky sa 70B pri BF16 zmestí pre nízku concurrency na jednu H200 (141 GB), no pre produktívne veľkosti batchu potrebuje typicky 2x H100 alebo tensor-paralelizmus cez viaceré GPU jedného nodu via NVLink.

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

Agenti sú na rozdiel od klasických web-appiek stateful – konverzačná pamäť, plány úloh a história tool-call musia prežiť, aj keď sa pod reštartuje alebo nastane region-failover. Architektonicky to znamená: session-state do regionálneho Redis alebo Cosmos DB s geo-replikáciou, dlhodobá pamäť a vektorový store replikované synchrónne alebo asynchrónne, podľa vyžadovaného RPO. Vektorový store je pritom výzvou bulk-dát, pretože embeddingy a chunky tvoria najväčšie objemy dát.

Pri téme EÚ-región a suverenita číha najdôležitejšia pasca: frankfurtský región US-hyperscalera poskytuje data-residency, nie suverenitu odolnú voči CLOUD Act – prevádzkovateľ zostáva US-právnickou osobou. Pre managed Kubernetes so skutočnou suverenitou prichádzajú do hry suverénne cloudy: Infomaniak (Ženeva/Zürich, plne švajčiarska kontrola, FADP plus GDPR) a Exoscale (Švajčiarsko, OpenStack, managed K8s) ponúkajú spravovaný Kubernetes bez hyperscaler-exposure; Swisscom má suverénny K8s-service založený na Kubermatic; STACKIT (Schwarz Digits, s dátovým centrom v Rakúsku) a Open Telekom Cloud stavajú na platformách založených na OpenStack s GPU-inštanciami. Pre workloady bez prísnej požiadavky na suverenitu zostáva managed Kubernetes hyperscalera (AKS/EKS/GKE) v EÚ-regióne pragmatickým defaultom – tak to rieši aj referenčná architektúra pre lean scale-upy.

Secrets, tool-prístup a observability

Agenti majú nezvyčajne veľký blast-radius: kompromitovaný agent môže volať mnoho tools. Preto platí ako best practice service-account na pár agent-tool namiesto zdieľaného účtu, just-in-time elevation pre citlivé operácie a audit-traily, ktoré cez token-exchange reťaz siahajú späť až k identite používateľa.

Konkrétne na Kubernetes:

• Workload Identity namiesto statických credentials: Azure Managed Identity, AWS IRSA (IAM Roles for Service Accounts v EKS), GCP Workload Identity Federation – pri suverénnych cloudoch Keystone- resp. K8s-service-accounty. Cieľ je identický: žiadny kľúč v kóde, žiadny človek v credential-ceste.
• Secrets-backbone: HashiCorp Vault je najrozšírenejšia secrets- a PKI-vrstva v DACH platformových stackoch; v BFSI a public sector s HSM-seal proti Utimaco- (Aachen) alebo Thales-HSM. External-Secrets pattern ich synchronizuje do K8s-secrets bez toho, aby ich ukladal v repo.
• Egress-kontrola: V DACH-BFSI etablovaný vzor je deny-by-default s explicitným allowlistom FQDN modelových API, logovaný na gateway. To zabraňuje neúmyselnej dátovej exfiltrácii a núti všetok modelový traffic cez AI-gateway (LiteLLM, Portkey, Kong), kde sú rate-limity, PII-filtre a budgety.

Pre health a observability poskytuje Kubernetes základ: liveness- a readiness-probes na pod zabezpečujú, že traffic dostávajú len zdravé inferenčné pody – čo je pri dlhých časoch načítania modelu kritické (readiness-probe smie zozelenať až vtedy, keď je model načítaný). Nad tým prichádza tracing-vrstva cez OpenTelemetry, s token-presnou atribúciou nákladov a EÚ-rezidentným backendom ako Langfuse (self-hosted).

Kedy Kubernetes – a kedy nie

Tu úprimné varovanie o komplexnosti. Kubernetes s vlastne hostovanou GPU-inferenciou nie je víkendový projekt. Oplatí sa, ak platí aspoň jeden z týchto driverov:

• Vysoká, stála záťaž: Orientačné pravidlo kolujúce v DACH platformových tímoch hovorí, že vlastne hostovaná inferencia sa od približne 8–12 H100-ekvivalentnej trvalej záťaže stáva na token lacnejšou než managed API – ale so 6–9 mesiacmi engineering predstihu. Pod touto hranicou dominujú TCO managed API.
• Prísna latencia: Latenčné budgety pod 200–500 ms s viacerými kolami tool-call vyžadujú co-located inferenciu; transatlantické API-volania (Frankfurt → US-East: ~80–120 ms one-way) sú potom diskvalifikované.
• Zmluvná suverenita: Keď právne oddelenie neakceptuje CLOUD Act-exposure alebo je záväzný BSI C5 Type 2.

Proti tomu hovoria managed API a serverless, keď je záťaž špičková (nečinné GPU sú najhorší capex), keď je potrebná vysoká modelová rozmanitosť (Azure Foundry sám doplnil v roku 2025 DeepSeek R1, GPT-4.1, Mistral Large 3, Claude Opus 4.5, Llama 4) alebo keď jednoducho nie je k dispozícii platformový tím. Prevádzku vLLM, GPU-scheduling a chybové scenáre NCCL v režime 24x7 ovláda in-house len málokto z DACH stredného segmentu – a práve tento nedostatok, nie technika samotná, je najčastejším dôvodom, prečo self-hosting projekty zlyhávajú.

Konkrétny príklad: lean-cluster pre B2B-agenta

Typický scale-up stack (vychádzajúci z referenčnej architektúry „Lean Cloud“) vyzerá takto:

```text
Managed Kubernetes (AKS/EKS v EÚ-regióne alebo Exoscale/Infomaniak suverénne)
├── Deployment: agent-orchestrator (LangGraph, 3 Replicas, HPA 2-10, CPU-nody)
├── Deployment: mcp-tools-sap (mTLS, 1 Service-Account na tool)
├── Deployment: ai-gateway-litellm (Failover: Azure OpenAI EU -> Mistral La Plateforme)
├── StatefulSet: qdrant (3 Replicas, PVC, vektorový store)
├── StatefulSet: redis (Session-State, geo-replikácia)
└── Worker-Deployment: doc-processor (KEDA, škáluje na hĺbku RabbitMQ-queue)
Inferencia modelu: Managed API (žiadny vlastný GPU-nod) -> cez gateway
```

Tu nebeží žiadne vlastné GPU – inferencia leží pri managed API v EÚ-geo, abstrahovaná cez gateway. To je zámerné: pri skromnej záťaži je pay-per-token lacnejší a nasaditeľný v týždňoch namiesto mesiacov. Až keď mesačný API-spend prekročí run-rate približne 10 H100-ekvivalentov v suverénnom cloude – alebo nová regulátorská požiadavka vyžaduje control, ktorý managed API nedokáže preukázať – oplatí sa migrácia na vlastné GPU-nody s vLLM alebo NIM na tom istom clustri. Práve na to je Kubernetes ideálny: architektúra zostáva rovnaká, len inferenčný komponent sa presúva z „managed API za gatewayom“ na „GPU-deployment v clustri“.

Pre agentúry a B2B-rozhodovateľov

Kubernetes je správny základ pre agentové systémy, ktoré majú dlhodobo rásť, zostať EÚ-suverénne alebo dodržiavať prísnu latenciu – ale vstup by mal takmer vždy prebiehať cez managed API a managed Kubernetes, s jasne zdokumentovaným migračným triggerom pre prechod na vlastnú GPU-inferenciu. Kto túto hranicu nedefinuje čisto, postaví buď príliš skoro drahý GPU-cluster, alebo príliš neskoro, keď sa API-účet už vymyká kontrole. Blck Alpaca sprevádza DACH-podniky a marketingové agentúry presne pri tomto architektonickom rozhodnutí – od make-buy-rent hodnotenia na komponent až po suverénny, observability-schopný cluster-design. Ozvite sa nám, skôr než sa objedná prvá GPU.