Kubernetes Archives - Alexandre Vazquez

OpenSearch, Loki, Quickwit y ClickHouse: ¿Qué plataforma elegir para logs y observabilidad en 2026?

2026-07-23 por

La gestión de logs y la observabilidad han dejado de ser un problema de «guardar texto y buscarlo rápido». En 2026, el reto real es económico y arquitectónico: ingerir volúmenes crecientes, retener datos durante meses, correlacionar logs con métricas y trazas, y responder durante un incidente sin que el coste se dispare.

Durante años, Elasticsearch fue la opción dominante. Después llegaron OpenSearch, Loki, Quickwit y, con mucha fuerza, ClickHouse como backend analítico. Todas pueden resolver una parte del problema, pero no optimizan para lo mismo. La decisión senior no debería ser «cuál es más rápido» en abstracto, sino qué preguntas hará el equipo, qué retención necesita y cuánta complejidad puede operar.

El estándar histórico: Elasticsearch y OpenSearch

OpenSearch nace como fork open source de Elasticsearch y conserva el modelo mental más familiar para muchos equipos: índices, shards, réplicas, mappings, Query DSL, agregaciones y una experiencia full-text madura. Si tu organización ya viene de Elasticsearch, es la transición más directa.

Arquitectónicamente se apoya en Apache Lucene. Cada índice se divide en shards; cada shard mantiene segmentos e índices invertidos; el clúster coordina escrituras, réplicas, búsquedas distribuidas y agregaciones. Esto da mucha potencia, pero también una huella operativa clara: JVM, heap sizing, merges, tiers hot/warm/cold y tuning de mappings.

En logs, OpenSearch brilla cuando necesitas búsquedas textuales expresivas, filtros ricos, agregaciones, dashboards maduros, tooling existente o casos cercanos a SIEM. El coste aparece cuando el volumen crece: indexar mucho contenido permite buscar rápido, pero consume almacenamiento y memoria.

En 2026 hay que tener en cuenta además la rama 3.x. OpenSearch 3.0 introdujo cambios relevantes como Lucene 10 y JVM 21, además de mejoras de rendimiento y funcionalidades de búsqueda vectorial. Es una señal de vitalidad del proyecto, pero también exige planificar upgrades con más cuidado que en un stack puramente stateless.

Loki: observabilidad centrada en eficiencia

Grafana Loki adopta una filosofía distinta: no indexar el contenido completo de los logs, sino las etiquetas. En la práctica se parece más a «Prometheus para logs» que a Elasticsearch: consultas por labels y filtros posteriores sobre las líneas con LogQL.

Su almacenamiento se basa en chunks comprimidos y un índice pequeño. Los chunks suelen vivir en object storage como S3, GCS, Azure Blob o MinIO, mientras el índice apunta a streams definidos por combinaciones de labels. Esa decisión reduce coste, pero traslada responsabilidad al diseño de etiquetas.

La regla práctica es simple: las labels deben tener cardinalidad controlada. cluster, namespace, app, environment o service suelen funcionar bien. request_id, user_id o trace_id como label pueden destruir el modelo porque multiplican streams, empeoran la compactación y hacen crecer el índice. Para esos valores es mejor filtrar en el contenido del log o apoyarse en trazas.

Loki brilla en Kubernetes porque el modelo de labels encaja con pods, namespaces y servicios. Además, su integración con Grafana es excelente: exploración de logs, saltos desde métricas, alertas con LogQL y correlación con Tempo o Prometheus.

Su debilidad aparece cuando quieres tratar los logs como un corpus de búsqueda arbitraria. Una consulta «búscame este fragmento en todos los logs de seis meses» puede ser mucho más cara que en un sistema con índice full-text. Loki está diseñado para consultas acotadas por labels y tiempo, no para reemplazar un motor de búsqueda general.

En 2026 Loki sigue muy activo. La documentación oficial lista versiones 3.x recientes, incluida la rama 3.7, y Grafana sigue posicionándolo como un sistema de agregación de logs horizontal, altamente disponible y eficiente en costes. La adquisición de Logline por Grafana refuerza además el foco en búsquedas difíciles dentro de logs, aunque no cambia el principio central: el diseño de labels sigue siendo crítico.

Cuándo brilla Loki

Loki es la elección pragmática para equipos Kubernetes que ya viven en Grafana, necesitan retener volumen a bajo coste y consultan por servicio, namespace, cluster, entorno y ventana temporal. Es menos convincente para búsqueda full-text global o análisis forense profundo.

