Category: Nube e Infraestructura

Kubernetes en el mediano mercado tiene un problema que rara vez se discute con honestidad: la mayoría de clusters están sobre-aprovisionados entre dos y cuatro veces sobre la demanda real. La factura mensual crece linealmente con la organización, los workloads se programan en nodos sub-utilizados, las solicitudes de recursos se inflan por miedo a OOM, y nadie sabe cuál es la unidad económica real de cada servicio. En 2026, con el coste de compute escalando junto con la adopción de IA, esta indisciplina se ha vuelto inviable.

Este artículo presenta el marco operativo de optimización de costes de Kubernetes específicamente para organizaciones de 50 a 500 ingenieros: suficientemente grandes para que K8s tenga sentido, pero no tan grandes como para tener un equipo dedicado de plataforma con FinOps integrado.

El problema fundamental: requests vs uso real

El driver número uno de coste innecesario en Kubernetes es el desajuste entre resources.requests y consumo real. Los equipos solicitan 2 CPU y 4 GB para servicios que consumen 0.2 CPU y 800 MB en P99. El scheduler reserva la solicitud, los nodos se llenan a 30% de utilización medida, y la organización paga por capacidad que nadie usa.

La causa raíz es cultural, no técnica: los equipos sobre-solicitan por miedo. Una vez vivieron un OOMKilled en producción y desde entonces piden el doble “por si acaso”. Sin disciplina y sin observabilidad de consumo real, este patrón se acumula durante años.

• Recomendación 1: instrumente Vertical Pod Autoscaler en modo recommendation-only en todos los namespaces durante 30 días. Genera recomendaciones basadas en consumo real sin actuar.
• Recomendación 2: publique un dashboard de “requests vs uso real” por equipo. La transparencia organizacional cambia comportamiento más rápido que cualquier política.
• Recomendación 3: defina ratios objetivo (por ejemplo, request/uso P95 menor a 1.5×). Los outliers se convierten en tickets de optimización con dueño asignado.

Karpenter: la diferencia que marca

Para clusters EKS, Karpenter ha desplazado al Cluster Autoscaler tradicional con una ventaja material: provisiona nodos basándose en los requisitos exactos de los pods pendientes, no en grupos predefinidos de nodos uniformes. Esto significa diversidad de instancias automática, consolidación agresiva de nodos sub-utilizados y bin-packing más denso.

La adopción típica reduce el coste de compute entre 15% y 40% sin cambiar ninguna otra cosa, simplemente porque Karpenter elige instancias mejor ajustadas y consolida nodos huérfanos. Para clusters GKE, el equivalente nativo (Cluster Autoscaler con node auto-provisioning) ha mejorado, pero sigue siendo menos agresivo en consolidación.

Tuning crítico de Karpenter

• Consolidation policy: habilite WhenEmptyOrUnderutilized. El default conservador deja capacidad ociosa.
• Diversidad de instancias: defina NodePools con familias amplias (m, c, r) en lugar de tipo único. Karpenter elige el más barato disponible.
• Arquitectura mixta: habilite arm64 (Graviton en AWS). 20-30% más barato para workloads que toleran la arquitectura.
• Disruption budgets: configure budgets para evitar consolidación masiva en horas de pico.

Spot fleet design: dónde aplica y dónde no

Las instancias spot ofrecen descuentos del 60-90% comparado con on-demand. Pero spot mal aplicado degrada disponibilidad sin ahorrar dinero significativo cuando se contabilizan los costes de incidentes y de complejidad operativa.

El árbol de decisión para spot:

• 100% spot: workloads batch, jobs de CI/CD, entrenamiento de ML, procesamiento asíncrono con retry tolerable, entornos de desarrollo y staging.
• Mix spot + on-demand: servicios stateless con réplicas múltiples y SLO menor a tres nueves. Defina baseline en on-demand y elasticidad en spot.
• 100% on-demand (o reservas): servicios stateful (bases de datos, brokers de mensajería), workloads con SLO de cuatro nueves o superior, componentes de control plane críticos.

