Cilium 1.18.15 corrige tres fallos de endpoints, ip6tables y backends
La release 1.18.15 corrige un borrado incorrecto de endpoints durante GC, errores de reconciliación de cadenas ip6tables y la restauración de backends que vuelven a estar activos tras un reinicio. También actualiza golang.org/x/net con una etiqueta de seguridad, sin identificar un CVE concreto en esas notas.
Una actualización de CNI puede arreglar bugs muy concretos y aun así ser importante para el funcionamiento del clúster: Cilium 1.18.15 corrige problemas en la recogida de endpoints, la reconciliación de reglas ip6tables y la recuperación de backends terminados. No es un cambio de arquitectura ni una nueva función para Kubernetes, sino un parche de la rama 1.18 que conviene evaluar en los clústeres que ejecutan esa serie.
El primer arreglo afecta a la eliminación de endpoints cuando el garbage collector recorre elementos y se reutiliza el ID de uno que ya había sido recogido. El bug podía hacer que se borrara el endpoint nuevo equivocado. El segundo corrige errores de renombrado de cadenas ip6tables que se ignoraban durante la reconciliación de reglas. Son rutas distintas del datapath de Cilium, pero las dos se manifiestan como estado de red que el agente no conserva o no limpia de la forma esperada.
La tercera corrección es para backends que estaban terminando y vuelven a activarse durante un reinicio: antes podían quedar marcados erróneamente como en cuarentena. En un servicio con varios destinos, eso puede alterar qué backend se considera elegible después de recuperar un componente. Las notas también actualizan golang.org/x/net con una etiqueta de seguridad, aunque no identifican un CVE concreto para esa actualización. No hay base para traducir esa etiqueta automáticamente en una vulnerabilidad explotada ni en un incidente de seguridad en Cilium.
-InfraCrew dice:un endpoint que se borra por error suele manifestarse como “la red va rara”; el parche por fin apunta al objeto concreto.-
Una release de mantenimiento, no un salto de versión mayor
Cilium 1.18.15 pertenece a la serie 1.18. Antes de cambiar clústeres productivos, el equipo debe confirmar qué rama y chart ejecuta, qué opciones personalizadas conserva y qué dependencias de Kubernetes o del kernel aplican a su instalación. Una corrección de parche no significa que todas las instalaciones deban saltar a la versión mayor más nueva, sobre todo cuando la ruta de actualización, rollback y configuración difiere entre releases.
La guía de Cilium para 1.18 recomienda seguir la ruta soportada y revisar el impacto de las operaciones durante un upgrade. Un rollout de CNI puede reiniciar agentes, operadores o proxies; las políticas existentes pueden seguir activas mientras algunas funciones de nivel 7 interrumpen conexiones durante el reinicio de componentes. El cambio es pequeño en el número de versión, pero forma parte del plano de red del clúster, así que conviene probarlo en un grupo de nodos representativo y observar conectividad y endpoints antes de ampliar.
Las notas no fijan una ventana obligatoria ni un mandato universal de instalación. La mejor preparación es comparar las notas con los síntomas observados: eliminación inesperada de pods de red, cadenas ip6tables que no quedan como espera el agente o backends que no vuelven tras un reinicio. Si no hay síntomas, sigue teniendo sentido considerar los fixes dentro del ciclo habitual de parches, con la validación normal del CNI.
-InfraCrew dice:un DaemonSet de red no es el lugar donde probar si “helm upgrade” conserva tus valores por telepatía.-
Qué conviene comprobar después
Tras desplegar en un entorno de prueba, se puede comparar antes y después el número de endpoints de Cilium, el estado de políticas y la presencia de backends para servicios que se hayan reiniciado. Si el problema original era un fallo de reconciliación, la señal no es solo que los pods aparezcan como Ready, sino que las reglas y destinos esperados vuelvan a estar presentes. También debe revisarse si la release renueva dependencias de seguridad, porque un cambio de módulo Go puede tener implicaciones distintas según cómo se empaquete la imagen.
Cilium usa eBPF como base de su datapath, aunque esta release menciona además comportamiento de ip6tables. Eso no implica que todos los clústeres usen las mismas rutas de red: la configuración depende del modo de enrutamiento, compatibilidad del kernel y opciones del CNI. No hay que asumir que el fallo afecta a cualquier clúster por llevar Cilium; primero se compara la configuración real con la ruta descrita en el issue corregido.
El valor operativo de esta versión está en reducir estados de red inesperados, no en perseguir un número nuevo. Actualizar de forma escalonada, verificar endpoints y backends, y preservar los valores de configuración hace más fácil distinguir el efecto del parche de un problema ajeno. El release no elimina la necesidad de monitorizar el datapath: hace que algunos estados incorrectos tengan una corrección publicada y rastreable.
Diccionario de la Crew
CNI — interfaz que permite a Kubernetes conectar pods a la red del clúster.
Endpoint — representación que mantiene Cilium de una carga conectada a la red y a sus políticas.
ip6tables — conjunto de reglas de filtrado y traducción de tráfico IPv6 en Linux.
Backend — destino concreto, como un pod, al que un servicio puede enviar tráfico.
GC (garbage collection) — proceso que identifica y elimina objetos que ya no deben permanecer en el estado activo.
