Plataforma on lo0 — Blog Técnico

Siete fases de despliegue greenfield de una plataforma LLM on-premise: del hardware en la sala al primer token productivo

Sun, 31 May 2026 08:00:00 +0200

TL;DR

Los dos posts anteriores de esta trilogía arquitectónica fijaron las piezas: las siete capas del stack de inferencia LLM describen los componentes encima del cluster, y los cinco niveles de madurez de la plataforma describen los estratos por debajo. Este post fija el cuándo: en qué orden se despliega cada cosa cuando se parte de cero —hardware comprado, racks instalados, cableado físico hecho— y se quiere llegar a un cluster sirviendo el primer token productivo a un cliente. Siete fases nominales F0 a F6 sin compromisos de calendario, organizadas por dependencias técnicas (no se entra en F3 sin gate de F2) y con un camino crítico identificable. F0 inventario hardware y conectividad eléctrica/red. F1 OS bare metal + drivers + container runtime. F2 cluster Kubernetes con CNI y storage Ceph operativos. F3 GitOps y observabilidad de infraestructura. F4 identidad, TLS, secretos y políticas. F5 plataforma GPU con observabilidad LLM-aware. F6 stack LLM operativo y abierto a tráfico productivo. Para cada fase: qué se monta, qué tiene que estar listo antes (dependencias entre fases), gate que valida el cierre, y la trampa típica que retrasa el camino crítico. La tesis: una plataforma LLM on-premise se hunde mucho más a menudo por secuenciar mal que por elegir mal. Las herramientas están todas inventadas; el orden es lo único que cada equipo redescubre.

Estás aquí: las siete fases y sus dependencias

Las fases no se ejecutan en serie pura. F2 y F3 pueden empezarse a la vez para acelerar (instalar Kubernetes y preparar el repo GitOps en paralelo). F4 puede solaparse con la parte final de F3. F5 espera a que F4 cierre porque los pods GPU exigen NetworkPolicy y RBAC desde el primer día. F6 es un único paso atómico: el cluster entra en producción o no.

Las flechas rojas son el camino crítico: el cuello de botella secuencial que ningún paralelismo puede acortar. Las flechas grises son dependencias que admiten solape parcial. Reconocer dónde solapar y dónde no es la diferencia entre un despliegue de tres meses y uno de seis para el mismo perímetro.

La analogía: la expedición a una cumbre de ocho mil

Una expedición a una cumbre alpina alta no es un trekking largo. Es una serie de campamentos que se montan en orden, cada uno con su altura, su función y su gate de validación: si no se aclimata bien en el campo base, no se puede subir al C1 sin riesgo; si el C2 no tiene su cocina y su radio en marcha, no se puede mandar gente arriba; si el ataque a cumbre se intenta sin los porteadores en los campamentos altos, no hay descenso seguro.

El despliegue greenfield de una plataforma LLM funciona idéntico. F0 es la llegada del material al campamento base — cajas, sponsors, permisos, primera revisión. F1 es montar el campo base operativo: cocina, tiendas, generador. F2 es la subida al C1: ya hay altitud real (cluster k8s en marcha) y se respira distinto. F3 es C2: añade comunicaciones, planificación y aclimatación operativa. F4 es C3, la última noche antes del ataque: equipo cordado, oxígeno listo, todos los protocolos verificados. F5 es el día del ataque a cumbre — esfuerzo intenso, márgenes finos. F6 es la cumbre y el inicio del descenso seguro: a partir de aquí la expedición está en operación día a día, ya no en construcción.

La analogía aguanta dos lecciones útiles: no se salta un campo (subir directo del campo base a la cumbre mata al equipo), y los gates son técnicos, no anímicos (si el barómetro pone tormenta, no se sale, aunque haya entusiasmo). El equipo de plataforma que sigue esas dos reglas llega a la cumbre. El que las negocia, no.

F0 — Hardware en la sala: el campamento base

Lo que se monta en esta fase. Inventario del hardware recibido (servidores, switches, PDUs, BMC), racks montados, cableado eléctrico y de datos terminado, etiquetado físico de cada equipo (rack/U/función), conectividad a la red corporativa, IPs de gestión asignadas, BMC accesible vía VPN con MFA, primer ping de cada nodo desde el bastion.

Dependencias. Cero técnicas — esta es la fase previa al software. Sí dependencias de procurement (servidores comprados, switches comprados), de obra civil (sala con climatización suficiente, suelo técnico) y administrativas (acceso al CPD para los técnicos).

Gate de validación que cierra F0.

Cada nodo aparece en el inventario con (hostname, MAC, IP gestión, IP datos, rack, U, función, owner).
BMC de cada nodo responde a ipmitool power status y a la UI HTTPS desde la VPN de gestión.
El switch de top-of-rack tiene su configuración versionada en git (incluso si todavía no hay GitOps de cluster, los configs de switch sí).
Un comando for h in $(cat hosts); do ping -c1 -W1 $h.mgmt; done devuelve 100% de éxito.

Trampa típica. Cablear “como salga” sin etiquetado físico ni esquema. Cuando llega F4 y hay que troubleshootear una NetworkPolicy, no saber qué interfaz física lleva qué VLAN duplica el tiempo de diagnóstico de cada incidente para siempre.

Por qué F0 no se solapa con F1. Hasta que cada servidor tiene IP de gestión y BMC vivo, no se puede automatizar el bootstrap del OS. Toda hora invertida en F0 ahorra horas en cada fase posterior — es la fase con mejor ROI del proyecto y la única que no admite atajos.

F1 — Bare metal: el campamento base operativo

Lo que se monta. Imagen del sistema operativo (Debian estable o Ubuntu LTS) provisionada vía PXE o cloud-init con el cloud-config versionado en git. Cada nodo tiene: hostname coherente, particiones LVM, kernel ≥ 6.6, container runtime containerd, drivers NVIDIA para los nodos GPU, chrony sincronizando contra servidores propios, SSH key del operador como única vía de acceso, nvidia-smi pasando smoke test en los nodos GPU.

Dependencias. F0 cerrada. Necesita la red de gestión funcionando para que el PXE responda y para que el bastion alcance cada nodo.

Gate de validación que cierra F1.

ansible -i inventory all -m ping devuelve 100% de éxito (o equivalente con Salt / Pulumi / etc).
Cada nodo GPU pasa nvidia-smi mostrando las GPUs esperadas con driver consistente entre nodos.
Reloj de cada nodo desviado < 50 ms del NTP de referencia.
Reinicio físico de un nodo lo deja exactamente en el mismo estado tras boot (idempotencia).

Trampa típica. Drivers NVIDIA instalados manualmente con apt install o con el script .run de NVIDIA. Funciona el día uno y se rompe el día de la primera actualización de kernel. La regla operativa que ya quedó establecida en el post de los cinco niveles: los drivers acaban siendo gestionados por el GPU Operator en F5; lo que se haga ahora es solo para que nvidia-smi pase el smoke test, no para producción.

Solape posible. F1 puede empezar para algunos nodos mientras todavía se finaliza F0 en otros (greenfield real raramente entrega todos los servidores el mismo día). El gate de F1 es por cluster, no por nodo individual.

F2 — Cluster Kubernetes operativo