Karpenter facilita esta segmentación con NodePools diferenciados y taints. Lo que no debe hacerse: mover servicios stateful a spot por “ahorro”. El coste de una interrupción de Postgres a las tres de la mañana excede años de ahorro spot.

Idle node detection y consolidación

Aun con Karpenter, los clusters acumulan nodos sub-utilizados por DaemonSets pesados, pods con anti-affinity rígido o reservations de extension resources que el scheduler no puede consolidar. El audit periódico es necesario.

Métricas a vigilar semanalmente:

• Nodos con utilización CPU menor a 30% durante más de 24 horas continuas.
• Distribución de pods por nodo: nodos con uno o dos pods pequeños son candidatos a consolidación manual.
• DaemonSets pesados: agente de logs que consume más que la aplicación. Suele indicar mal-configuración o tooling redundante.
• Pods huérfanos: ReplicaSets de deployments eliminados, jobs completados no limpiados, pods evicted que no fueron recreados.

Namespace quotas: la primera línea de defensa

Sin cuotas por namespace, un equipo puede consumir todo el cluster con una mala configuración de réplicas. ResourceQuota y LimitRange a nivel namespace son trivial de configurar y desproporcionadamente efectivos en limitar daño.

• ResourceQuota: límite total de CPU/memoria solicitable por namespace, número máximo de pods, número máximo de PVCs.
• LimitRange: defaults para pods que no especifican requests/limits, máximos absolutos por pod individual.
• PriorityClass: los pods críticos del cluster (ingress, observability, security) tienen prioridad alta y no son evictables.

El beneficio secundario es organizacional: cada equipo ve cuánta capacidad consume y se vuelve responsable de su propio consumo. La factura cloud agregada deja de ser un misterio.

FinOps tooling: Kubecost, OpenCost, Cast.ai

El problema de atribución de costes Kubernetes está resuelto. Tres opciones principales según presupuesto y madurez:

• OpenCost (open source, CNCF): baseline gratuito. Atribución por namespace, deployment, label. Integración con Prometheus. Suficiente para organizaciones que tienen equipo capaz de operarlo.
• Kubecost (versión enterprise sobre OpenCost): UI pulida, alertas, recomendaciones automáticas de rightsizing, soporte multi-cluster. Vale el costo cuando el ahorro identificado excede la licencia.
• Cast.ai: optimización automatizada con SLAs de reducción de coste. Costo más alto pero hace el trabajo de optimización por usted. Sentido para equipos pequeños sin bandwidth FinOps dedicado.

El error a evitar: comprar la herramienta sin asignar dueño organizacional. Una herramienta de FinOps sin un humano que actúe sobre sus recomendaciones es un dashboard caro.

Cuándo abandonar Kubernetes por completo

La pregunta incómoda que pocos consultores formulan: ¿debería su organización estar en Kubernetes en absoluto? Para equipos con menos de 100 ingenieros y workloads simples, K8s puede ser una sobre-inversión. Las alternativas modernas han mejorado lo suficiente para reconsiderar.

Indicadores de que K8s no era la elección correcta

• El equipo dedica más del 20% de su tiempo a operar K8s en lugar de construir producto.
• Los workloads son una docena de servicios stateless sin necesidades especiales de orquestación.
• Los costes de plataforma exceden los costes de compute aplicativo real.
• Cada incidente toma horas porque el debug atraviesa cinco capas de abstracción K8s.

Alternativas viables en 2026: AWS Fargate o ECS para contenedores sin control plane K8s, Google Cloud Run para serverless containers con escalado a cero, Fly.io o Render para plataformas opinionated full-stack. Migrar fuera de K8s es factible si el equipo es honesto sobre el coste de mantener la plataforma.

Reserved instances y savings plans: la otra capa