Quickwit: búsqueda cloud-native sobre object storage

Quickwit es una plataforma de búsqueda distribuida en Rust, pensada para cargas append-only como logs y trazas. Su tesis es atractiva: mantener búsqueda potente, pero desacoplar cómputo y almacenamiento usando object storage como capa principal.

En lugar de depender de discos locales calientes, Quickwit escribe índices y splits en almacenamiento compatible con S3, Azure Blob, Google Cloud Storage o MinIO. Los indexers procesan datos, los searchers consultan segmentos y el metastore coordina el estado. El modelo usa índices invertidos optimizados para datos inmutables y almacenamiento remoto: más cercano a OpenSearch en búsqueda que Loki, pero con economía cloud-native.

Quickwit es especialmente interesante para equipos que quieren sustituir parte de un clúster Elasticsearch/OpenSearch caro, tienen logs en S3 o pueden moverlos allí, y necesitan búsquedas textuales con mejor coste operativo. También tiene integración con Grafana y APIs compatibles parcialmente con Elasticsearch/OpenSearch, lo que facilita algunos flujos existentes.

El matiz crítico para 2026 es su estado de proyecto. Datadog adquirió Quickwit en 2024. La adquisición no significó que el repositorio open source desapareciera: el repositorio quickwit-oss/quickwit sigue público y muestra actividad reciente, incluidas etiquetas y discusiones de 2026. También el plugin de Grafana de Quickwit publica compatibilidad reciente con Grafana 12.1+ y 13. Dicho eso, el riesgo de producto es distinto al de Loki u OpenSearch: la dirección estratégica está influida por Datadog y parte del esfuerzo puede orientarse a casos internos o comerciales.

La lectura honesta es esta: Quickwit no debe descartarse por estar «muerto», porque no está archivado según las fuentes revisadas. Pero sí conviene evaluarlo con más diligencia: cadencia de releases, issues críticos, roadmap, compatibilidad real de APIs, facilidad de operación y dependencia del equipo mantenedor. Para una plataforma core de observabilidad, esa evaluación pesa tanto como el benchmark.

ClickHouse: el motor analítico de la nueva observabilidad

ClickHouse nació como base de datos analítica columnar, no como plataforma de logs. Precisamente por eso se ha vuelto relevante para observabilidad. Muchos incidentes no se resuelven buscando una cadena exacta, sino agrupando por servicio, calculando percentiles, explorando cardinalidades, cruzando logs con trazas y consultando billones de eventos por rango temporal.

El modelo de ClickHouse es columnar. Los datos se almacenan por columnas, se comprimen muy bien y se consultan con ejecución vectorizada, índices primarios ordenados, data skipping indexes y motores como MergeTree. Para observabilidad, esto permite almacenar eventos anchos y leer solo las columnas necesarias.

La contrapartida es que ClickHouse no es Elasticsearch. La búsqueda full-text existe y ha mejorado, pero el punto fuerte sigue siendo el análisis estructurado y semiestructurado. Si tus consultas son «dame todos los errores 500 por versión, región y endpoint en los últimos 15 minutos», ClickHouse encaja muy bien. Si tu consulta principal es «encuentra cualquier línea que contenga una frase rara en seis meses de texto no estructurado», probablemente quieras otro componente o una estrategia híbrida.

ClickHouse se ha movido con decisión hacia observabilidad. La adquisición de HyperDX y el lanzamiento de ClickStack cambian el posicionamiento: ya no es solo «usa ClickHouse como backend y construye tú la UI», sino una pila con OpenTelemetry, HyperDX como interfaz y ClickHouse como motor. Brilla en plataformas de alto volumen, logs estructurados, trazas, métricas derivadas y consultas agregadas de baja latencia, aunque exige entender modelado, TTLs, compresión y costes de ingestión.

Comparativa rápida