Lo que se monta. RKE2 instalado con tres nodos de control plane HA, joining de todos los workers (CPU y GPU), Cilium como CNI con kubeProxyReplacement habilitado y BGP control plane apuntando a los switches ToR del F0, Rook-Ceph desplegado en los nodos de storage para cubrir block (RBD), filesystem (CephFS) y object (RGW S3-compatible), kubectl get nodes devolviendo todos los nodos Ready, primer pod de prueba con PVC montando y datos persistiendo tras restart del pod.

Dependencias. F1 cerrada (drivers + container runtime). Switches con BGP configurado (lo cerrado en F0). Discos NVMe particionados o disponibles raw para Ceph OSDs.

Gate de validación que cierra F2.

kubectl get nodes -o wide muestra todos los nodos Ready con la versión esperada de Kubernetes.
Un Deployment con replicas=3 y antiAffinity por nodo arranca y los pods caen en nodos distintos.
Una PVC RWO (RBD) crea un volumen, el pod escribe datos, el pod se borra, otro pod la monta y lee los datos.
Una PVC RWX (CephFS) hace lo mismo con dos pods escribiendo simultáneamente.
Un bucket RGW vía s3cmd o mc acepta put y get con TLS.
Hubble (lado lectura del CNI) muestra flow logs entre dos pods de namespaces distintos.
Test de chaos: drain de un nodo worker no GPU; las cargas se reschedulean automáticamente.

Trampa típica. Empezar a kubectl apply cargas reales en F2 sin GitOps. El backlog de cosas-aplicadas-a-mano crece más rápido que la capacidad de migrarlo a git después. La regla: en F2 sólo se aplican los prerrequisitos del cluster (CNI, CSI, storage class por defecto). Cualquier carga de aplicación espera a F3.

Solape posible. F2 ↔ F3. Mientras se monta el cluster, se prepara en paralelo el repo GitOps (estructura de directorios, primeras Helm releases). Cuando F2 cierra, Flux se enchufa al repo y todo lo que iba a ser kubectl apply ya está como manifest reconciliado.

F3 — GitOps y observabilidad de infraestructura

Lo que se monta. Forgejo desplegado primero (es prerrequisito de todo lo que viene). Repo gitops-infra con la estructura inicial (apps/, infrastructure/, tenants/, clusters/). Flux instalado y reconciliando ese repo. Las cargas de prerequisito que se aplicaron a mano en F2 se mueven al repo y se reconcilian (deja de haber kubectl apply operativo). VictoriaMetrics + vmagent scrapeando métricas. Grafana con dashboards iniciales (USE/RED + cluster + Ceph + Cilium). Loki recibiendo logs vía vector/fluent-bit. Alertmanager + Keep enrutando alertas a un canal de chat. Backups Barman Cloud para Postgres (futuro CNPG) y snapshots Ceph programados.

Dependencias. F2 cerrada. Bucket RGW para almacenar backups (lo cubre Ceph del F2).

Gate de validación que cierra F3.

Cambio aplicado al repo se refleja en el cluster en < 5 minutos sin intervención manual.
Un cambio aplicado con kubectl edit directamente al cluster es detectado por Flux y revertido (drift detection vinculante, no sólo observacional).
Grafana muestra dashboards de cluster, Ceph, Cilium y nodos GPU (DCGM no llega hasta F5, pero las métricas básicas del nodo sí).
Un alert de prueba enviado a Alertmanager llega al canal de chat en < 1 minuto.
Restore de un backup Postgres en un cluster temporal devuelve datos coherentes (la prueba define el RPO real).

Trampa típica. Tener Helm charts en git pero seguir aplicando con helm install desde la terminal. Eso es nivel 1 con disfraz de nivel 2. F3 sólo se cierra cuando Flux es la única autoridad que aplica cambios y los humanos editan repo, no cluster.

Solape posible. F3 ↔ F4. Mientras se cierra F3, se puede preparar el manifest de Defguard y cert-manager en el repo. Cuando se reconcilien tienen donde aterrizar.

F4 — Identidad, certificados, secretos, políticas

Lo que se monta. Defguard desplegado con su Postgres dedicado (CNPG). Realm inicial con los operadores de plataforma enrolados con MFA y WireGuard. OIDC integrado en kube-apiserver (--oidc-issuer-url, --oidc-client-id, --oidc-username-claim), en Forgejo, en Grafana, en Alertmanager — un solo SSO. cert-manager instalado con CA interna emitiendo certs internos para mTLS y con Let’s Encrypt ACME para certs de borde. SOPS configurado con KMS (puede ser un HSM físico, una clave age en un cofre, o un Vault externo) y External Secrets Operator sincronizando secretos al cluster. Kyverno desplegado con políticas iniciales en modo audit durante una semana, después promovidas a enforce. NetworkPolicy default-deny aplicada a cada namespace existente. Tetragon habilitado para runtime security. Audit log de kube-apiserver enviado a Loki con retención larga.

Dependencias. F3 cerrada (Flux aplica los manifests, VM/Loki ingieren métricas y logs).

Gate de validación que cierra F4.

kubectl con kubeconfig admin compartido deja de funcionar; cada operador usa su propio token OIDC con MFA.
Un secret en data: plano en un commit es rechazado por el pre-commit hook (o por Kyverno admission).
Un pod sin securityContext.runAsNonRoot=true es rechazado por Kyverno en admission.
Una NetworkPolicy intencionalmente errónea (allow-all) en un namespace de tenant es rechazada.
Un audit del último día devuelve la lista completa de actores y cambios (huella regulatoria mínima).
Pen-test interno básico: un atacante con kubeconfig falsificado falla en MFA y queda registrado.

Trampa típica. Kyverno en modo audit permanente porque “no queremos romper cargas en producción”. F4 se cierra cuando las políticas están en enforce. Hasta entonces, sigues en F3 con cara de F4.

Por qué F4 no se solapa con F5. F5 introduce pods GPU que mueven mucha VRAM y mucho cómputo. Sin NetworkPolicy default-deny, sin RBAC OIDC, sin Kyverno bloqueando configuraciones inseguras, los pods GPU son la superficie de ataque más jugosa del cluster. Cualquier compromiso en F5 sin F4 cerrada es un acceso casi-total al hardware caro.

F5 — Plataforma GPU con observabilidad LLM-aware

Lo que se monta. NVIDIA GPU Operator vía Flux con la versión de driver decidida en F1 (ahora ya no se manipula a mano). DCGM Exporter expone métricas GPU a VictoriaMetrics. MIG manager configurado para los nodos donde tenga sentido (por ejemplo, en un cluster 4×H100 SXM: dos GPUs con passthrough completo para el LLM general TP=4, dos GPUs particionadas en 2×3g.40gb cada una para LLMs pequeños y embeddings). Topology Manager con política single-numa-node. KEDA con Prometheus scaler instalado y un ScaledObject de ejemplo apuntando a una métrica vLLM (vllm:num_requests_running). OpenTelemetry Collector con receivers OTLP, processors attributes (enriquecen spans con tenant_id, priority_tier), exporters a Langfuse y a Tempo. LeaderWorkerSet API habilitada para topologías tensor parallel. OME (Operator Model Engine) o vLLM Production Stack desplegado como controller — todavía sin modelos cargados.