Optimización de Kubernetes es una conversación; optimización de compromiso de compute es otra. Las dos son ortogonales y ambas importan. Karpenter elige el mejor instance type, pero el descuento sobre ese instance type depende de su perfil de compromiso con el proveedor cloud.

El patrón operativo en AWS para clusters con uso predecible: Savings Plans tipo Compute cubriendo el baseline (típicamente 60-70% del uso medio mensual), Karpenter operando sobre el resto en mezcla de on-demand y spot. Compute Savings Plans son flexibles (cubren EC2, Fargate y Lambda en cualquier región), un 17-27% más baratos que on-demand sin obligar a tipo de instancia específico.

• Compromiso a uno o tres años: tres años da descuento mayor pero menos flexibilidad. La regla: si la arquitectura cambiará en menos de tres años, uno año.
• Baseline conservador: comprometer al 80% del uso es arriesgado si la organización decrece o migra arquitectura. 60-70% deja margen.
• Revisión trimestral: el uso cambia, la cartera de Savings Plans debe revisarse y ajustarse.
• Equivalentes en otros clouds: Committed Use Discounts en GCP, Reserved Instances en Azure, con dinámicas similares.

Egress y networking: el coste invisible

El compute es visible; el networking es invisible hasta que aparece la factura. En clusters K8s grandes, los costes de egress entre zonas de disponibilidad, entre regiones, y hacia internet pueden representar 15-30% de la factura cloud total. Y casi nadie los optimiza porque no aparecen en Kubecost por defecto.

• Cross-AZ traffic: los pods que hablan entre sí en zonas diferentes pagan tráfico inter-AZ. Configure topology spread constraints y service mesh con preferencia same-AZ.
• NAT Gateway: tráfico outbound de pods hacia internet pasa por NAT Gateway en arquitecturas estándar. Volumen alto + precio por GB = factura sorpresa. VPC Endpoints para servicios AWS internos eliminan gran parte.
• Load Balancer pricing: ALBs y NLBs cobran por LCU consumido, no solo por hora. Tráfico TLS pesado infla LCUs. Reuse de listeners y certificados ayuda.
• Replicación de datos cross-region: útil para DR pero costoso. Revise si la frecuencia y volumen están alineados con RPO real.

La instrumentación: VPC Flow Logs habilitados y analizados en una herramienta de costo de red (vantage.sh, Sysdig, o queries directas en Athena sobre los flow logs). El primer mes de visibilidad típicamente revela uno o dos patrones de tráfico que pueden eliminarse o ruteo más eficiente que ahorra 5-10% de la factura inmediatamente.

Cuándo aplica este marco, cuándo no

Cuándo aplica: organizaciones con facturas mensuales de Kubernetes mayores a 25k USD donde nadie sabe explicar la composición; clusters con más de 50 nodos donde la utilización media es menor al 50%; equipos que han crecido en K8s sin disciplina FinOps desde el inicio.

Cuándo no aplica: clusters de desarrollo o exploratorios donde el coste absoluto es menor; organizaciones que están en proceso de migrar fuera de K8s y donde la inversión en optimización compite con la migración misma; equipos sin observability básica de Kubernetes (instale Prometheus y dashboards antes de optimizar; no puede optimizar lo que no mide).

La optimización de Kubernetes no es un proyecto único. Es una práctica continua que se vuelve parte del ciclo de vida de cada servicio. Las organizaciones que la institucionalizan reducen sus facturas 30-50% en seis meses y mantienen la disciplina indefinidamente. Las que no, descubren cada trimestre que el coste cloud subió otro 20% y nadie sabe por qué.

Durante la mayor parte de la última década, la criptografía post-cuántica (PQC) fue una conversación académica que los CTOs podían posponer. En 2024, NIST finalizó los primeros estándares. En 2025, la NSA publicó CNSA 2.0 con timeline obligatorio para sistemas de seguridad nacional. En 2026, los principales vendors (AWS, Google, Cloudflare, Microsoft) ya despliegan PQC híbrido en TLS por defecto. La conversación pasó de “si” a “cuándo y cómo”, y el cuándo es ahora.

