Fabric8 Kubernetes Client 7.9 está disponible!

En nombre de todo el equipo de Fabric8 y de todos sus contribuidores, estoy muy contento de anunciar que hemos liberado la versión 7.9.0 de Fabric8 Kubernetes Client y que está disponible para su descarga desde Maven Central 🎉.

Esta es la novena versión menor de Fabric8 Kubernetes Client 7, que trae nuevas características, bug fixes y mejoras, minimizando los cambios que puedan romper la compatibilidad.

Muchas gracias a todos los que habéis contribuido reportando issues, creando pull requests, dando feedback y promocionando el proyecto mediante blogs, videos, comentarios, etc. Valoramos muchísimo vuestra ayuda ¡seguid así!

Mirando hacia la 8.0

Con la 7.x entrando en modo mantenimiento, centramos nuestro esfuerzo en la próxima versión mayor, Fabric8 Kubernetes Client 8.0. Los tres cambios principales que estamos planeando son:

• Una nueva base de JDK: la versión mínima requerida sube a Java 17, así que Java 11 dejará de estar soportado.
• Una migración a Jackson 3.x, reemplazando el actual stack de serialización basado en Jackson 2.x.
• Un nuevo cliente HTTP por defecto: el transporte pasa de Vert.x 4 a Vert.x 5.

Compartiremos más detalles a medida que la 8.0 tome forma, así que mantente atento y empieza a planificar tu actualización si alguno de estos cambios afecta a tu configuración.

Novedades

Sin más dilación, veamos cuáles son las novedades más importantes de esta versión:

• Soporte para Kubernetes 1.37 (Garhwal)
• Gateway API 1.6 con TCPRoute y UDPRoute
• Fiabilidad de WebSocket en los clientes HTTP de Vert.x 5 y Jetty
• Generador de Java reforzado frente a inyección de código
• 🐛 Muchas otras mejoras y bug-fixes

Puedes encontrar la lista completa de cambios para esta versión en la release page en GitHub.

Soporte para Kubernetes 1.37 (Garhwal)

Esta versión añade soporte para Kubernetes v1.37.0 (Garhwal), manteniendo el modelo del cliente sincronizado con la última API de Kubernetes.

Junto con las nuevas APIs, varias versiones de API que se han eliminado upstream en Kubernetes v1.37.0 dejan de estar disponibles en el cliente:

• certificates.k8s.io/v1alpha1/ClusterTrustBundle; usa certificates.k8s.io/v1 o v1beta1
• networking.k8s.io/v1beta1/IPAddress y ServiceCIDR; usa networking.k8s.io/v1
• storage.k8s.io/v1beta1/VolumeAttributesClass; usa storage.k8s.io/v1
• scheduling.k8s.io/v1alpha2 (toda la versión de API, 28 tipos); usa v1alpha3 o v1beta1

La firma del constructor canónico de VolumeMount también ha cambiado para dar cabida al nuevo campo bindMountOptions. Si construyes tus recursos con los builders fluidos (new VolumeMountBuilder()...), no te afecta; sólo las llamadas directas al constructor canónico necesitan actualizarse.

Gateway API 1.6 con TCPRoute y UDPRoute

El modelo de Gateway API incluido se ha actualizado de 1.5.1 a 1.6.1. Como resultado, ahora están disponibles v1.TCPRoute y v1.UDPRoute, ambos promovidos desde v1alpha2 upstream en Gateway API v1.6.0. Los tipos v1alpha2 siguen disponibles, pero upstream los ha deprecado y planea eliminarlos en una futura versión, así que el código nuevo debería preferir los tipos v1.

Ten en cuenta que v1.SessionPersistence ya no expone idleTimeout, que se eliminó upstream en Gateway API v1.6.0. No hay pérdida de datos en tiempo de ejecución: la clase mantiene sus additionalProperties, así que cualquier YAML o JSON que todavía contenga idleTimeout se sigue deserializando y re-serializando intacto.

Fiabilidad de WebSocket en los clientes HTTP de Vert.x 5 y Jetty

Llegan un par de correcciones importantes para las operaciones de WebSocket (exec, attach, portForward y los watches basados en WebSocket) en los módulos opcionales kubernetes-httpclient-vertx-5 y kubernetes-httpclient-jetty.

En el cliente de Vert.x 5, los clientes derivados (los que se producen internamente, por ejemplo al adaptarlo a un OpenShiftClient o al refrescar un token de OAuth) creaban un cliente de WebSocket completamente nuevo y sin configuración, descartando el material de confianza (trust) del clúster y los límites configurados de tamaño de frame y de mensaje. Los clientes derivados ahora reutilizan el transporte de WebSocket del cliente original, de modo que el TLS se verifica frente a la CA del clúster configurada y se respetan los límites.

Tanto el cliente de Vert.x 5 como el de Jetty enrutan ahora también las conexiones de WebSocket a través del proxy configurado, en lugar de conectarse directamente al servidor de la API y saltarse un proxy de salida obligatorio. En el cliente de Vert.x 5, el timeout de conexión configurado se aplica ahora también a las conexiones de WebSocket.

Ten en cuenta que los módulos por defecto kubernetes-httpclient-vertx (Vert.x 4), OkHttp y JDK nunca se vieron afectados, ya que sirven los WebSockets desde el mismo cliente que usan para el HTTP normal.

Generador de Java reforzado frente a inyección de código

El java-generator ahora emite todos los valores controlados por el schema (valores de enum, el group/version/names del CRD, nombres de propiedades, descripciones y valores por defecto) como literales de cadena de Java totalmente escapados, de modo que un schema de CRD malicioso ya no puede inyectar código ejecutable en las fuentes generadas. Como medida de defensa en profundidad, cada clase generada se vuelve a parsear y se valida estructuralmente antes de escribirse, abortando la generación ante cualquier discrepancia residual.

Cómo utilizar esta versión

Si tu proyecto está basado en Maven, lo único que hay que hacer es añadir Fabric8 Kubernetes Client a las dependencias del proyecto:

<dependency>
  <groupId>io.fabric8</groupId>
  <artifactId>kubernetes-client</artifactId>
  <version>7.9.0</version>
</dependency>

Si tu proyecto está basado en Gradle, lo único que tienes que hacer es añadir Fabric8 Kubernetes Client a las dependencias de Gradle:

dependencies {
  api "io.fabric8:kubernetes-client:7.9.0"
}

Una vez hayas configurado tu proyecto, puedes crear una instancia del cliente para realizar distintas operaciones. En el siguiente fragmento de código muestro cómo instanciar el cliente y obtener una lista de Pods:

try (KubernetesClient client = new KubernetesClientBuilder().build()) {
  client.pods().list().getItems().forEach(p -> System.out.println(p.getMetadata().getName()));
}

Cómo ayudar y colaborar

Si estás interesado o interesada en ayudar con el proyecto y es la primera vez que contribuyes, puedes echar un vistazo al tag "good first issue" en el repositorio. Hemos etiquetado issues muy sencillas para que puedas iniciarte en el mundo Open Source.

También nos encanta leer artículos y publicaciones mencionando nuestro proyecto y compartiendo la experiencia. Dar una estrella al proyecto, y en general, ayudar a promocionar el proyecto, nos ayuda a llegar a más usuarios e incrementar el feedback. El feedback es la única forma de mejorar y siempre es bienvenido.

Project Page | Issues | Discussions | Gitter | Stack Overflow