Dependencias. F4 cerrada (los pods GPU heredan NetworkPolicy default-deny, RBAC OIDC y políticas Kyverno).

Gate de validación que cierra F5.

Un pod de prueba pidiendo nvidia.com/gpu: 1 se programa en el nodo correcto y nvidia-smi desde dentro del contenedor ve la GPU correcta (entera o un slice MIG).
DCGM Exporter expone métricas en Grafana (utilization, VRAM, temperatura, NVLink bandwidth) para cada GPU.
Un Deployment de vLLM de prueba arranca con un modelo pequeño (por ejemplo, un 7B FP16) cargado desde Ceph RGW.
Un span OpenTelemetry generado por ese vLLM llega a Langfuse con atributos gen_ai.* correctos.
KEDA escala el Deployment de prueba de 1 a N réplicas bajo carga sintética y vuelve a 1 cuando cesa.
Un upgrade del GPU Operator a una nueva versión drena y reprograma los pods GPU sin pérdida de servicio.

Trampa típica. Cargar el modelo grande “para probar” antes de que DCGM y OTel estén verdes. Cuando algo falle, no habrá métricas que distingan entre OOM, throttling térmico, mismatch de driver o problema de red — se diagnostica a ciegas. La regla: modelo pequeño primero, golden path verde, después modelo grande.

Solape posible. Ninguno con F6. F6 es atómico.

F6 — Stack LLM en producción

Lo que se monta. Las siete capas del stack de inferencia descritas en el post correspondiente, desplegadas en este orden:

Vector store + datos relacionales (Qdrant, PostgreSQL CNPG, Ceph RGW para pesos y adapters, CephFS para datasets). Algunos componentes ya existían de F3 como datos; aquí se especializan para RAG con sus colecciones y schemas iniciales.
Embeddings + reranker (Infinity con multilingual-e5-large, TEI con bge-reranker-v2-m3). Es la capa que debe estar verde antes de cualquier modelo grande, porque el RAG depende de ella.
Inferencia LLM (vLLM Production Stack con el LLM general y el LLM código). Carga modelos desde Ceph RGW. Multi-LoRA pool inicial vacío.
Gateway (Envoy AI Gateway) con OAuth Defguard, routing por body.model, rate-limit por tenant. Este es el punto que abre tráfico al exterior.
Observabilidad LLM-aware (Langfuse enchufado al OTel del F5).
Control plane GitOps y dependency tracking ya estaban activos desde F3 y F4 respectivamente; aquí simplemente se les añade el catálogo de los nuevos servicios LLM.

Dependencias. Todas las anteriores cerradas.

Gate de validación que cierra F6.

Curl al endpoint público con bearer token Defguard recibe respuesta de chat completion en castellano técnico correcta, con trace_id propagado.
La traza aparece en Langfuse con atributos gen_ai.* completos, latencia desglosada y tenant_id propio.
Un canary 5% de tráfico al nuevo modelo durante 24 h no degrada métricas de calidad ni de latencia.
Un golpe de tráfico controlado dispara KEDA, las réplicas escalan, la latencia P95 se mantiene dentro de presupuesto.
Un fallo intencional de un pod vLLM no afecta a la disponibilidad del endpoint (réplicas + reschedule).
El operador interno demuestra el camino completo de revocación de acceso a un tenant en < 5 minutos (Defguard → Kyverno → cierre de NetworkPolicy).

Trampa típica. Abrir tráfico de cliente real antes de tener el runbook de incidentes firmado, el SLO negociado y el plan de continuidad probado. F6 técnicamente está cerrada; operativamente, la plataforma sigue siendo experimento hasta que el primer postmortem real demuestre que el equipo sabe responder.

Las matemáticas que importan: peso relativo del esfuerzo por fase

Sin comprometernos con semanas calendario, sí podemos cuantificar el peso relativo del esfuerzo de ingeniería por fase en un greenfield típico. La curva no es uniforme:

$$ \text{esfuerzo}_{F_i} \approx \text{base}_i \cdot (1 + \epsilon_i) $$

donde $\text{base}_i$ es el esfuerzo nominal y $\epsilon_i$ es el factor de sorpresas (cabling errado, drivers incompatibles, certificados mal emitidos, conflictos de versiones). La tabla siguiente da el peso relativo nominal y el factor típico de sorpresa observado:

Fase	Peso nominal	Factor sorpresa típico ε	Peso efectivo medio
F0 — Hardware	8 %	0.5 (1× a 2×)	12 %
F1 — Bare metal	6 %	0.3	8 %
F2 — Cluster k8s	12 %	0.4	17 %
F3 — GitOps + obs	14 %	0.5	21 %
F4 — Identidad + políticas	18 %	0.7	31 %
F5 — GPU plane	10 %	0.4	14 %
F6 — Stack LLM live	8 %	0.3	10 %
Buffer / integración	24 %	—	—

Dos observaciones operativas. F4 concentra más sorpresas que ninguna otra (federación OIDC entre cuatro o cinco apps con configuraciones distintas, políticas Kyverno que tumban cargas legítimas, secretos rotos por encriptación mal probada). F0 tiene un coeficiente de sorpresa alto en relación a su tamaño porque cualquier error de cableado o etiquetado se descubre tarde y se paga caro. Las dos consecuencias prácticas: planificar F4 con margen generoso y no escatimar tiempo en F0 porque cada hora ahorrada ahí cuesta cinco después.

Camino crítico y holguras. El camino crítico es lineal F0 → F1 → F2 → F3 → F4 → F5 → F6. Las únicas holguras reales son los solapes ya identificados:

F2 ↔ F3 (holgura ~30 %): preparar repo y dashboards iniciales mientras se monta cluster.
F3 ↔ F4 (holgura ~20 %): manifests de identidad listos al cerrar F3, aplicación inmediata.
Dentro de F4: políticas en modo audit corriendo en paralelo con setup de Defguard.

Nada acorta el camino crítico más de un ~15 % del total. Quien promete un greenfield productivo en la mitad del tiempo razonable está vendiendo otra cosa: probablemente saltarse F4 o cargar F6 con F5 verde-pero-no-validado.

Diagrama final: el cronograma de despliegue completo

El cronograma no es decorativo: cada fila define lo que se monta en su fase y el gate que la cierra. Una fase no se da por terminada hasta que su gate está verde. Una fase con gate amarillo arrastra todas las posteriores; intentar saltar a la siguiente con un gate parcialmente cumplido es lo que produce, varias semanas después, el incidente que obliga a “volver a F4 con producción rodando” — la situación más cara de toda la matriz de costes del post de los cinco niveles.

Errores típicos de planificación

Patrones que retrasan o hunden el despliegue greenfield, independientemente de las herramientas elegidas:

1. Comprar el LLM antes que el cluster. Empezar el proyecto por “qué modelo vamos a servir” en vez de por “qué plataforma puede sostener cualquier modelo razonable”. El modelo es un parámetro intercambiable; la plataforma no.

2. Subestimar F0. “Eso lo hace el equipo de redes”. Sí, pero el resultado de F0 lo consumen todas las fases posteriores. Si el equipo de redes entrega tarde, el proyecto entero llega tarde — y nadie lo había marcado como camino crítico.