Este artículo presenta el marco operativo de migración PQC: qué estándares importan, cómo hacer inventario criptográfico, qué significa el modo híbrido y cómo construir crypto-agility para no repetir esta migración cada vez que algo cambie.

El reloj que ya está corriendo: “harvest now, decrypt later”

Aunque los computadores cuánticos relevantes para romper RSA-2048 o ECDH-P256 probablemente no existan antes de 2030-2035, el riesgo no espera a esa fecha. Adversarios sofisticados (estados-nación, grupos APT) están capturando y almacenando tráfico cifrado hoy para descifrarlo cuando la capacidad cuántica esté disponible. Cualquier dato con valor a largo plazo (registros médicos, secretos comerciales, datos clasificados, propiedad intelectual estratégica) está efectivamente expuesto hoy si se transmite con cifrado solamente clásico.

Esto significa que la pregunta no es “¿cuándo debo migrar?” sino “¿cuánto tiempo de exposición acumulada puedo aceptar?”. Para datos sensibles con horizonte de confidencialidad mayor a cinco años, la respuesta empieza a parecerse a “empezar ya”.

Los estándares NIST PQC: qué son y dónde aplican

NIST finalizó cuatro algoritmos en su primera ronda de estandarización, cada uno cubriendo un caso de uso distinto. La nomenclatura ha cambiado entre los borradores y los estándares finales; use los nombres FIPS oficiales.

• ML-KEM (anteriormente Kyber, FIPS 203): mecanismo de encapsulamiento de claves (KEM). Reemplaza el rol de RSA-OAEP y ECDH para establecimiento de claves en TLS, VPN, intercambio de sesión. Tres niveles de seguridad: ML-KEM-512, 768, 1024.
• ML-DSA (anteriormente Dilithium, FIPS 204): firma digital. Reemplaza RSA-PSS y ECDSA para firma de certificados, código, documentos. Niveles 44, 65, 87.
• SLH-DSA (anteriormente SPHINCS+, FIPS 205): firma digital basada en hash. Más lenta y con firmas más grandes que ML-DSA, pero apoyada en supuestos criptográficos extremadamente conservadores. Para casos donde la longevidad importa más que el rendimiento.
• FALCON (FIPS 206 en draft): firma digital alternativa basada en lattice. Firmas más compactas que ML-DSA, útil en contextos con limitaciones estrictas de tamaño (firmware embedded, certificados X.509 con limitaciones).

La selección operativa por defecto: ML-KEM-768 para establecimiento de claves y ML-DSA-65 para firma, como reemplazo de propósito general de los algoritmos clásicos equivalentes en seguridad. SLH-DSA y FALCON se evalúan caso por caso.

Fase de inventario: lo que no puede medir, no puede migrar

La fase más subestimada y más crítica. Antes de migrar nada, debe saber qué criptografía existe en su organización, dónde vive y cuál es su exposición cuántica. Sin inventario, la migración es un caos de ad hoc.

Áreas a inventariar

• TLS: qué versiones, qué cipher suites, qué clientes y servidores. Auditar load balancers, ingress controllers, service mesh, conexiones outbound a APIs externas.
• Code signing: certificados que firman binarios, artefactos de release, contenedores. Apple, Microsoft, Google Play.
• PKI interna: CAs raíz, intermedias, certificados emitidos. ¿Cuántos años de vida tienen los certificados emitidos hoy?
• S/MIME y correo: firma y cifrado de email corporativo, especialmente en sectores regulados.
• VPN: IPsec, WireGuard, OpenVPN. Algoritmos de intercambio de claves y autenticación.
• Secretos en reposo: bases de datos cifradas con KMS, secrets managers, HSMs. Algoritmos del wrapping de claves.
• SSH: claves de servidor, claves de usuario, claves de despliegue. Identidades automatizadas con muchos años de existencia.
• Blockchain o firma distribuida: si aplica, sistemas que dependen de ECDSA tienen exposición específica.
• Hardware embedded e IoT: dispositivos en campo con criptografía cementada que no se actualizan en años.

