Fabric8 Kubernetes Client 8.0 is now available!

On behalf of the Fabric8 team and everyone who has contributed, I'm happy to announce that the Fabric8 Kubernetes Client 8.0.0 has been released and is now available from Maven Central 🎉.

This marks the eighth major release of the Fabric8 Kubernetes Client. As we anticipated in the 7.9 announcement, it raises the Java baseline, moves the serialization stack to Jackson 3, and switches the default HTTP client to Vert.x 5. To assist you with the transition, we've prepared a migration guide to help you update your code to this new version.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• Java 17 as the minimum supported version
• Jackson 3
• Vert.x 5 as the default HttpClient, Jetty 12, and proxy fixes
• CRD Generator: v1 removed and schemas that match what the client writes
• Typed DSL and model updates
• 🐛 Many other bug fixes and minor improvements

You can find the full changelog for this version in our GitHub release page.

Be sure to check out the migration guide for a smooth upgrade.

Java 17 as the minimum supported version

Starting with this release, the Fabric8 Kubernetes Client no longer supports Java 11. The minimum supported version is now Java 17, the oldest release that still receives broad support across vendors.

The new baseline applies to the build too, not only to the runtime. The Maven plugins, the Gradle plugin, and the annotation processor now require a Java 17+ JVM to run your build, and the OSGi bundles declare osgi.ee=JavaSE 17. If you deploy on Karaf, note that the kubernetes-karaf feature repository no longer defines its own scr feature and relies on the one provided by the Karaf distribution instead.

Jackson 3

The client has moved from Jackson 2.x to Jackson 3 (3.2.1), which means the new tools.jackson Maven coordinates and Java packages. If your code only deals with the Kubernetes model and the client DSL, you shouldn't notice the change. The default serialization keeps the Jackson 2 behavior for your custom types, so the resources you send to the cluster look the same as they did in 7.x.

If your code uses Jackson directly (custom serializers and deserializers, annotations on your custom resource classes, or mappers you build yourself), you'll need to update it. Jackson 3 relocates several annotations and renames JsonSerializer and JsonDeserializer to ValueSerializer and ValueDeserializer. For mappers you build yourself, the migration guide explains how to keep the 7.x wire format for types such as Year, Month, java.sql.Date, and Locale with the new Jackson2JdkTypesModule.

Please, check the Jackson 3 section of the migration guide for the details.

Vert.x 5 as the default HttpClient, Jetty 12, and proxy fixes

The kubernetes-client and openshift-client artifacts now default to the Vert.x 5 HttpClient implementation (kubernetes-httpclient-vertx-5) instead of the Vert.x 4 one. For most users, this change should be seamless. If you need to stay on Vert.x 4 for now, you can exclude kubernetes-httpclient-vertx-5, add kubernetes-httpclient-vertx, and pin the Vert.x artifacts to 4.x, as described in the migration guide.

The optional kubernetes-httpclient-jetty module has moved from Jetty 11 to Jetty 12.1. Since Jetty 12 can't coexist with earlier Jetty versions on the classpath, check the Jetty 12 section if your application depends on Jetty too.

This release also brings a round of fixes across the HttpClient implementations:

• Proxy credentials are sent only to the proxy. In several combinations of HttpClient implementation and request type (HTTPS, WebSocket, or SOCKS), they could travel through the proxy tunnel and reach the API server.
• Proxy passwords containing a colon, proxy URLs with a user and no password, and SOCKS5 proxy credentials are now handled correctly.
• The Vert.x, Jetty, and JDK clients now send a WebSocket ping every Config#websocketPingInterval (30 seconds by default), like OkHttp already did, so load balancers that close idle connections no longer drop quiet watches.
• Requests no longer hang when a retry action, a retry decision, or the response cleanup throws an exception.

CRD Generator: v1 removed and schemas that match what the client writes

The CRD Generator v1 (crd-generator-api and crd-generator-apt), deprecated since 7.0, has been removed. If you are still using it, migrate to the CRD Generator v2 with the Maven plugin, the CLI tool, or the Gradle build script recipe. The CRD Generator v2 migration guide walks you through the process. Beware: dropping the dependency without adding a replacement fails silently, since an absent annotation processor produces no compiler diagnostic.

The generated schemas have also been aligned with what the client actually writes, so the API server no longer prunes or rejects your data:

• Object, raw Map, List<Object>, raw collection, @JsonUnwrapped, and polymorphic properties keep their content.
• Date and time types only declare a format their values match.
• byte[], ByteBuffer, char[], Year, and java.sql.Date get schemas that match their serialized form.
• int/Integer and long/Long properties get format: int32 and format: int64, like controller-gen.

Since the generated CRDs change, review them before applying them to your clusters. The Generated CRDs section of the migration guide lists what's different.

Typed DSL and model updates

The client DSL now provides typed entry points for the resources added in Kubernetes 1.37, such as certificates().v1().podCertificateRequests(), dynamicResourceAllocation().v1().deviceTaintRules(), storageMigration().v1().storageVersionMigrations(), and the scheduling().v1beta1() podGroups() and workloads().

The unversioned runtimeClasses() and network().ingresses() entry points now use the v1 models instead of the v1beta1 ones that Kubernetes no longer serves.

The shard selector support introduced in 7.8 gains a typed ShardSelector, so you no longer need to write the shardRange(...) CEL expression and its hexadecimal bounds by hand:

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

As a consequence, a literal withShardSelector(null) no longer compiles; cast it to (String) null instead.

Finally, the bundled extension models follow their upstream projects, and some of these upgrades bring breaking changes of their own. If you use the OpenShift, Open Cluster Management, Tekton, or Knative models, check the breaking changes in the release page.

Using this release

If your project is based on Maven, you just need to add the Fabric8 Kubernetes Client to your Maven dependencies:

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

If your project is based on Gradle, you just need to add the Fabric8 Kubernetes Client to your Gradle dependencies:

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

Once your project is ready, you can create a new instance of the client to perform operations. In the following code snippet, I show you how to instantiate the client and retrieve a list of Pods:

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

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "good first issue" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Giving a star to the project, and spreading the word in general, helps us reach more users and broaden the feedback. Feedback is the only way to improve.

Project Page | Issues | Discussions | Gitter | Stack Overflow