3. Solapar F4 con F5 “para ganar tiempo”. Es la única dependencia donde no hay holgura. Si se intenta solapar, F5 acaba operando con políticas en audit permanente (no estás en F4) o sin OIDC integrado (operadores con kubeconfig compartido tocando GPU). Ambos antipatrones se quedan en producción.

4. Saltar el smoke test del modelo pequeño en F5. “Vamos a por el 70B directamente”. Cuando algo falle (y algo fallará), no habrá baseline contra el que diagnosticar.

5. Tratar F6 como “encender vLLM”. F6 incluye gateway, observabilidad LLM-aware, runbook, SLO, plan de continuidad. Encender vLLM es cinco minutos; cerrar F6 es semanas de validación y firma.

6. No definir gates por escrito. Si los gates no están escritos, son negociables a posteriori. “Esto ya cuenta como F4” es la frase que precede a los seis meses siguientes de retrofit.

7. Asignar la fase a un único responsable. Cada fase necesita al menos dos personas que la entiendan. La rotación de personal en proyectos largos destruye el conocimiento; los gates por escrito + revisión cruzada lo preservan.

8. Olvidar el camino de descenso. El post se centra en subir. La operación día a día (descenso, en la analogía) es otra historia que también merece planificación — runbooks, on-call, capacidad de upgrade, plan de fin de vida. Los equipos que sólo planifican la subida llegan a la cumbre y se quedan ahí sin oxígeno.

Aplicado a hardware on-premise típico: 4×H100 SXM

Sobre el cluster genérico de referencia (4×H100 SXM 80 GB, NVLink, 640 GB RAM por nodo GPU, 3 nodos control plane, 3-5 nodos worker CPU, 2 nodos worker GPU), el reparto temporal del trabajo se distribuye así:

F0 (hardware)
└─ 8 servidores físicos racks + switches + BMC + IPs gestión
 ├─ 3 nodos cp-01..03 — control plane (sin GPU)
 ├─ 3 nodos worker-cpu-01..03 — CPU plane (Forgejo, Ceph, observabilidad)
 └─ 2 nodos worker-gpu-01..02 — GPU plane (4×H100 SXM cada uno)

F1 (bare metal)
└─ OS + drivers + containerd en los 8 nodos por igual
 (los drivers NVIDIA solo en los 2 nodos GPU, smoke `nvidia-smi`)

F2 (cluster k8s)
└─ RKE2 control plane en cp-01..03 (HA con etcd embebido)
 workers joining: 3 CPU + 2 GPU
 Ceph OSDs en los 3 nodos worker CPU
 pools por defecto: RBD-replicated-3, CephFS-replicated-3, RGW

F3 (GitOps + obs)
└─ Forgejo + Flux + VM/Grafana/Loki + Keep en CPU plane
 primer repo `gitops-infra` reconcilia lo de F2

F4 (identidad)
└─ Defguard en CPU plane (StatefulSet con Postgres CNPG)
 OIDC en kube-apiserver, Forgejo, Grafana, Alertmanager
 Kyverno como Deployment en control plane

F5 (GPU plane)
└─ NVIDIA GPU Operator targetea workers GPU
 MIG manager: 1ª GPU MIG 7g.80gb (= passthrough), 2ª 2×3g.40gb
 OTel Collector como DaemonSet en GPU plane + CPU plane
 primer vLLM con modelo 7B FP16 verde

F6 (stack LLM)
└─ Las 7 capas se reconcilian vía Flux desde un segundo repo `gitops-llm`
 primer endpoint público con OAuth Defguard
 primer cliente productivo enrolado bajo SLA

La distribución física del cluster aprovecha el aislamiento entre planos definido en F0: el plano de control no toca GPU, el plano CPU concentra estado relevante (Forgejo, Ceph, Postgres CNPG, Langfuse, Defguard) y el plano GPU se especializa al máximo. Esa separación, decidida en F0 antes de instalar el primer servidor, condiciona el éxito del resto de fases — es otro recordatorio de por qué F0 importa más de lo que parece.

Lo que no hemos cubierto (próximos posts)

Este post recorre el camino de subida a la cumbre. Quedan piezas que merecen su propio artículo:

El descenso seguro: operación día a día, runbooks por componente, on-call, capacity planning continuo, ciclo de upgrades del cluster sin downtime.
Multi-site (segunda cumbre): cómo se federan dos clusters con Cilium Cluster Mesh y qué fases extra introduce. F3.5 (Cluster Mesh) y F4.5 (replicación cross-site) son las fases que faltan.
El camino brownfield: lo que cambia cuando ya hay un cluster con cargas. Las fases siguen siendo las mismas, pero los gates se aplican retroactivamente y cada paso requiere planning de migración.
El coste calendario real: rangos típicos en semanas para un equipo de plataforma de 2-3 personas, separado por fase, con bandas de incertidumbre.
El handoff a operación: cómo se entrega la plataforma del equipo de despliegue al equipo de operación, qué documentos firman, qué se hereda y qué se renegocia.

Ver también

Anatomía de un stack de inferencia LLM on-premise — las siete capas que se montan en F6. Los componentes, no el cronograma.
Cinco niveles de madurez de la plataforma debajo del LLM — los niveles correspondientes a las fases F1→F5. Los estratos, no la secuencia.
El catálogo OSS para LLMOps en seis etapas — fichas individuales de las piezas citadas aquí.
Tracing LLM con OpenTelemetry GenAI — el OTel del F5 con detalle de las semantic conventions gen_ai.*.

Referencias

RKE2 Documentation — docs.rke2.io
Cilium documentation — docs.cilium.io
Rook documentation — rook.io/docs
Flux GitOps toolkit — fluxcd.io
Forgejo — forgejo.org
cert-manager — cert-manager.io
External Secrets Operator — external-secrets.io
Kyverno — kyverno.io
NVIDIA GPU Operator — docs.nvidia.com/datacenter/cloud-native/gpu-operator
DCGM Exporter — github.com/NVIDIA/dcgm-exporter
KEDA — keda.sh
LeaderWorkerSet API — github.com/kubernetes-sigs/lws
OpenTelemetry Semantic Conventions for GenAI — opentelemetry.io/docs/specs/semconv/gen-ai

Cinco niveles de madurez de la plataforma debajo del LLM: del servidor con Linux al cluster listo para vLLM

Sun, 31 May 2026 07:00:00 +0200

TL;DR

El post de las siete capas del stack de inferencia LLM daba por supuestas muchas piezas: un cluster Kubernetes operativo, GitOps reconciliando, identidades resueltas, GPUs visibles para el scheduler, observabilidad capaz de transportar gen_ai.*. Antes de que vLLM tenga sentido, hay que llegar a ese punto de partida, y se llega por niveles. Este post define cinco niveles de madurez de la plataforma que vive debajo del LLM, desde un servidor bare metal con Linux instalado (nivel 0) hasta un cluster listo para correr la capa de inferencia (nivel 4) y el handoff al post anterior (nivel 5). Cada nivel desbloquea una capacidad concreta —ejecutar contenedores con reproducibilidad, reconstruir el cluster desde git, autenticar humanos vía OIDC, programar GPUs con MIG y métricas DCGM, demostrar compliance sin intervención manual— y cada uno tiene un test de validación que decide si estás de verdad ahí o solo te lo cuentas. Para cada nivel: qué piezas OSS lo cubren en 2026 (Cilium, RKE2, Flux, cert-manager, Defguard, NVIDIA GPU Operator, KEDA, Trivy, Kyverno…), el orden de despliegue dentro del nivel, las decisiones que cuesta caro saltarse, y los antipatrones que te bajan de nivel cuando creías estar arriba. La tesis: subir de nivel cuesta poco esfuerzo si lo haces a tiempo, y mucho refactor si pretendes saltártelo. La inferencia LLM exige al menos nivel 4; quien intenta servir LLMs desde un nivel 1 o 2 acaba pagando con incidentes nocturnos lo que se ahorró en plataforma.