Característica	OpenSearch	Loki	Quickwit	ClickHouse
Modelo principal	Búsqueda distribuida sobre Lucene	Logs por streams y labels	Búsqueda distribuida cloud-native	Base analítica columnar
Modelo de almacenamiento	Shards, segmentos Lucene, tiers hot/warm/cold	Chunks comprimidos + índice pequeño	Índices/splits en object storage	Columnas comprimidas en MergeTree
Índice	Invertido, muy completo	Labels, no contenido completo	Invertido optimizado para object storage	Índice primario, data skipping, columnas
Full-text search	Excelente	Limitada y dependiente de filtros	Muy buena	Buena, no su principal fortaleza
Coste relativo	Alto	Bajo	Bajo-medio	Bajo-medio
Latencia de query	Baja en índices calientes bien dimensionados	Baja si acotas por labels; peor en barridos amplios	Baja-media según caché y object storage	Muy baja en agregaciones bien modeladas
Escalado	Maduro, pero operativo	Horizontal y económico	Desacopla cómputo y almacenamiento	Excelente en analítica e ingestión
Kubernetes	Bueno	Excelente	Bueno	Bueno, mejor con ClickStack/OTel
Grafana	Sí	Nativo	Sí	Sí
Compatibilidad Elasticsearch	Alta en OpenSearch	No	Parcial	No
Mejor caso de uso	Búsqueda compleja y compatibilidad	Logs Kubernetes de bajo coste	Búsqueda eficiente sobre S3	Observabilidad analítica unificada
Riesgo principal	Coste y complejidad	Cardinalidad de labels	Ecosistema y gobernanza tras adquisición	Modelado y curva SQL/operación

¿Cuál elegir en 2026?

La respuesta depende menos de la moda tecnológica y más del perfil del equipo.

Si eres un equipo de plataforma con herencia Elasticsearch

OpenSearch es la opción conservadora si ya tienes automatizaciones, alertas y conocimiento operacional alrededor de Elasticsearch/OpenSearch. No migres «tal cual» esperando que el coste baje: revisa mappings, retención, ILM/ISM, shards, campos indexados y separación entre datos calientes y archivo.

Si eres un equipo Kubernetes centrado en Grafana

Loki suele ser la primera opción. Es eficiente, se integra muy bien con Grafana y reduce el coste de logs operativos. La clave es gobernar labels desde el día uno: taxonomía permitida, límites de cardinalidad y consultas por contexto antes de buscar texto.

Si buscas reducir coste frente a OpenSearch sin perder búsqueda

Quickwit merece una PoC seria cuando Loki se queda corto en búsqueda y OpenSearch resulta caro. La decisión debe incluir continuidad: actividad del repositorio, releases, clientes, soporte comunitario, integración con Grafana y posición de Datadog.

Si quieres una plataforma unificada de observabilidad

ClickHouse es probablemente la apuesta más fuerte para consolidar logs, trazas, métricas derivadas y eventos en una base analítica común. ClickStack e HyperDX reducen la necesidad de construir toda la experiencia desde cero, pero la adopción depende de madurez en SQL, modelado y operación de bases analíticas.

Si tienes requisitos de seguridad, auditoría o SIEM

OpenSearch sigue siendo más natural para investigación textual y tooling de seguridad. ClickHouse puede funcionar para analítica de seguridad a escala, pero exige modelado. Loki rara vez es la primera opción para SIEM. Quickwit puede ser interesante, con ecosistema más pequeño.

Si el presupuesto es el cuello de botella

No elijas solo por coste de almacenamiento por TB. Calcula coste total: ingestión, consultas, retención, operación, backups, upgrades, formación y tiempo de incidente. Loki y ClickHouse suelen ganar en coste bruto; Quickwit puede ser muy competitivo sobre object storage; OpenSearch puede ser razonable si se limita a datos realmente buscables y calientes.

Cómo plantear una PoC de decisión

Una prueba útil no consiste en instalar cuatro Helm charts y mirar una demo. Define preguntas reales de incidentes pasados y ejecútalas sobre datos representativos:

Últimos 7 días de logs de producción, con cardinalidad real.
Una ventana caliente de 2 horas con alto volumen.
Una búsqueda textual rara sobre un periodo amplio.
Una agregación por servicio, endpoint, versión y región.
Un flujo de correlación desde alerta a logs y trazas.

Mide ingestión sostenida, coste de almacenamiento, latencia p50/p95, complejidad de operación y experiencia del equipo. Incluye un escenario incómodo: nodo caído, object storage lento, cardinalidad inesperada o consulta mal escrita.

Conclusión

La era en la que Elasticsearch era la única opción viable para logs terminó. En 2026 hay cuatro caminos claros.

OpenSearch es la elección madura para búsqueda full-text y compatibilidad. Loki es eficiente para logs operativos en Kubernetes. Quickwit ofrece búsqueda moderna sobre object storage, con evaluación de gobernanza obligatoria tras la adquisición por Datadog. ClickHouse se consolida como motor analítico para observabilidad unificada, especialmente con ClickStack e HyperDX.

La mejor plataforma no es la que gana todos los benchmarks. Es la que responde a tus preguntas de producción con el menor coste sostenible y la menor fricción operativa para tu equipo.

