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

Despliegue on lo0 — Blog Técnico