Estás aquí: los cinco niveles de un vistazo

Antes del detalle, la escalera. Cada peldaño añade una capacidad ausente en el anterior. El test del nivel es la pregunta cuya respuesta honesta dice si ya estás en él.

Los niveles no son intercambiables. Un cluster en nivel 2 no puede correr LLMs en producción con garantías: técnicamente carga el pod de vLLM, pero al primer incidente nocturno se descubre que no hay TLS, ni identidades, ni alerting, ni métricas GPU, ni forma de saber quién cambió qué. Subir un nivel después de tener LLMs ya en producción cuesta órdenes de magnitud más que subirlo cuando el cluster aún está vacío.

La analogía: del puesto callejero al restaurante con estrella

Imagina la escala de un negocio de hostelería. Nivel 0 es el puesto callejero: una plancha, una bombona, un cocinero que improvisa. Puede vender comida — funciona — pero cualquier cosa que se desvíe del día normal (una inspección sanitaria, un cliente alérgico, un pedido de 200 raciones) le tira el negocio. Nivel 1 es el bar de tapas: cocina dimensionada, carta corta repetible, varios turnos. El cocinero ya no improvisa cada día; trabaja sobre un menú escrito, aunque las recetas viven en la cabeza del jefe. Nivel 2 es el restaurante con menú del día: hay procedimientos escritos, proveedores fijos, control de stock, libro de incidencias. Si el cocinero principal se cae enfermo, el segundo puede sacar el servicio sin estragos. Nivel 3 es el restaurante con carta y servicio formal: trazabilidad de cada ingrediente, alérgenos en la carta, certificación sanitaria, contrato con los proveedores, formación obligatoria del personal. Nivel 4 es la cocina especializada en un producto complejo (sushi, alta cocina, panadería artesanal): herramientas específicas que el restaurante normal no necesita (horno de leña, cuchillos especiales, cámara de fermentación), procesos calibrados, métricas de calidad. Nivel 5 es el restaurante con estrella Michelin: el sistema entero funciona, el plato es el resultado de la organización, no del talento de una persona.

La analogía aguanta hasta el final, incluido el detalle más interesante: se puede operar a cualquier nivel, pero las promesas que se pueden cumplir son distintas. El puesto callejero no puede prometer una experiencia consistente a 80 comensales con reserva. El cluster en nivel 1 no puede prometer servicio LLM productivo multi-tenant con SLA. En ambos casos el problema no es de capacidad técnica del último componente (la plancha cocina; el pod arranca); es de capacidad organizativa del sistema entero.

Vamos nivel por nivel.

Nivel 0 — Caótico: el servidor con Linux y nada más

La capacidad que da. Ejecutar contenedores con docker/podman, ejecutar binarios, conectar el servidor a la red. El operador puede entrar por SSH, hacer cosas, y ver resultados.

El test del nivel. “Si reinstalo el servidor desde cero, ¿puedo dejarlo idéntico a como estaba en una tarde, usando sólo notas guardadas?”. Si la respuesta es no (porque los pasos están en la cabeza del que lo montó, en .bash_history, en un wiki desactualizado), estás en nivel 0.

Piezas mínimas que dejar resueltas antes de subir a nivel 1.

Pieza	Decisión sugerida en 2026	Por qué importa al subir
Distribución Linux	Debian estable u Ubuntu LTS	Soporte largo, predecible, kernel reciente disponible
Kernel	LTS reciente (≥ 6.6) con BPF y schedulers modernos	Cilium/eBPF, drivers NVIDIA recientes lo exigen
Drivers NVIDIA	Versión que casa con la CUDA del motor LLM que vas a servir	Mismatch driver/CUDA bloquea vLLM antes de empezar
Container runtime	`containerd`	Estándar CNCF, integrado con RKE2/kubeadm
Filesystem raíz	XFS o ext4 + LVM thin pools	Snapshots, ampliación en caliente
Sincronización horaria	`chrony` con servidores propios	TLS, logs correlados, certificados cortos lo exigen
Red de gestión	VLAN dedicada, ACLs en switch	Aislar plano de control del tráfico de carga
Red de cluster	LACP + jumbo frames + BGP (si vas a Cilium)	NVLink intra-nodo no salva la red de servicio
BMC / IPMI	Acceso fuera de banda con TLS y MFA	Recuperación cuando el sistema operativo no arranca

Antipatrones que te dejan clavado en nivel 0.

Servidores mascota (con nombre propio, configurados a mano, no reemplazables).
Cambios aplicados con vi directo sobre /etc/... sin commit a un repo.
Despliegue con docker-compose sin healthchecks ni reinicio automático.
Inventario que vive en una hoja Excel que nadie actualiza.

Orden de despliegue dentro del nivel. Imagen del sistema desde PXE/cloud-init con configuración inicial (LVM, hostname, red, SSH key, chrony) → bootstrap de bastion/jump host → inventario en Ansible (o equivalente declarativo aunque luego se reemplace) → drivers NVIDIA + container runtime → smoke test (un contenedor CUDA pasa nvidia-smi). En este punto, el servidor está listo para que entre Kubernetes.

Nivel 1 — Repetible: cluster Kubernetes operativo

La capacidad que da. Programar contenedores con scheduler, abstracción de red entre pods, volúmenes persistentes, lifecycle de cargas, escalado horizontal manual.

El test del nivel. "¿Puedo perder un nodo y que las cargas se reprogramen sin intervención humana?". Si sí, estás en nivel 1. Si no — porque los pods están pinneados a nodos, porque no hay réplicas, porque las PVCs no se reattachean — sigues en 0 con Kubernetes encima.

Piezas mínimas del nivel.

Pieza	Decisión sugerida en 2026	Alternativa principal
Distribución k8s	RKE2 (CIS-hardened por defecto, sin sobrecosto comercial)	k3s para edge muy pequeño, kubeadm puro para casos custom
CNI	Cilium con kube-proxy replacement, BGP, Gateway API	Calico (sin BGP no compite contra Cilium en 2026)
CSI block + filesystem + object	Rook-Ceph (RBD + CephFS + RGW S3-compatible)	OpenEBS Mayastor + Garage para deployments pequeños
Ingress	Cilium Gateway API (mejor unificar con CNI)	NGINX Ingress, Traefik
Cert básico	Self-signed bootstrap	(cert-manager entra en nivel 3)
Manejo de cargas	`kubectl apply` + Helm desde terminal	Sin GitOps todavía
Container registry	Cualquier registry interno (o externo de confianza) con TLS	(registry interno gestionado entra en nivel 2)

