El 23 de junio de 2026, Buoyant anunció Linkerd 2.20 y el titular no fue una feature nueva sino un número incómodo de ignorar: hasta 85% menos memoria en el control plane. En un mundo donde cada gigabyte de RAM reservado se paga, que un service mesh adelgace su propio overhead es exactamente el tipo de noticia que un equipo de plataforma necesita. Te contamos qué cambió por dentro, por qué el ahorro es real y qué podés hacer con esto hoy.
Linkerd es un service mesh open source, graduado en la CNCF, que agrega mTLS, balanceo de carga y métricas a las comunicaciones entre servicios en Kubernetes sin tocar el código de tus aplicaciones. Su versión 2.20, publicada el 23 de junio de 2026, recorta hasta un 85% la memoria del control plane al refactorizar el destination controller, el componente que descubre endpoints y distribuye el estado del cluster a los proxies del data plane.
¿Qué es el control plane de un service mesh y por qué consume RAM?
Un service mesh divide su trabajo en dos planos. El data plane son los proxies que se inyectan junto a cada pod (en Linkerd, un micro-proxy escrito en Rust) y que interceptan el tráfico real entre servicios. El control plane es el cerebro: les dice a esos proxies a quién pueden hablarle, con qué identidad mTLS y hacia qué endpoints enrutar.
Dentro del control plane, el linkerd-destination es la pieza más exigente con la memoria. Su trabajo es traducir un nombre de servicio en un conjunto de endpoints enriquecidos —con identidad mTLS, zona de disponibilidad y protocolo— y mantener ese mapa actualizado en tiempo real. Para lograrlo:
- Cachea el estado del cluster en memoria. Guarda copias locales de servicios, EndpointSlices y políticas para responder rápido sin golpear la API de Kubernetes en cada consulta.
- Mantiene streams gRPC abiertos con miles de proxies. Cada proxy del data plane se suscribe a cambios; el controller tiene que sostener todas esas conexiones simultáneas.
- Procesa eventos constantemente. Cuando un pod nace o muere, el controller recalcula y empuja la actualización a cada proxy interesado.
El problema aparece con el pod churn: cuando hay despliegues frecuentes o autoescalado agresivo, miles de pods aparecen y desaparecen, y cada cambio se multiplicaba en memoria por la cantidad de proxies que necesitaban enterarse. En clusters grandes, el destination controller podía convertirse en el componente más caro de todo el mesh.
¿Cómo logró Linkerd 2.20 bajar 85% la memoria?
La clave está en cómo el destination controller estructura el estado compartido. Antes, buena parte de la información común a muchos proxies se mantenía de forma redundante. La versión 2.20 trae un destination controller refactorizado que organiza el estado común del cluster de manera compartida, evitando duplicar en memoria lo que en realidad es la misma información para muchos consumidores.
El resultado, según Buoyant, es una reducción de hasta el 85% del consumo de memoria del control plane durante el pod churn intenso, justamente el escenario donde antes más sufría. Y lo importante: ese ahorro se logra sin resignar las garantías de siempre —mTLS, traffic splitting y las golden metrics siguen funcionando igual—. No es un modo "lite" con menos features; es la misma funcionalidad con un costo de RAM mucho menor.
Conviene leer el número con cabeza de ingeniero: es un tope ("hasta 85%") medido en condiciones de alta rotación de pods. Tu mejora real depende del tamaño del cluster, la cantidad de proxies y qué tan seguido desplegás. Pero incluso una fracción de ese ahorro cambia cómo dimensionás los requests y limits del control plane.
¿Qué más trae Linkerd 2.20 además del ahorro de RAM?
El recorte de memoria es el protagonista, pero no viaja solo. La edición open source suma:
- Balanceo de carga con conciencia de rate limit. El enrutamiento ahora detecta cuándo un upstream está saturado y desvía carga hacia targets sanos, en lugar de seguir golpeando al que ya está al límite. Preserva el throughput general bajo presión.
- Mejores métricas de entrada (inbound). Más visibilidad sobre el tráfico que reciben tus servicios, útil para diagnosticar latencia y errores del lado del que responde.
- Kubernetes 1.31 como versión mínima. Esta y las próximas releases requieren al menos 1.31, así que revisá la versión de tu cluster antes de actualizar.
Por separado, Buoyant Enterprise for Linkerd 2.20 —la edición comercial— agrega rotación automática del trust anchor (el ancla de confianza de la PKI del mesh) y soporte para VMs Windows que viven fuera del cluster de Kubernetes. Son funciones pensadas para operaciones grandes; si trabajás con la edición open source, el plato fuerte sigue siendo el ahorro de memoria.
Para ubicar la release en su línea de tiempo: la 2.19 (octubre de 2025) había traído criptografía post-cuántica. La 2.20 cambia el foco de la seguridad criptográfica a la economía operativa del mesh.
¿Qué significa esto para tu cluster en producción?
Si ya corrés Linkerd, el impacto es directo y medible:
- Podés revisar a la baja los limits del control plane. Muchos usuarios sobredimensionaron los
requests/limitsdel destination controller para evitar OOMKills durante despliegues. Con 2.20 esos márgenes se pueden ajustar hacia abajo con un baseline más predecible. - El mesh deja de competir por recursos con tus apps. En un Cloud Server con RAM acotada, cada cientos de MB que el control plane libera quedan disponibles para las cargas que de verdad generan valor.
- Mejor comportamiento bajo escalado. El ahorro se concentra justo en el pod churn, así que los picos de despliegue o de autoescalado dejan de ser el momento de mayor estrés de memoria.
Si todavía no usás un service mesh, esta release baja una de las barreras históricas para adoptarlo: el costo de overhead. El argumento de "no quiero pagar RAM extra para tener mTLS y observabilidad" se debilita cuando el control plane pesa una fracción de lo que pesaba.
¿Cómo lo probás hoy en tu Cloud Server?
Si tenés un cluster de Kubernetes andando, evaluar Linkerd 2.20 es cuestión de un entorno de prueba:
- Verificá la versión de Kubernetes. Necesitás 1.31 o superior. Chequealo con
kubectl version. - Instalá el CLI y validá el cluster. Linkerd trae
linkerd check --prepara confirmar que tu cluster cumple los requisitos antes de instalar nada. - Probalo en staging primero. Instalá el control plane, inyectá el proxy en un namespace de prueba y mirá el consumo real del destination controller con
kubectl top pods -n linkerdantes y después. - Compará contra tu baseline. Si venís de una versión anterior, medí la memoria del control plane bajo un despliegue rodante para ver el ahorro en tu caso concreto, no en el del benchmark.
Para no perderte detalles de la actualización, conviene leer los release notes oficiales y, si querés entender la pieza que cambió, el deep dive del destination controller. La cobertura de Cloud Native Now sobre la 2.20 resume bien el contexto del anuncio.
Si estás armando el cluster desde cero, esta nota se complementa bien con nuestras guías de Kubernetes con kubeadm y containerd, y con la comparativa Docker vs Kubernetes ya publicadas en el blog.
Preguntas frecuentes
¿Cuándo salió Linkerd 2.20?
Buoyant la anunció el 23 de junio de 2026. Es la release que sucede a la 2.19, que había llegado en octubre de 2025 con criptografía post-cuántica.
¿El recorte del 85% de RAM aplica a todo Linkerd o solo al control plane?
Solo al control plane, y dentro de él, principalmente al destination controller. El ahorro se logra al refactorizar cómo ese componente estructura el estado compartido del cluster. El consumo de los proxies del data plane es otra historia.
¿Linkerd es open source o es de pago?
Linkerd es open source y está graduado en la CNCF. El ahorro de memoria, el balanceo con conciencia de rate limit y las nuevas métricas de entrada están en la edición open source. Buoyant Enterprise for Linkerd es la edición comercial, que agrega funciones como la rotación automática del trust anchor y el soporte de VMs Windows.
¿Voy a obtener exactamente 85% menos de RAM si actualizo?
No necesariamente. El 85% es un máximo medido bajo pod churn intenso. Tu ahorro real depende del tamaño del cluster, la cantidad de proxies conectados y la frecuencia de tus despliegues. Medí tu propio baseline antes y después para conocer el número que te toca.
¿Qué versión de Kubernetes necesito para Linkerd 2.20?
La versión mínima soportada es Kubernetes 1.31. Si corrés algo más viejo, vas a tener que actualizar el cluster antes de instalar Linkerd 2.20.
¿Qué es el destination controller que cambió en esta versión?
Es el componente del control plane que resuelve nombres de servicio en conjuntos de endpoints con su identidad mTLS, zona y protocolo, y mantiene esa información sincronizada con cada proxy del mesh. Por su rol de caché y distribución de estado, era el mayor consumidor de memoria del control plane, y es justo lo que la 2.20 optimizó.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