CTA: decide con datos, no con preferencias

Antes de migrar o estandarizar, ejecuta una PoC de dos semanas con datos reales, consultas reales y una estimación honesta de coste total. Debe revelar qué datos van a búsqueda, cuáles a analítica y cuáles a almacenamiento barato.

Fuentes

OpenSearch 3.0: https://opensearch.org/blog/unveiling-opensearch-3-0/
OpenSearch 3.0, Lucene 10 y JVM 21: https://opensearch.org/blog/opensearch-3-0-what-to-expect/
Grafana Loki, documentación: https://grafana.com/docs/loki/latest/
Grafana Loki, releases 3.x: https://grafana.com/docs/loki/latest/release-notes/
Grafana Loki, labels y cardinalidad: https://grafana.com/blog/how-labels-in-loki-can-make-log-queries-faster-and-easier/
Datadog adquiere Quickwit: https://www.datadoghq.com/blog/datadog-acquires-quickwit/
Quickwit OSS: https://github.com/quickwit-oss/quickwit
Quickwit datasource para Grafana: https://github.com/quickwit-oss/quickwit-datasource
ClickStack: https://clickhouse.com/clickstack
ClickStack/HyperDX en ClickHouse Cloud: https://clickhouse.com/docs/use-cases/observability/clickstack/overview
ClickHouse adquiere HyperDX: https://clickhouse.com/blog/202504-newsletter
ClickHouse y observabilidad 2026: https://clickhouse.com/resources/engineering/what-is-observability

Construyendo un Framework de Migración para Kubernetes: Lecciones de Ingress-NGINX

2026-02-16 por Alexandre Vazquez

Si gestionas infraestructura Kubernetes en producción, el anuncio de la depreciación de Ingress-NGINX no fue una sorpresa, sino un recordatorio crudo de la realidad del ecosistema: la obsolescencia es una constante. Lo que hoy es un componente crítico, mañana puede ser un legacy que amenaza la estabilidad y seguridad de tu plataforma.

La depreciación de Ingress-NGINX, un controlador que ha sido la columna vertebral del tráfico entrante para miles de clusters, no es un evento aislado. Es un patrón que se repetirá con otros componentes a medida que Kubernetes evoluciona. La pregunta crítica para los equipos de plataforma no es «¿cómo migramos este componente?», sino «¿cómo construimos un marco de trabajo reutilizable para gestionar estas migraciones de forma sistemática, segura y con mínima interrupción?».

En este artículo, no solo analizaremos las lecciones específicas de Ingress-NGINX, sino que las abstraeremos en un framework de migración para Kubernetes que tu equipo puede aplicar a cualquier cambio mayor: desde la transición a Gateway API, hasta la migración de CNIs, cambios de versión de control-plane, o la adopción de nuevos CRDs. Este framework está diseñado para ingenieros senior, arquitectos y SREs que necesitan un enfoque práctico y metódico para el cambio en entornos empresariales.

Por qué necesitas un framework, no solo un plan ad-hoc

Migrar un componente como el controlador de ingress en un cluster de producción es una operación de alto riesgo. Impacta el tráfico de red, la seguridad (TLS), la observabilidad y, en última instancia, la disponibilidad de tus aplicaciones. Un enfoque ad-hoc, basado en scripts sueltos y manuales, introduce puntos de fallo, hace imposible la validación consistente y dificulta el rollback en caso de problemas.

Un framework proporciona:

Consistencia: El mismo proceso para diferentes migraciones.
Visibilidad: Estado claro en cada fase.
Automatización: Reducción de errores humanos.
Seguridad: Puntos de validación y compuertas (gates) definidos.
Reversibilidad: Un camino claro para deshacer los cambios.

La documentación oficial de Kubernetes sobre gestión de despliegues enfatiza estrategias como el despliegue gradual y el rollback, principios que son la base de nuestro framework.

Fase 1: Evaluación y Análisis de Impacto

Antes de escribir una línea de código o un manifiesto YAML, debes entender completamente el alcance. Esta fase responde a la pregunta: «¿Qué estamos tocando y qué puede romperse?».

1.1. Inventario de Recursos y Dependencias

Para una migración de ingress, no solo son los objetos Ingress. Debes catalogar:

