Anuncio de Flux 2.9 GA

¡Estamos emocionados de anunciar la liberación de Flux v2.9.0! En esta publicación, destacamos algunas de las nuevas características y mejoras incluidas en esta versión. Destacados Flux v2.9 introduce el Sistema de Plugins CLI de Flux, una nueva forma de extender la interfaz de línea de comandos de Flux con plugins de primera clase. Junto con el sistema de plugins, esta versión trae potentes adiciones a la aplicación del lado del servidor, la descifrado de secretos y las integraciones de Git. En esta versión, hemos introducido varias nuevas características en la CLI de Flux y en los controladores: Sistema de Plugins CLI de Flux con los plugins Mirror y Schema Reglas de ignorar campos en la aplicación del lado del servidor para un control preciso de deriva Descifrado de SOPS con el cifrado post-cuántico Age Autenticación de Identidad de Carga de Trabajo de Kubernetes para OpenBao y Vault Estrategias de post-renderizado de Helm, incluyendo soporte para hooks de gráficos Firma y verificación de confirmaciones de Git con claves SSH Webhook Receivers sin secretos, asegurados por OIDC Autenticación de AWS CodeCommit utilizando Identidad de Carga de Trabajo En noticias del ecosistema, hay una nueva versión del Operador de Flux que extiende la interfaz web de Flux con un panel de carga de trabajo y un potente visor de registros de pods. Sistema de Plugins CLI de Flux La característica principal de Flux v2.9 es el nuevo Sistema de Plugins CLI de Flux, especificado en RFC-0013. Los plugins te permiten extender el comando flux con capacidades adicionales que se envían y versionan de manera independiente a la CLI de Flux, mientras se siente como parte nativa de la herramienta. El catálogo de plugins de Flux se envía con dos plugins mantenidos por el proyecto Flux: Mirror — refleja gráficos de Helm, artefactos de OCI e imágenes de contenedores entre registros usando una configuración declarativa. Soporta imágenes de múltiples arquitecturas, conversión de gráficos de Helm de HTTP/S a OCI, verificación de firmas, filtrado por regex y semver, y múltiples métodos de autenticación incluyendo la Identidad de Carga de Trabajo en la nube. Schema — valida manifiestos de Kubernetes contra esquemas JSON y reglas CEL. Viene con esquemas integrados para Kubernetes, OpenShift, Gateway API y las CRD de Flux, soporta catálogos de esquema personalizados e integra con CI/CD a través de GitHub Actions o Docker. Además, ControlPlane mantiene el plugin Operator para gestionar recursos del Operador de Flux, rastrear objetos a través del pipeline de GitOps, depurar ResourceSets e instalar habilidades de agentes de IA. Instalación de plugins Los plugins se gestionan a través de los nuevos subcomandos de flux plugin. Los binarios se descargan a ~/fluxcd/plugins y se registran como subcomandos de Flux, así que una vez instalados, se invocan como flux <plugin>: # Buscar en el catálogo de plugins disponibles flux plugin search # Instalar un plugin flux plugin install schema # Listar plugins instalados flux plugin list # Actualizar y eliminar plugins flux plugin update schema flux plugin uninstall schema Por defecto, flux plugin install descarga la versión más reciente de un plugin. Para configuraciones reproducibles, puedes fijar un plugin a una versión específica con flux plugin install schema@0.5.0, o a un resumen inmutable con flux plugin install schema@sha256:<digest>, lo cual se recomienda para pipelines de CI y entornos de producción. Reglas de ignorar campos en la aplicación del lado del servidor Flux aplica tus recursos con aplicación del lado del servidor, convirtiéndose en el administrador de campos de todo lo que concilia. Sin embargo, ciertos campos deben ser propiedad de otros controladores, como el campo de réplicas gestionado por un escalador automático de pods horizontal, o los certificados inyectados por un webhook de admisión. Hasta ahora, Flux intentaría continuamente revertir esos campos al estado deseado declarado en Git. Flux v2.9 extiende la aplicación del lado del servidor con reglas de ignorar campos. Usando el nuevo campo Kustomization.spec.ignore, puedes decirle al controlador de kustomize que ignore campos específicos gestionados durante la detección de deriva y la aplicación, dejándolos bajo la propiedad de otros controladores: apiVersion: kustomize.toolkit.fluxcd.io/v1 kind: Kustomization metadata: name: podinfo namespace: flux-system spec: # ... ignore: - target: kind: Deployment paths: - "/spec/replicas" Esto te brinda un control preciso sobre qué partes de un recurso posee Flux, facilitando la combinación de GitOps con escaladores automáticos, mallas de servicio y otros controladores que mutan objetos en vivo. Mejora del descifrado de secretos Cifrado post-cuántico Age Flux v2.9 agrega soporte para descifrar secretos cifrados con SOPS sellados con el cifrado post-cuántico Age. A medida que la industria se prepara para la criptografía post-cuántica, esto permite a los equipos proteger sus secretos en reposo con cifrado resistente a los cuánticos mientras mantienen el mismo flujo de trabajo de GitOps basado en SOPS. Identidad de Carga de Trabajo para OpenBao y Vault A partir de esta versión, el controlador de kustomize ahora puede autenticarse a OpenBao y HashiCorp Vault utilizando la Identidad de Carga de Trabajo de Kubernetes. Esto elimina la necesidad de almacenar tokens de Vault de larga duración en el clúster. Flux cambia el token de ServiceAccount del controlador por credenciales de Vault, siguiendo el mismo modelo de autenticación sin claves ya utilizado para los proveedores de la nube. Mejoras en Helm Estrategias de post-renderizado Flux v2.9 agrega soporte para estrategias de post-renderización de Helm en la API de HelmRelease, dándote control sobre cómo la post-renderización interactúa con los hooks de gráficos. Cambio importante La estrategia de post-renderizado predeterminada ha cambiado de nohooks a combinada. Con la nueva predeterminada, los hooks de Helm se incluyen en el proceso de post-renderización, lo que se alinea más estrechamente con el comportamiento nativo de Helm. Si tus gráficos dependen del comportamiento anterior, establece la estrategia explícitamente a nohooks en tus HelmReleases antes de actualizar. Valores literales El campo valuesFrom de HelmRelease ahora soporta un modo literal que refleja la semántica de helm install --set-literal. Esto te permite inyectar todo el contenido de una ConfigMap o clave Secret como un único valor de cadena, sin que Helm intente analizarlo como un tipo; útil para valores que contienen caracteres que Helm interpretaría de otra manera. Un ejemplo común es pasar archivos de configuración completos, como Java application.properties o blobs de configuración .yaml, a un valor de gráfico tal cual, sin que los puntos en las claves de propiedades se expandan en objetos anidados. Comprobaciones de salud CEL Las expresiones de comprobación de salud basadas en CEL ahora permiten un tipo vacío, lo que hace posible escribir comprobaciones de salud que se aplican a múltiples tipos de recursos tanto en HelmReleases como en Kustomizations. Integraciones de Git Flux v2.9 trae claves SSH para la firma y verificación de confirmaciones de Git, complementando el soporte existente para GPG: Verificación el controlador de origen ahora puede verificar las firmas de confirmaciones de Git realizadas con claves SSH, además de GPG, configurado a través de la API GitRepository.spec.verify. Firma el controlador de automatización de imágenes puede firmar las confirmaciones que empuja con claves SSH, configurado a través de la API ImageUpdateAutomation.spec.git.commit.signingKey, y flux bootstrap puede firmar las confirmaciones de manifiesto que empuja con claves SSH. Esta versión también añade soporte para autenticarse a AWS CodeCommit utilizando la Identidad de Carga de Trabajo, extendiendo el modelo de autenticación sin claves a los repositorios de Git alojados en AWS. También puedes iniciar Flux directamente en CodeCommit siguiendo la guía de inicio dedicada a AWS CodeCommit. Mejoras en artefactos Sigstore privado Para entornos a prueba de aire y auto-alojados, el controlador de origen ahora soporta una raíz confiable personalizada de Sigstore para la verificación sin claves de artefactos OCI e imágenes de contenedores. Esto permite a las organizaciones que ejecutan su propia infraestructura de Sigstore verificar firmas sin depender de la raíz de confianza pública de Sigstore. Descubrimiento de directorios de ArtifactGenerator La API de ArtifactGenerator obtiene descubrimiento de directorio por patrón de ruta, facilitando la gestión de artefactos a través de monorepos. En lugar de declarar un artefacto por aplicación manualmente, describes un diseño de directorio con un patrón y dejas que el observador de origen descubra los directorios coincidentes y genere un ExternalArtifact por coincidencia. Capturas nombradas como {app} y {env} se convierten en variables de plantilla para nombres y etiquetas de artefactos: apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: ArtifactGenerator metadata: name: monorepo-apps namespace: flux-system spec: sources: - alias: monorepo kind: GitRepository name: my-monorepo pathPattern: "@monorepo/apps/{app}/envs/{env}" artifacts: - name: "{app}-{env}" copy: - from: "@monorepo/apps/{app}/envs/{env}/**" to: "@artifact/" Mejoras en Webhook Flux v2.9 introduce soporte para Receivers genéricos asegurados por OIDC, permitiendo que los Receivers de webhook sean asegurados sin un secreto compartido. En lugar de validar una firma HMAC, el controlador de notificaciones puede verificar un token ID de OIDC presentado por el llamador, lo que permite integraciones seguras y sin secretos con plataformas que soportan OIDC. Los Receivers también pueden ser configurados ahora con un filtro a nivel de recurso, brindándote más control preciso sobre qué recursos un Receiver concilia cuando es activado. Para hacer que los Receivers sean más fáciles de trabajar desde la línea de comandos y trabajos de CI, esta versión añade el nuevo comando flux trigger receiver, que te permite activar un webhook sin necesidad de elaborar y enviar la solicitud HTTP tú mismo. Noticias del Ecosistema Flux Web UI: Cargas de Trabajo y Registros La última versión del Operador de Flux extiende la interfaz web de Flux con un panel de carga de trabajo dedicado y un visor de registros de pods totalmente funcional. El nuevo panel de carga de trabajo proporciona una vista enfocada para Implementaciones, StatefulSets, DaemonSets y CronJobs, incluyendo: Una visualización de pipeline que muestra el flujo desde la fuente a través del conciliador hasta la carga de trabajo y los pods Controles de acción para operaciones de conciliación, implementación y suspender/reanudar Un panel de múltiples pestañas con secciones de Resumen, Pods, Eventos, Especificación y Estado Listados de pods detallados con estado de implementación e información de imagen por contenedor El visor de registros de pods trae una experiencia moderna de registro directamente en la interfaz: Transmisión de registros en tiempo real con modos seguir y instantánea Agregación de múltiples pods y múltiples contenedores con ordenación cronológica Detección de nivel de registro y codificación de colores a través de muchos frameworks de registro Agrupamiento de trazas de pila colapsables para excepciones de Go, Python, Node y Java Poderoso filtrado con soporte de negación, impresión bonita de JSON y exportaciones descargables Todas las operaciones de carga de trabajo y registros respetan Kubernetes RBAC a través de la suplantación de usuarios, por lo que lo que cada usuario puede ver y hacer en la interfaz coincide con sus permisos en el clúster. Comienza instalando la versión más reciente del Operador de Flux y siguiendo la documentación de la interfaz web de Flux. Versiones Soportadas Flux v2.6 ha llegado al final de su vida útil y ya no se soporta. Flux v2.9 soporta las siguientes versiones de Kubernetes: Distribución Versiones Kubernetes 1.34, 1.35, 1.36 OpenShift 4.21 Soporte empresarial Ten en cuenta que el proyecto CNCF Flux ofrece soporte solo para las tres últimas versiones menores de Kubernetes. La compatibilidad hacia atrás con versiones anteriores de Kubernetes y OpenShift es ofrecida por proveedores como ControlPlane que brindan soporte empresarial para Flux. Procedimiento de Actualización Ten en cuenta que en Flux v2.9, las siguientes APIs han llegado al final de su vida útil y han sido eliminadas de las CRD: image.toolkit.fluxcd.io/v1beta2 notification.toolkit.fluxcd.io/v1beta2 Antes de actualizar a Flux v2.9, asegúrate de migrar todos tus recursos a las APIs estables usando el comando flux migrate. Esta versión también contiene los siguientes cambios importantes, por favor revísalos antes de actualizar: La estrategia de post-renderizado predeterminada de Helm ha cambiado de nohooks a combinada. Los Receivers de GCR ahora requieren los campos de correo electrónico y audiencia en su Secret referenciado (CVE-2026-40109). Procedimiento de Actualización para Flux v2.9 Hemos publicado una guía de actualización paso a paso dedicada, por favor sigue las instrucciones de la Guía de Procedimiento de Actualización para Flux v2.7+. Y hasta aquí Si tienes alguna pregunta o simplemente te ha gustado lo que leíste y quieres involucrarte, aquí hay algunas buenas maneras de contactarnos: Únete a nuestras próximas reuniones de desarrollo. Háblanos en el canal #flux en CNCF Slack. Únete a las discusiones de planificación. Sigue a Flux en Twitter, o únete al grupo de LinkedIn de Flux.