Antipatrones que te bajan a nivel 0.

Servicios desplegados con kubectl apply desde la terminal de una persona y sin guardar el YAML en ninguna parte.
Volúmenes persistentes sin política de backup.
“Cluster de un nodo” como producción permanente — un solo punto de fallo arquitectónico.
CNI sin NetworkPolicy disponible o sin BGP cuando la red lo requiere.

Orden de despliegue dentro del nivel. RKE2 instalado en al menos tres nodos para control plane HA → Cilium instalado en modo kube-proxy replacement + BGP control plane → Rook-Ceph en al menos tres nodos cubriendo block (RBD) + filesystem (CephFS) + object (RGW S3-compatible) con replicación 3× o Erasure Coding según pool → smoke test (un Deployment con PVC arranca, los pods se reschedulean al cordon de un nodo, los datos persisten).

Nivel 2 — Definido: el cluster se reconstruye desde git

La capacidad que da. El estado del cluster vive en un repositorio. Cualquier cambio pasa por commit. Cualquier persona puede reconstruir el cluster (o uno equivalente) desde el repo y los backups. La observabilidad básica avisa cuando algo se rompe.

El test del nivel. “Si pierdo el cluster entero, ¿puedo recrearlo en X horas desde el repo + los backups, sin intervención manual fuera del bootstrap?”. Las dos horas son negociables; lo que define el nivel es que el repo + los backups bastan, no que la persona-que-sabe esté disponible.

Piezas mínimas del nivel.

Pieza	Decisión sugerida en 2026	Por qué
Forge	Forgejo (o Gitea, GitLab CE)	OSS auto-alojado, fork comunitario de Gitea, gobernanza abierta
Reconciliador GitOps	Flux	CNCF graduado, multi-tenancy nativo, lightweight
Registry de imágenes	Forgejo Container Registry	Junto al código, sin pieza extra
TSDB métricas	VictoriaMetrics + vmagent	Throughput superior a Prometheus puro, retención larga, compatible PromQL
Visualización	Grafana	Estándar de facto
Logs	Loki o Vector	OSS, integrado con Grafana
Alerting	Alertmanager + Keep (orquestador OSS)	Keep añade enrutamiento multi-canal sin lock-in
Backups DB	Barman Cloud (Postgres)	Estándar para CNPG
Backups objeto / dataset	Ceph RGW multisite + snapshots CephFS	Cross-pool y cross-site

Antipatrones que te bajan a nivel 1.

kubectl apply aplicado en producción fuera del repo (drift no detectado).
Branches main con permisos de escritura para humanos sin revisión.
Repo monolítico sin separación tenant/infra/apps (cambios cruzados no auditables).
Métricas que no se conservan más de 7 días (sin SLO observable a un mes vista).
Alerting que dispara para todo (fatiga) o para nada (silencio).

Orden de despliegue dentro del nivel. Forgejo desplegado primero (es prerrequisito de todo lo demás) → Flux instalado y apuntando al repo de manifests → repositorio inicial con Helm releases de Cilium y Rook-Ceph reconciliados por Flux (sustituyendo los kubectl apply del nivel 1) → VictoriaMetrics + Grafana + Loki vía Helm/Flux → backups Postgres y snapshots Ceph programados → smoke test (tira el cluster, restaura desde repo + backup, los servicios vuelven).

Nivel 3 — Gestionado: identidades, certificados, secretos y políticas

La capacidad que da. Cualquier humano que opera el cluster lo hace con identidad propia (no kubeconfig compartido), con MFA y con permisos limitados. TLS interno automático. Secretos versionados encriptados. Políticas que rechazan configuraciones inseguras antes de que entren al cluster. Auditoría completa de quién hizo qué.

El test del nivel. “Si un atacante consigue el portátil de un administrador, ¿qué puede hacer en producción?”. En nivel 3 la respuesta es “poco”: MFA bloquea el segundo factor, las políticas Kyverno bloquean cambios destructivos sin aprobación, las NetworkPolicies impiden lateral movement, los secretos están encriptados con KMS externo, el audit log queda. En nivel 2, “todo”.

Piezas mínimas del nivel.

Pieza	Decisión sugerida en 2026	Por qué
IdP / OIDC	Defguard	OSS español, WireGuard + OIDC + 2FA, multi-org
Federación con cluster	OIDC en kube-apiserver, OIDC en Forgejo, OIDC en Grafana	SSO consistente
PKI interna	cert-manager + Trust Manager	Estándar de facto, ACME y CA interna
ACME externo	Let’s Encrypt para certs de borde	Sin pago, automatizado
Secretos en git	SOPS + age o KMS externo	Versionable, encriptado en repo
Sync de secretos	External Secrets Operator	Pull desde KMS / Vault al cluster
Policy as code	Kyverno (o OPA Gatekeeper)	Kyverno tiene menos curva de aprendizaje
NetworkPolicy	Cilium NetworkPolicy + L7	Default deny per namespace
Runtime security	Tetragon (Cilium)	eBPF, complementa NetworkPolicy con detección
Vulnerability scanning	Trivy en pipeline CI + admission	SBOM por imagen, bloqueo de CVE críticas
Audit log	kube-apiserver con `--audit-policy-file` enviado a Loki	Trazabilidad regulatoria

Políticas Kyverno mínimas a tener vivas.

Deny de imágenes :latest o sin sha digest.
Deny de pods sin securityContext.runAsNonRoot=true.
Deny de pods sin resources.limits (CPU + memoria).
Deny de Services sin label owner=<equipo>.
Deny de cambios en namespaces críticos (kube-system, flux-system) sin label de aprobación.

Antipatrones que te bajan a nivel 2.

kubeconfig compartido entre administradores.
Secretos en data: plano del manifest commiteado al repo.
NetworkPolicy ausente en namespaces nuevos por defecto (allow-all implícito).
kubectl edit o kubectl patch en producción sin pasar por el repo.

Orden de despliegue dentro del nivel. Defguard desplegado y enrolado con WireGuard / OIDC → integración OIDC con kube-apiserver, Forgejo y Grafana → cert-manager instalado y emitiendo certificados internos (CA propia para mTLS, Let’s Encrypt para borde) → SOPS configurado y External Secrets Operator instalado → migración de secretos plano → encriptado → Kyverno con políticas iniciales y modo audit, después enforce → NetworkPolicy default-deny por namespace → Tetragon habilitado → smoke test (intentar saltarse cada política y comprobar que las admisiones rechazan).

Nivel 4 — Optimizado para GPU: el cluster ya sabe lo que es una H100

La capacidad que da. El scheduler de Kubernetes ve las GPUs, las distingue, las puede particionar (MIG) o multiplexar (time-slicing), exponer métricas DCGM, autoescalar con KEDA usando métricas de la propia carga LLM (vllm:num_requests_running, vllm:gpu_cache_usage_perc), transportar trazas con semantic conventions GenAI. Todo lo necesario para que el stack de inferencia LLM se apoye en una plataforma que entiende su naturaleza.