Herramientas que aceleran el inventario: SBOMs criptográficos (CBOMs) emergentes en CycloneDX 1.6, scanners como pqc-prepared, auditoría TLS con sslscan/testssl.sh. La parte difícil no es técnica: es organizacional. Hay sistemas legacy que nadie quiere tocar y que probablemente contienen criptografía hardcoded de hace quince años.

Modo híbrido: la única opción razonable para 2026

Los algoritmos PQC son nuevos y no han sufrido el mismo escrutinio criptanalítico durante décadas que RSA o ECC. Una nueva vulnerabilidad teórica en ML-KEM o ML-DSA es plausible. La defensa contra este riesgo es el modo híbrido: combinar un algoritmo clásico con un algoritmo PQC de manera que romper la combinación requiera romper ambos.

En TLS, esto significa cipher suites híbridas como X25519MLKEM768, que ya están desplegadas en Chrome, Firefox y los principales CDNs en 2025-2026. El cliente y el servidor establecen una clave de sesión que es función de ambos intercambios; un atacante necesita romper X25519 (clásico) y ML-KEM-768 (post-cuántico) para descifrar.

• Ventaja: protección frente a fallos catastróficos en cualquiera de los dos algoritmos.
• Desventaja: tamaño de handshake mayor (relevante en redes muy restringidas o protocolos UDP con MTU).
• Conclusión operativa: use híbrido como default hasta que la confianza criptanalítica en PQC iguale a la confianza histórica en algoritmos clásicos. Probablemente esto sea cinco a diez años más.

Timeline realista: NSA 2030, industria 2035

Los timelines de referencia que cualquier CTO debe conocer:

• 2024-2026 (presente): estándares NIST finalizados, soporte en bibliotecas principales (BoringSSL, OpenSSL 3.x, AWS-LC, rustls). Despliegues PQC híbrido en TLS por defecto en navegadores y CDNs.
• 2027-2028: ventana de transición acelerada. Vendors empiezan a deprecar negociación solo-clásico. Auditorías SOC 2 y similares empiezan a preguntar por crypto-agility.
• 2030 (CNSA 2.0 NSA): sistemas de seguridad nacional y proveedores federales con sistemas nuevos requieren PQC. Sistemas existentes deben tener plan de migración aprobado.
• 2035 (industria amplia): deprecación generalizada de RSA-2048 y ECDH P-256 como algoritmos solo-clásicos. Cumplimiento regulatorio en sectores críticos (finanzas, salud, infraestructura) requerirá PQC.

El error táctico común: tratar 2030/2035 como fechas distantes y posponer. La realidad operacional: migrar criptografía a través de una organización de miles de sistemas toma de tres a cinco años cuando se hace con disciplina. Empezar en 2032 es llegar tarde.

Crypto-agility: el patrón que importa más que el algoritmo

La lección estratégica de PQC no es que necesitamos ML-KEM en lugar de RSA. Es que necesitamos sistemas que puedan cambiar de algoritmo sin reescritura. Esto se llama crypto-agility, y la mayoría de software empresarial no la tiene.

Patrones de crypto-agility

• Algoritmos como configuración, no como código: el código no asume RSA-2048; consulta una abstracción que devuelve el algoritmo activo. Cambiar de algoritmo es un cambio de configuración, no de código.
• Identificadores versionados en formatos persistidos: cada firma, cada blob cifrado, cada certificado lleva metadata explícita del algoritmo usado. Permite que múltiples algoritmos coexistan durante la transición.
• Validación de múltiples algoritmos en paralelo: los verificadores aceptan firmas clásicas y PQC durante la transición. Los firmantes pueden producir cualquiera según política.
• Rotación de claves probada regularmente: si nunca rotó una CA, no podrá rotar para migrar a PQC. La rotación es un drill que debe ejecutarse en producción.
• Inventario continuo, no único: CBOMs generados en CI/CD, no auditorías manuales anuales.

