Fabric8 Kubernetes Client 8.0 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 8.0.0 de Fabric8 Kubernetes Client y que está disponible para su descarga desde Maven Central 🎉.

Esta es la octava versión mayor de Fabric8 Kubernetes Client. Tal y como anticipamos en el anuncio de la 7.9, sube la versión base de Java, migra el stack de serialización a Jackson 3 y cambia el cliente HTTP por defecto a Vert.x 5. Para facilitarte la transición, hemos preparado una guía de migración para ayudarte a actualizar tu código a esta nueva versión.

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í!

Novedades

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

• Java 17 como versión mínima soportada
• Jackson 3
• Vert.x 5 como HttpClient por defecto, Jetty 12 y correcciones de proxy
• CRD Generator: adiós a la v1 y schemas que coinciden con lo que escribe el cliente
• Actualizaciones del DSL tipado y de los modelos
• 🐛 Muchas otras mejoras y bug-fixes

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

No olvides revisar la guía de migración para una actualización sin problemas.

Java 17 como versión mínima soportada

A partir de esta versión, Fabric8 Kubernetes Client ya no soporta Java 11. La versión mínima soportada es ahora Java 17, la versión más antigua que todavía cuenta con un soporte amplio por parte de los distintos proveedores.

La nueva versión base también se aplica a la build, no sólo al runtime. Los plugins de Maven, el plugin de Gradle y el annotation processor necesitan ahora una JVM de Java 17 o superior para ejecutar tu build, y los bundles de OSGi declaran osgi.ee=JavaSE 17. Si despliegas en Karaf, ten en cuenta que el feature repository kubernetes-karaf ya no define su propia feature scr y utiliza en su lugar la que proporciona la distribución de Karaf.

Jackson 3

El cliente ha migrado de Jackson 2.x a Jackson 3 (3.2.1), lo que implica las nuevas coordenadas de Maven y paquetes de Java tools.jackson. Si tu código sólo trabaja con el modelo de Kubernetes y el DSL del cliente, no deberías notar el cambio. La serialización por defecto mantiene el comportamiento de Jackson 2 para tus tipos propios, de modo que los recursos que envías al clúster son iguales que en la 7.x.

Si tu código usa Jackson directamente (serializers y deserializers propios, anotaciones en las clases de tus custom resources o mappers que construyes tú mismo), tendrás que actualizarlo. Jackson 3 cambia de paquete varias anotaciones y renombra JsonSerializer y JsonDeserializer a ValueSerializer y ValueDeserializer. Para los mappers que construyes tú mismo, la guía de migración explica cómo mantener el formato de la 7.x para tipos como Year, Month, java.sql.Date y Locale con el nuevo Jackson2JdkTypesModule.

Por favor, consulta la sección de Jackson 3 de la guía de migración para conocer todos los detalles.

Vert.x 5 como HttpClient por defecto, Jetty 12 y correcciones de proxy

Los artefactos kubernetes-client y openshift-client utilizan ahora por defecto la implementación de HttpClient de Vert.x 5 (kubernetes-httpclient-vertx-5) en lugar de la de Vert.x 4. Para la mayoría de los usuarios, este cambio debería ser transparente. Si necesitas seguir con Vert.x 4 por el momento, puedes excluir kubernetes-httpclient-vertx-5, añadir kubernetes-httpclient-vertx y fijar los artefactos de Vert.x a la 4.x, tal y como se describe en la guía de migración.

El módulo opcional kubernetes-httpclient-jetty ha pasado de Jetty 11 a Jetty 12.1. Como Jetty 12 no puede convivir en el classpath con versiones anteriores de Jetty, revisa la sección de Jetty 12 si tu aplicación también depende de Jetty.

Esta versión también trae una serie de correcciones en las distintas implementaciones de HttpClient:

• Las credenciales del proxy se envían únicamente al proxy. En varias combinaciones de implementación de HttpClient y tipo de petición (HTTPS, WebSocket o SOCKS), podían viajar a través del túnel del proxy y llegar al servidor de la API.
• Ahora se gestionan correctamente las contraseñas de proxy que contienen dos puntos, las URLs de proxy con usuario y sin contraseña, y las credenciales de proxies SOCKS5.
• Los clientes de Vert.x, Jetty y JDK envían ahora un ping de WebSocket cada Config#websocketPingInterval (30 segundos por defecto), como ya hacía OkHttp, de modo que los balanceadores de carga que cierran las conexiones inactivas ya no cortan los watches silenciosos.
• Las peticiones ya no se quedan colgadas cuando una acción de reintento, una decisión de reintento o la limpieza de la respuesta lanzan una excepción.

CRD Generator: adiós a la v1 y schemas que coinciden con lo que escribe el cliente

El CRD Generator v1 (crd-generator-api y crd-generator-apt), deprecado desde la 7.0, se ha eliminado. Si todavía lo utilizas, migra al CRD Generator v2 con el plugin de Maven, la herramienta CLI o la receta para el build script de Gradle. La guía de migración al CRD Generator v2 te guía durante el proceso. Cuidado: eliminar la dependencia sin añadir un reemplazo falla de forma silenciosa, ya que la ausencia de un annotation processor no produce ningún diagnóstico del compilador.

Los schemas generados también se han alineado con lo que el cliente escribe realmente, de modo que el servidor de la API ya no recorta ni rechaza tus datos:

• Las propiedades Object, Map sin tipar, List<Object>, colecciones sin tipar, @JsonUnwrapped y polimórficas mantienen su contenido.
• Los tipos de fecha y hora sólo declaran un formato que sus valores cumplen.
• byte[], ByteBuffer, char[], Year y java.sql.Date obtienen schemas que coinciden con su forma serializada.
• Las propiedades int/Integer y long/Long obtienen format: int32 y format: int64, como en controller-gen.

Como los CRDs generados cambian, revísalos antes de aplicarlos en tus clústers. La sección de CRDs generados de la guía de migración detalla qué es diferente.

Actualizaciones del DSL tipado y de los modelos

El DSL del cliente proporciona ahora puntos de entrada tipados para los recursos añadidos en Kubernetes 1.37, como certificates().v1().podCertificateRequests(), dynamicResourceAllocation().v1().deviceTaintRules(), storageMigration().v1().storageVersionMigrations() y los podGroups() y workloads() de scheduling().v1beta1().

Los puntos de entrada sin versión runtimeClasses() y network().ingresses() utilizan ahora los modelos v1 en lugar de los v1beta1 que Kubernetes ya no sirve.

El soporte para shard selectors introducido en la 7.8 incorpora un ShardSelector tipado, de modo que ya no necesitas escribir a mano la expresión CEL shardRange(...) y sus límites hexadecimales:

client.pods()
  .withShardSelector(ShardSelector.builder().addShard(0, 4).addShard(2, 4).build())
  .list();

Como consecuencia, una llamada literal a withShardSelector(null) ya no compila; haz un cast a (String) null en su lugar.

Por último, los modelos de extensiones incluidos siguen a sus proyectos upstream, y algunas de estas actualizaciones traen sus propios cambios incompatibles. Si utilizas los modelos de OpenShift, Open Cluster Management, Tekton o Knative, revisa los breaking changes en la release page.

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>8.0.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:8.0.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