El test del nivel. “Si pongo un pod que pide nvidia.com/gpu: 1, ¿se programa en la GPU correcta, con el slice correcto, con métricas DCGM expuestas, con observabilidad GenAI lista para recibir spans?”. Si sí, estás en nivel 4. Si la respuesta requiere “depende de qué nodo y quién lo despliegue”, todavía no.

Piezas mínimas del nivel.

Pieza	Decisión sugerida en 2026	Por qué
GPU device plugin	NVIDIA GPU Operator	Despliega drivers, container toolkit, DCGM y MIG manager con un operator
Particionamiento HW	MIG (Multi-Instance GPU) en H100 cuando aplique	Aislamiento hardware real, no time-slicing
Métricas GPU	DCGM Exporter	SM utilization, VRAM, temperatura, throttling, NVLink bandwidth
Métricas LLM	vLLM Prometheus endpoint + scrape	TTFT, TPOT, KV cache, prefix hit rate
Autoscaling	KEDA con ScaledObject Prometheus	Escala por métricas LLM, no por CPU
Operadores LLM	vLLM Production Stack / OME (Operator Model Engine)	Manejo declarativo de modelos / adapters
Trazas	OpenTelemetry Collector con receivers OTLP + processors + exporters	Semantic conventions `gen_ai.*` (post)
LeaderWorkerSet	API LeaderWorkerSet (k8s 1.30+)	Topología tensor parallel coherente con NVLink
Topology Manager	habilitado con `single-numa-node`	Pin de pods GPU a NUMA correcta

Decisión clave: MIG, time-slicing o pasthrough.

MIG divide una H100 en 1g.10gb, 2g.20gb, 3g.40gb, 7g.80gb (slices con aislamiento HW real). Útil para servir varios modelos pequeños o reservar capacidad por tenant con garantía. Limitación: hasta 7 instancias por GPU, perfiles predefinidos.
Time-slicing comparte una GPU entre varios pods sin aislamiento HW. Útil para dev/test, no para producción multi-tenant con SLA.
Passthrough asigna la GPU entera a un pod. Útil para tensor parallel sobre múltiples GPUs del mismo nodo (LLM grande con TP=4).

Para una plataforma LLM productiva, la regla práctica: passthrough para los modelos grandes con TP, MIG para embeddings y modelos pequeños que cohabitan, nunca time-slicing en producción.

Antipatrones que te bajan a nivel 3.

Instalar drivers NVIDIA a mano fuera del GPU Operator (rotura silenciosa al actualizar Kubernetes).
Servir un LLM con requests.gpu: 1 sin haber decidido MIG / passthrough (terminas con GPUs idle por fragmentación o pods que se pisan).
KEDA autoscalando por CPU (HorizontalPodAutoscaler clásico) en pods que están casi siempre al 10% de CPU pero al 95% de KV cache.
OpenTelemetry desplegado pero sin semantic conventions gen_ai.* (las trazas no son LLM-aware).

Orden de despliegue dentro del nivel. NVIDIA GPU Operator instalado vía Helm/Flux con la versión de driver que case con el motor LLM elegido → DCGM Exporter habilitado y métricas visibles en Grafana (dashboards NVIDIA importados) → MIG manager configurado para los nodos donde tenga sentido (mezcla typical en cluster 4×H100 SXM: dos GPUs con passthrough completo para el LLM general TP=4, dos GPUs particionadas en 2×3g.40gb cada una para LLMs pequeños + embeddings) → OpenTelemetry Collector con processors attributes para enriquecer spans con etiquetas propias (tenant_id, priority_tier) + exporters a Langfuse y a Tempo → KEDA instalado con ScaledObject de ejemplo apuntando a vllm:num_requests_running → vLLM Production Stack o OME para declarar modelos como CRD → smoke test (un Deployment de vLLM declarado vía CRD arranca, sirve un token, expone métricas, la traza llega a Langfuse, KEDA escala bajo carga sintética).

Nivel 5 — Handoff: el cluster es plataforma LLM, las siete capas entran encima

Llegado al nivel 4, el cluster cumple el contrato que el post de las siete capas asumía como punto de partida. El nivel 5 no añade infraestructura: añade el stack LLM propiamente dicho. Por completitud, los siete componentes del nivel 5 son:

Gateway (Envoy AI Gateway) — entra primero, dirige tráfico a inferencia LLM y embeddings.
Inferencia LLM (vLLM Production Stack o OME con vLLM) — sobre las GPUs ya descubiertas por el GPU Operator del nivel 4.
Embeddings + reranker (Infinity, TEI) — pod separado del LLM, ya cubierto en el post anterior.
Vector store + datos relacionales (Qdrant, PostgreSQL CNPG, Ceph RGW para pesos y adapters, CephFS para datasets) — la mayoría ya existía en nivel 2 como datos; ahora se especializa para RAG.
Observabilidad LLM-aware (Langfuse) — se enchufa a la cadena OTel del nivel 4.
Control plane GitOps — el del nivel 2 sigue siendo la única autoridad legítima.
Dependency tracking (Hubble flows + Otterize) — sobre Cilium que ya existía en nivel 1.

El criterio para promocionar de nivel 4 a nivel 5 no es técnico: es contractual. El cluster ya soporta LLMs; la decisión es cuándo abrir tráfico real de clientes. La promoción exige: golden eval del modelo verde, runbook de incidentes firmado, SLOs negociados, plan de continuidad, mapeo a ENS / NIS2 / 42001 si aplica.

Las matemáticas que importan: cuánto cuesta saltarse un nivel

Para cuantificar la tesis del post, una estimación con orden de magnitud del coste de subir cada nivel a tiempo versus subirlo después de tener producción. Las cifras son tiempo de ingeniería con un equipo de plataforma pequeño (2-3 personas), asumiendo plantillas y experiencia previa.

Nivel	Tiempo a montar sobre cluster vacío	Tiempo a retrofit con producción rodando
0 → 1	1-2 semanas	1-2 semanas (poco refactor downstream)
1 → 2	2-3 semanas	4-8 semanas (migrar todo a git)
2 → 3	2-4 semanas	8-16 semanas (rebuild de imágenes, migración de secretos, RBAC retroactivo)
3 → 4	1-2 semanas	4-8 semanas (reconfigurar GPU, mover modelos a MIG, instrumentar `gen_ai.*`)
4 → 5	1-2 semanas	2-4 semanas
Total 0 → 5	~10-15 semanas	~20-40 semanas si se hace en orden equivocado

Multiplicador típico observable en la práctica: 2× a 3× el coste si se hace en orden equivocado. Y eso asumiendo que se llega a hacer — muchos proyectos no superan el nivel 2 nunca porque “lo de la identidad” siempre puede esperar a otro sprint. Cuando llega el incidente, ya es tarde para empezar.

Más allá del tiempo, el coste operativo (incidentes nocturnos, escapes de seguridad, deuda invisible) crece exponencialmente con el desfase entre el nivel real y el nivel necesario. Un cluster en nivel 2 sirviendo LLMs productivos en clientes regulados es una bomba de relojería: técnicamente funciona, organizativamente no.

Diagrama final: la escalera completa con piezas