Recursos Directos: Todos los objetos Ingress en todos los namespaces, con sus anotaciones específicas (nginx.ingress.kubernetes.io/*).
Configuración Global: ConfigMaps que contienen la configuración del controlador (e.g., nginx-configuration).
Dependencias de Infraestructura: Services de tipo LoadBalancer, certificados TLS (manejados por cert-manager o similares), políticas de red (NetworkPolicies).
Integraciones de Observabilidad: Dashboards de Grafana, alertas de Prometheus, logs estructurados que dependen de etiquetas específicas de NGINX.

Un comando inicial como kubectl get ingress -A es el punto de partida, pero se necesita un análisis más profundo para capturar anotaciones personalizadas y configuraciones complejas.

1.2. Análisis de Brechas (Gap Analysis)

Compara las capacidades del componente antiguo con las del nuevo. En el caso de migrar de Ingress-NGINX a Gateway API (usando, por ejemplo, un controlador como Gateway API con Envoy o NGINX Kubernetes Gateway), identifica:

Funcionalidades equivalentes: ¿El nuevo componente soporta rewrite rules, auth annotations, canary deployments de la misma forma?
Paradigmas diferentes: Gateway API separa los roles (Infraestructura vs. Aplicación) mediante GatewayClass, Gateway, y HTTPRoute. Esto es un cambio arquitectónico, no solo una sustitución.
Características no soportadas: Algunas anotaciones muy específicas de NGINX pueden no tener un equivalente directo y requerir una solución alternativa.

Este análisis te permitirá categorizar los recursos: aquellos con una migración trivial, aquellos que requieren reconfiguración, y aquellos que pueden ser un bloqueador (show-stopper).

Fase 2: Diseño y Estrategia de Despliegue

Con el alcance definido, diseñamos el cómo. La clave aquí es la coexistencia pacífica y el despliegue incremental.

2.1. Patrón de Despliegue Dual (Dual-Homing)

El patrón más seguro para migrar tráfico de red es ejecutar ambos controladores (el antiguo y el nuevo) en paralelo. Esto permite:

Migración por servicio/dominio: Enrutar el tráfico de un host específico (app1.example.com) al nuevo controlador, mientras el resto sigue por el antiguo.
Pruebas en producción con tráfico real controlado: Usar un subconjunto de usuarios (por ejemplo, mediante un header HTTP) para enviar tráfico al nuevo ingress.
Rollback instantáneo: Basta con reconfigurar el DNS o el balanceador de capa 4 para volver al controlador antiguo.

Como señala el framework de Google para esta migración, esta fase requiere una cuidadosa planificación de la IP del balanceador de carga y la gestión de DNS.

2.2. Automatización de la Conversión de Manifiestos

Convertir manualmente cientos de objetos Ingress es inviable y propenso a errores. Debes crear o utilizar herramientas de conversión. El objetivo no es una conversión 1:1 perfecta (el análisis de brechas ya habrá identificado diferencias), sino generar un artefacto base que luego será revisado y ajustado.

Un script simple en Python o Go puede leer los objetos Ingress existentes y generar los correspondientes HTTPRoute y referencias a Gateway. Este es un ejemplo conceptual de la lógica:

# Pseudocódigo para ilustrar el flujo de conversión
ingress_resources = kubectl_get_all_ingresses()
for ingress in ingress_resources:
    http_route = HTTPRoute()
    http_route.metadata.name = ingress.metadata.name
    http_route.metadata.namespace = ingress.metadata.namespace
    
    for rule in ingress.spec.rules:
        host_rule = HTTPRouteRule()
        host_rule.hostnames = [rule.host]
        # Mapear paths y backends...
        # **Aquí se aplicarían las reglas del Gap Analysis**
        http_route.spec.rules.append(host_rule)
    
    # Gestionar TLS: mapeo a Gateway, no a Secret en HTTPRoute
    if ingress.spec.tls:
        # Nota: En Gateway API, TLS se configura en el recurso Gateway.
        # Esto requiere una estrategia de agrupación por host/Secret.
        pass

La salida de esta automatización debe ser revisada por un ingeniero para los casos complejos antes de aplicarse al cluster.

Fase 3: Implementación y Validación Gradual

Esta es la fase de ejecución, donde el framework impone compuertas (gates) de validación entre cada paso.

3.1. Fase 1: Despliegue del Nuevo Controlador en Modo Pasivo

Instala el nuevo controlador (ej: un operator de Gateway API) pero no lo expongas al tráfico de producción. Configúralo para que escuche en un Service interno o en una IP de LoadBalancer diferente. Valida:

Los pods del controlador están Ready.
Los CRDs necesarios están instalados.
Puedes crear recursos de prueba (HTTPRoute) y el controlador los sincroniza (revisa los logs o el estado del recurso).

3.2. Fase 2: Migración de un Servicio No Crítico (Piloto)

Selecciona un servicio de bajo riesgo, preferiblemente interno o con poco tráfico. Aplica los manifiestos convertidos y configura el DNS o el balanceador de capa 4 para enviar el tráfico de ese host específico al nuevo controlador.

Validaciones post-migración (Checklist):

Conectividad básica: ¿Responde el servicio con un código 2xx/3xx?
Funcionalidad específica: ¿Funcionan las reglas de rewrite, redirecciones, autenticación?
TLS: ¿Los certificados se presentan correctamente? ¿La cadena de confianza es válida?
Observabilidad: ¿Aparecen logs en el nuevo formato? ¿Las métricas (peticiones/segundo, latencia) se exponen a Prometheus?
Prueba de rollback: Vuelve a enrutar el tráfico al controlador antiguo y confirma que todo sigue funcionando.

3.3. Fase 3: Expansión y Automatización del Pipeline

Tras el éxito del piloto, migra grupos de servicios siguiendo un criterio (por namespace, por equipo dueño, por criticidad). Idealmente, integra este proceso en tu pipeline de GitOps:

El ingeniero modifica la ruta (Kustomize overlay, Helm value) para apuntar al nuevo Gateway.
El cambio se fusiona (merge) y es aplicado por el operador GitOps (ArgoCD, Flux).
Un job de validación post-despliegue ejecuta smoke tests contra el servicio.
Una alerta monitoriza el error rate del servicio migrado; si supera un umbral, puede disparar un rollback automático.

Fase 4: Rollback y Lecciones Aprendidas

Un framework de migración robusto trata el rollback no como un fracaso, sino como una característica esencial del proceso.

4.1. Estrategias de Rollback Granular

Debes poder revertir a diferentes niveles:

Rollback por servicio: Reconfigurar el enrutamiento de un host específico al controlador antiguo.
Rollback masivo: Tener un script o playbook listo para reenrutar todo el tráfico al controlador antiguo en minutos. Esto implica mantener el controlador antiguo operativo y con capacidad suficiente hasta el final de la ventana de migración.
Rollback de configuración: Si el problema está en un manifiesto HTTPRoute erróneo, debes poder revertir el commit en Git y dejar que GitOps sincronice el estado anterior.

4.2. Documentación y Conclusión

Una vez completada la migración (o incluso después de cada fase), documenta:

Problemas encontrados y su solución: Este es el conocimiento tribal más valioso.
Métricas de éxito: Tiempo total, tasa de error durante la migración, recursos consumidos.
Mejoras para el framework: ¿Faltó un punto de validación? ¿Podría automatizarse más un paso?

Esta documentación no es un reporte para la gerencia; es la entrada para refinar el framework y prepararlo para la próxima migración inevitable.

Conclusión: Más allá de Ingress-NGINX

La depreciación de Ingress-NGINX es un caso de estudio perfecto, pero el framework descrito aquí es aplicable a cualquier cambio disruptivo en tu plataforma Kubernetes: la migración a un nuevo CNI, el cambio de una versión mayor del control-plane con APIs obsoletas, la adopción de un nuevo modelo de service mesh, o la consolidación de múltiples clusters.

La constante en Kubernetes es el cambio. La ventaja competitiva de un equipo de plataforma no reside en conocer el componente de moda, sino en poseer un proceso sistemático, automatizado y seguro para adoptar, operar y eventualmente retirar cualquier componente. Invertir en construir y refinar este framework de migración es invertir en la resiliencia y velocidad a largo plazo de tu plataforma. La próxima depreciación importante no será una crisis, sino solo otra ejecución en el playbook de tu equipo.

Helm 4.0 explicado: novedades clave, cambios importantes y cómo prepararte para la migración

2026-01-262025-11-23 por Alexandre Vazquez

Helm es uno de las principales utilidades dentro del ecosistema de Kubernetes y por tanto la release de una nueva version major, como es Helm 4.0 es algo a tener en consideración porqué sin dudas es algo que se va a tener que analizar, valorar y gestionar en los próximos meses.

Debido a eso, veremos muchos comentarios y artículos alrededor de este tema, por lo que vamos a intentar mostrar algo de luz.

Principales novedades de Helm 4.0

Según el propio proyecto en su anuncio, Helm 4 introduce tres grandes bloques de cambios: nuevo sistema de plugins, mejor integración con Kubernetes ** y modernización interna de SDK y rendimiento**.

Nuevo sistema de plugins (incluye WebAssembly)

Se ha rediseñado por completo del sistema de plugins, haciendo un enfoque especial en la seguridad mediante la introducción de un nuevo runtime WebAssembly que si bien es opcional, es recomendado dado que se ejecutan en un modo «sandbox» que ofrece limites y garantías desde el punto de vista de la seguridad

De todos modos, no hay que preocuparse en exceso, ya que los plugins “clásicos” siguen funcionando, pero el mensaje es claro: para seguridad y extensibilidad, la dirección es Wasm.

Server-Side Apply y mejor integración con otros controladores

Desde esta versión Helm 4 a través del flag --server-side se soporta Server-Side Apply (SSA) que ya se ha convertido en estable desde la versión v1.22 de Kubernetes y permite llevar al lado del servidor las actualizaciones sobre los objetos para evitar conflictos entre diferentes controladores que gestionan los mismos recursos.

También incorporar integración con kstatus para asegurar el estado de un componente de na una manera más fiable que lo que ocurre actualmente con el uso del parámetro --wait

Otras Mejoras Adicionales

Adicionalmente hay otro listado de mejores que siendo de menor calado son saltos cualitativos de importancia como puede ser los siguiente:

Instalación por digest en registries OCI: (helm install myapp oci://...@sha256:<digest>)
Valores multi-document: puedes pasar varios YAML de values en un único fichero multi-doc, facilitando entornos / overlays complejos.
Nuevo argumento --set-json que permite de una manera sencilla pasar estructuras complejas comparado con la solución actual mediante uso del parámetro --set

¿Por qué una major (v4) y no otra minor de la 3.x?

Tal y como explican en la entrada oficial de lanzamiento había features que el equipo no podía introducir en v3 sin romper APIs públicas del SDK y arquitectura interna:

Cambio fuerte en el sistema de plugins (WebAssembly, nuevos tipos, integración profunda con el core).
Reestructuración de paquetes Go y establecimiento de un SDK estable en helm.sh/helm/v4, incompatible a nivel de código con v3.
Introducción y futura evolución de Charts v3, que requieren que el SDK soporte múltiples versiones de API de charts.

Con todo esto, seguir en la rama 3.x habría violado SemVer: el cambio de número mayor está básicamente “pagando” la deuda técnica acumulada para poder avanzar.

Adicionalmente se espera en el futuro una nueva evolución de las charts, pasando de una v2 a una futura v3 que aun no esta completamente definida y actualmente las charts v2 se ejecutan correctamente en esta nueva versión.

¿Tengo que migrar a esta nueva versión?

La respuesta corta es: si. Y posiblemente la respuesta larga sea: sí, y rápido. En el anuncio oficial de Helm 4 especifican el calendario de soporte de Helm 3:

Bugfixes de Helm 3 hasta el 8 de julio de 2026.
Security fixes de Helm 3 hasta el 11 de noviembre de 2026.
No se backportearán nuevas features a Helm 3 durante ese periodo; únicamente se actualizarán librerías de cliente de Kubernetes para soportar nuevas versiones de K8s.

Traducción práctica:

Tienes ~1 año para planificar migración tranquila a Helm 4 con soporte de bugs.
Después de noviembre de 2026, seguir usando Helm 3 será cada vez más arriesgado desde el punto de vista de seguridad y compatibilidad.

Buenas prácticas para migración

Para realizar la migración hay que recordar que es perfectamente posible y factible tener instaladas ambas versiones en un misma máquina o agente, por lo que se puede hacer una migración «paulatina» para asegurar que se llega al final del soporte de la versión v3 con todo migrado correctamente, y para eso se recomiendan lo siguientes pasos:

Realizar un análisis de todos los comandos y uso de Helm tanto desde el punto de vista de pipelines de integración, scripts de upgrade o incluso la importación de librerías cliente de helm en desarrollos basados en Helm.
Especialmente revisar con cautela todos los usos de --post-renderer, helm registry login, --atomic, --force.
Posteriormente al análisis empezar a probar Helm 4 primero en entornos no productivos, reutilizando los mismos charts y values, revirtiendo a Helm 3 en caso de que se detecte un problema hasta que este sea sub
Si tienes plugins críticos, probarlos explícitamente con Helm 4 antes de hacer el cambio global.

Problemas con los Ingress en Kubernetes: limitaciones reales y por qué Gateway API es el futuro

2026-02-202025-11-23 por Alexandre Vazquez

Introducción

Los Ingress han sido, desde las primeras versiones de Kubernetes, la forma más habitual de exponer aplicaciones al exterior. Aunque su diseño inicial era sencillo y elegante, el éxito de Kubernetes y la creciente complejidad de los casos de uso han convertido al Ingress en una pieza problemática: limitado, inconsistente entre vendors y difícil de gobernar en entornos empresariales.

En este artículo analizamos por qué los Ingress se han convertido en una fuente constante de fricción, cómo han influido los distintos Ingress Controllers en esta situación y por qué cada vez más organizaciones están considerando alternativas como Gateway API.

Qué son los Ingress y por qué fueron diseñados así

El ecosistema de Ingress gira en torno a dos recursos principales:

🏷️ IngressClass

Define qué controlador gestionará los Ingress asociados. Su alcance es global al clúster, por lo que suele ser administrado por el equipo de plataforma.

🌐 Ingress

Es el recurso que los desarrolladores usan para exponer un servicio. Permite definir rutas, dominios, certificados TLS y poco más.

Su especificación es mínima por diseño, lo que permitió una adopción rápida, pero también sembró las bases de los problemas actuales.

El problema: un estándar demasiado simple para necesidades complejas

A medida que Kubernetes se convirtió en estándar empresarial, los usuarios querían replicar configuraciones avanzadas de proxies tradicionales: re-escrituras, timeouts, cabeceras personalizadas, CORS, etc.
Pero Ingress no daba soporte nativo a todo esto.

Los vendors reaccionaron… y ahí nació el caos.

Anotaciones vs CRDs: dos caminos incompatibles

Los distintos Ingress Controllers han tomado caminos muy diferentes para añadir capacidades avanzadas:

📝 Anotaciones (NGINX, HAProxy…)

Ventajas:

Flexibles y fáciles de usar
Directamente en el recurso Ingress

Desventajas:

Cientos de anotaciones propietarias
Documentación fragmentada
Configuraciones no portables entre vendors

📦 CRDs personalizados (Traefik, Kong…)

Ventajas:

Más estructurado y potente
Mejor validación y control

Desventajas:

Añade nuevos objetos no estándar
Requiere instalarlos y gestionarlos
Menor interoperabilidad

¿Resultado?
Infraestructuras profundamente acopladas a un vendor, lo que complica migraciones, auditorías y automatización.

La complejidad para los equipos de desarrollo

El diseño de Ingress implica dos responsabilidades muy diferenciadas:

Plataforma: define IngressClass
Aplicación: define Ingress

Pero la realidad es que el desarrollador acaba tomando decisiones que deberían ser responsabilidad del área de plataforma:

Certificados
Políticas de seguridad
Reglas de reescritura
CORS
Timeouts
Prácticas corporativas de naming

Esto provoca:

Configuraciones inconsistentes
Cuellos de botella en revisiones
Dependencia constante entre equipos
Falta de estandarización efectiva

En empresas grandes, donde la seguridad y la gobernanza son críticas, esto es especialmente problemático.

NGINX Ingress: la descomisión que reavivó el debate

La reciente descontinuación del NGINX Ingress Controller ha puesto en evidencia lo frágil del ecosistema:

Miles de clústeres dependen de él
Múltiples proyectos usan sus anotaciones
Migrar implica reescribir configuraciones enteras

Esto ha reactivado la conversación sobre la necesidad de un estándar real… y ahí aparece Gateway API.

Gateway API: una alternativa prometedora (pero no perfecta)

Gateway API nace para resolver muchas de las limitaciones de Ingress:

Separación clara entre responsabilidades (infraestructura vs aplicación)
Extensibilidad estandarizada
Más tipos de rutas (HTTPRoute, TCPRoute…)
Mayor expresividad sin depender de anotaciones propietarias

Pero también trae desafíos:

Requiere adopción gradual
No todos los vendors implementan lo mismo
La migración no es trivial

Aun así, se perfila como el futuro de la gestión de tráfico en Kubernetes.

Conclusión

Los Ingress han sido fundamentales para el éxito de Kubernetes, pero su propia simplicidad los ha llevado a convertirse en un cuello de botella. La falta de interoperabilidad, las diferencias entre vendors y la compleja gobernanza en entornos empresariales hacen evidente que es momento de adoptar modelos más maduros.

Gateway API no es perfecto, pero avanza en la dirección correcta.
Las organizaciones que quieran estabilidad a futuro deberían empezar a planificar su transición.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.