Pilastro 4 · Infrastruttura
Progettiamo, deployamo e manuteniamo cluster Kubernetes pronti a ospitare carichi IA — model serving, vector database, pipeline di data processing, RAG distribuiti, agenti orchestrati. L'esperienza in questo pilastro è maturata su ambienti enterprise e su progetti per la pubblica amministrazione italiana (sotto NDA), con vincoli reali di sicurezza, audit, continuità di servizio e compliance normativa.
L'infrastruttura non è un dettaglio implementativo. È il limite operativo di quello che puoi fare con l'IA.
Cosa progettiamo
Un cluster Kubernetes che ospita carichi IA ha requisiti molto diversi da uno generico. GPU scheduling, vector storage, observability LLM-specifica, isolation tra tenant. Disegnamo per queste esigenze fin dal primo giorno.
Topologia nodi (CPU pool + GPU pool), networking, ingress, storage tiered, backup. Scelta tra distribuzione managed (EKS, GKE, AKS), self-managed (kubeadm, k3s, RKE2) o appliance (microk8s, Talos). La scelta segue i vincoli reali, non la moda.
GPU sharing tra carichi, time-slicing quando ha senso, dedicato quando è critico. Integrazione con vLLM, Ollama, Triton Inference Server. Autoscaling reattivo al carico, con limiti di costo configurabili.
Storage class per workload diversi (modelli pesanti, vector index in memoria, log strutturati). Deploy di Qdrant, Weaviate, pgvector come servizi cluster-native con backup, replicazione, monitoring.
NetworkPolicy strict-by-default, PodSecurityStandard restricted, secret management con sealed-secrets o External Secrets Operator, audit logging, RBAC granulare. Hardening secondo CIS Kubernetes Benchmark.
Esperienza
Una parte significativa della nostra esperienza Kubernetes proviene da progetti per enti della pubblica amministrazione italiana, con vincoli operativi reali — non scenari di laboratorio.
Significa che il cluster deve passare l'audit, non solo essere tecnicamente corretto. Significa che il SOC del cliente deve poter leggere i log di sicurezza nei suoi sistemi, non nei nostri. Significa che ogni componente deve avere una giustificazione documentata di scelta e di gestione delle vulnerabilità.
Significa anche che le persone che mantengono il cluster devono saper rispondere a una commissione, non solo a Stack Overflow. Per ovvi motivi non possiamo nominare i progetti specifici, ma le referenze sono disponibili sotto NDA in fase commerciale avanzata.
Quando un cluster ospita servizi al cittadino o sistemi interni di una struttura pubblica, downtime non pianificato significa danno reale. Disegnamo per HA non come buzzword: ridondanza per zona, RPO/RTO documentati, runbook testati, on-call procedures realistici.
Cosa includiamo
L'infrastruttura non finisce il giorno del go-live. Il valore vero è nella manutenibilità a tre anni di distanza, quando le persone iniziali del progetto non ci sono più.
Provisioning con IaC (Terraform, Pulumi, Ansible), configurazione del control plane, addon essenziali (CNI, ingress, metrics, monitoring), prime applicazioni IA in deploy.
Aggiornamenti del control plane in finestre concordate, patching dei worker, upgrade controlled di addon e applicazioni, monitoraggio attivo con alert verso il cliente, post-mortem documentati per ogni incidente.
Quando il cliente ha team interno o vuole prendere il controllo operativo, costruiamo il percorso di handover: runbook completi, shadowing dei nostri operatori, transizione documentata. Il cliente non resta dipendente da noi se non vuole esserlo.
Una call iniziale per capire se siamo le persone giuste per il tuo progetto.