Coste operativo: lo que nadie quiere admitir

Los algoritmos PQC son más caros en CPU, en ancho de banda y en almacenamiento que sus equivalentes clásicos. Las firmas ML-DSA son aproximadamente diez veces más grandes que las firmas ECDSA. Los handshakes TLS híbridos transmiten kilobytes adicionales. Para sistemas de bajo volumen, el coste es despreciable; para sistemas a escala (CDNs, IoT con millones de dispositivos, redes con conexiones por segundo en seis dígitos), el coste agregado es material.

• Tamaño de certificados: certificados X.509 con firmas ML-DSA o SLH-DSA son significativamente más grandes. Impacto en CDN cache, en almacenamiento de certificate transparency logs, en handshakes TLS.
• CPU de servidor: ML-KEM en TLS handshake añade carga al servidor TLS. En arquitecturas con millones de handshakes diarios, esto se traduce en capacidad adicional.
• Ancho de banda mobile y edge: handshakes más grandes en redes lentas o con MTU restringido pueden requerir múltiples roundtrips, degradando latencia percibida.
• Almacenamiento de firmas: SLH-DSA produce firmas de varios kilobytes. Aceptable para firma de release única; problemático para sistemas que firman millones de eventos.

La estrategia de mitigación incluye benchmark en condiciones representativas antes de la migración masiva, selección de niveles de seguridad PQC adecuados al contexto (ML-KEM-512 puede ser suficiente donde ML-KEM-1024 sería sobre-ingeniería), y aceleración por hardware donde aplica (HSMs PQC-ready, instrucciones vectoriales modernas).

Dependencias de terceros: el eslabón débil

Aunque su organización migre completamente a PQC, su exposición real depende de la criptografía usada por cada proveedor, cada API externa, cada CDN, cada CA. Una organización con TLS PQC interno pero que se conecta a procesadores de pago, APIs de partners y servicios SaaS con TLS clásico no ha eliminado su exposición; la ha movido.

El programa de migración serio incluye un componente de gestión de proveedores: encuestar a vendors críticos sobre su roadmap PQC, incluir cláusulas de crypto-agility en contratos nuevos, monitorizar continuamente qué algoritmos negocian las conexiones externas y priorizar la migración de los vendors más expuestos (procesadores financieros, identity providers, sistemas de comunicación segura).

Los proveedores grandes (AWS, Google, Microsoft, Cloudflare) están bien posicionados y migrarán transparentemente. Los proveedores pequeños y especializados son donde se concentra el riesgo de quedar varado en criptografía clásica más allá del timeline organizacional. El inventario de proveedores con exposición PQC es tan importante como el inventario interno.

Cuándo aplica este marco, cuándo no

Cuándo aplica: organizaciones que manejan datos con horizonte de confidencialidad mayor a cinco años (salud, financiero, defensa, propiedad intelectual estratégica); proveedores federales o de infraestructura crítica con timelines regulatorios; cualquier organización con PKI propia, code signing significativo o sistemas embedded en producción de larga duración.

Cuándo no aplica con urgencia: aplicaciones donde el horizonte de confidencialidad es menor a dos años (los datos pierden valor antes de que la amenaza cuántica madure); sistemas que dependen exclusivamente de proveedores cloud cuyos servicios gestionados (KMS, ALB, CloudFront) habilitarán PQC transparentemente. En estos casos, la prioridad es asegurarse de estar en versiones de servicio que reciben PQC automáticamente, no construir migración propia.

La migración PQC es la mayor transición criptográfica desde la adopción de TLS. Las organizaciones que la tratan como un proyecto único (“migremos a Kyber en 2029”) la van a fallar. Las que la tratan como una inversión en crypto-agility (“construyamos la capacidad de cambiar de algoritmo en general”) van a sobrevivir a esta transición y a la siguiente sin reescribir todo otra vez.