La escalera no es decorativa: cada nivel enable el siguiente. No se puede tener observabilidad LLM-aware (nivel 4) sin OTel desplegado vía Flux (nivel 2). No se puede tener TLS interno automático (nivel 3) sin un PKI raíz que viva en algún sitio (registro y certificados gestionados desde el nivel 2). No se puede tener KEDA escalando por métricas vLLM (nivel 4) sin Prometheus / VictoriaMetrics scrapeando (nivel 2). Los niveles no son una jerarquía conceptual: son una jerarquía de dependencias de instalación.

Decisiones de diseño típicas que rompen el progreso

Errores que se ven repetidamente y que tiran el cluster atrás de nivel:

1. Saltar de nivel 1 a nivel 4 directamente. “Tenemos prisa por servir el LLM, lo de identidad y GitOps lo hacemos después”. Después es siempre dos órdenes de magnitud más caro y siempre llega después del primer incidente.

2. Confundir Helm con GitOps. Tener Helm charts no es nivel 2. Es nivel 1 con plantillas. Nivel 2 exige que un reconciliador (Flux/ArgoCD) aplique las charts desde un repo, detecte drift y avise.

3. cert-manager sin policy de uso. Tener certificados auto-renovados pero usar TLS sólo en el ingress, sin mTLS interno entre servicios, deja la promesa de TLS coja y baja el nivel 3 a un cosplay del 3.

4. NVIDIA drivers a mano. Funciona el día uno y se rompe el día del primer upgrade de kernel. La regla: drivers siempre vía GPU Operator, nunca paquetes del sistema operativo.

5. Métricas Prometheus pero retención de 7 días. Sin retención larga (≥ 90 días) no hay SLO honesto. VictoriaMetrics con 1 año de retención cuesta poco más que Prometheus con 7 días, y desbloquea cumplimiento y postmortems serios.

6. OIDC sólo para kube-apiserver. Si Forgejo, Grafana, Defguard y vLLM cada uno tiene su propio sistema de auth, no tienes SSO, tienes islas. Un nivel 3 honesto exige federación.

7. Kyverno en modo audit permanente. Las políticas que no rechazan no son políticas, son alertas. En algún momento hay que pasar a enforce. Mientras tanto, sigues en nivel 2 con cara de 3.

8. MIG sin decisión consciente del perfil. Configurar MIG con el perfil por defecto sin haber medido el tamaño de los modelos que van a cohabitar deja GPUs fragmentadas con slices que nadie usa. La regla: MIG sólo si has medido y has decidido los perfiles por adelantado.

Todos comparten una raíz: declarar el nivel sin pasar el test del nivel. Decir “ya hicimos GitOps” cuando todavía se aplican cosas con kubectl edit en prod. Decir “ya hicimos identidad” cuando hay un kubeconfig admin compartido. Decir “estamos listos para LLM” cuando no hay DCGM Exporter ni Langfuse enchufado.

Aplicado a hardware on-premise típico: cluster 4×H100 SXM

Sobre el cluster genérico de referencia (4×H100 SXM 80 GB, NVLink, 640 GB RAM), un setup razonable después de pasar los cinco niveles distribuye así los componentes:

control plane (3 nodos sin GPU, hostnames cp-01..03)
├── kube-apiserver, etcd, controller-manager, scheduler
├── Flux, Forgejo, cert-manager, External Secrets, Kyverno
└── Tetragon (DaemonSet también aquí)

worker plane (≥ 3 nodos sin GPU, hostnames worker-cpu-01..03)
├── Cilium agent (DaemonSet)
├── Rook-Ceph OSDs + MONs + MDS (CephFS) + RGW (S3)
├── VictoriaMetrics + Grafana + Loki
├── Defguard (StatefulSet)
└── Langfuse + OTel Collector

worker plane GPU (≥ 2 nodos con 4×H100 SXM, hostnames worker-gpu-01..02)
├── NVIDIA GPU Operator (driver + container toolkit)
├── DCGM Exporter (DaemonSet)
├── MIG manager (configurando el perfil decidido)
├── vLLM (Deployment) — LLM general TP=4 ocupa 4 GPUs (passthrough)
├── vLLM (Deployment) — LLM código TP=2 ocupa 2 GPUs
├── Infinity (embeddings) — 2 réplicas cohabitan en 2 slices MIG
└── KEDA scaler escuchando métricas vLLM

La regla operativa: el plano de control y el plano CPU se separan del plano GPU. Un incidente en el plano GPU no debe llevarse por delante el plano de control (que es lo que recupera el cluster). Y el plano CPU concentra todo lo que mueve estado relevante (Forgejo, Rook-Ceph, Postgres CNPG, Langfuse): es el corazón a proteger.

El hardware GPU se especializa al máximo: pods GPU solamente corren en nodos GPU, y los nodos GPU no corren nada CPU-bound aparte del overhead operativo (Cilium, GPU Operator, DCGM). Esto se enforza con nodeSelector + taints/tolerations + Kyverno policy que rechaza pods sin requests GPU programándose en nodos GPU.

Lo que no hemos cubierto (próximos posts)

Este post recorre el camino vertical hacia arriba. Quedan piezas horizontales y otras transversales que merecen su propio artículo:

Multi-site activo/standby: cómo se federan dos clusters con Cilium Cluster Mesh y qué cambia en cada nivel cuando hay dos sites en lugar de uno.
Migración entre niveles con tráfico real: cómo se retrofitea un cluster que ya está en producción al nivel siguiente sin downtime.
La operación día a día: runbooks por nivel, qué dashboards mirar cada mañana, qué SLOs definir por componente.
El plano de coste: cuánto cuesta cada nivel en hardware, energía, horas de ingeniería, licencias OSS opcionales (soporte comercial de Rancher, Cilium Enterprise, etc.) y cuándo cada gasto se justifica.
Cumplimiento operacionalizado: cómo se mapean los niveles 3 y 4 a controles ENS Alto, NIS2 e ISO/IEC 42001 sin convertir el cluster en un ejercicio de paperwork.

Ver también

Anatomía de un stack de inferencia LLM on-premise — lo que se monta encima de un cluster en nivel 4. Este post es su prequel arquitectónico.
El catálogo OSS para LLMOps en seis etapas — fichas individuales de muchas de las piezas citadas aquí.
Tracing LLM con OpenTelemetry GenAI — el OTel del nivel 4 con detalle de las semantic conventions gen_ai.*.
Pipeline LLMOps de seis etapas — el marco operacional que vive sobre el cluster nivel 5.

Referencias

RKE2 Documentation — docs.rke2.io
Cilium documentation — docs.cilium.io
Rook-Ceph — rook.io
Flux GitOps toolkit — fluxcd.io
Forgejo — forgejo.org
cert-manager — cert-manager.io
External Secrets Operator — external-secrets.io
Kyverno — kyverno.io
NVIDIA GPU Operator — docs.nvidia.com/datacenter/cloud-native/gpu-operator
DCGM Exporter — github.com/NVIDIA/dcgm-exporter
KEDA — keda.sh
LeaderWorkerSet API — github.com/kubernetes-sigs/lws
vLLM Production Stack — docs.vllm.ai/en/latest/serving/production_stack.html
OpenTelemetry Semantic Conventions for GenAI — opentelemetry.io/docs/specs/semconv/gen-ai
CIS Kubernetes Benchmark
NIST SP 800-207 — Zero Trust Architecture