Fabric8 Kubernetes Client: typed Java for the Kubernetes API

Creating a client in one line, with three credential sources

The README's entry point is short, and it is the whole argument for the library in one line:

KubernetesClient client = new KubernetesClientBuilder().build();

No configuration file argument, no explicit URL. The builder resolves connection details itself, and the README lists the sources in order of priority: system properties, then environment variables, then the kube config file, then a service account token with its mounted CA certificate. System properties beat environment variables. That last entry is the important one for in-cluster use, because a pod talking to the API server uses the mounted service account rather than anything you wrote down.

OpenShift is handled by an adapter rather than a second client type. `DefaultOpenShiftClient` implements both interfaces, so getting the OpenShift view of the same connection is a cast-like call:

OpenShiftClient osClient = new KubernetesClientBuilder().build().adapt(OpenShiftClient.class);

The README names the concrete payoff, which is access to OpenShift extensions such as `Build`s. This is why the project exists rather than being a thin wrapper someone could write in an afternoon: the value is in the typed model of both upstream Kubernetes and the OpenShift API surface, generated rather than hand-maintained.

Two modules, seven extensions, and a mock server

The README publishes a module table rather than a single dependency, which is the first structural decision. The two core artifacts are `kubernetes-client` and `openshift-client`, each with its own Maven Central coordinate and Javadoc.

Then there are extensions: `knative-client`, `tekton-client`, `chaosmesh-client`, `volumesnapshot-client`, `volcano-client`, `istio-client` and `open-cluster-management-client`. Each is a separate artifact with its own generated models. That is the right shape for an ecosystem this size, because you should not pull Istio models into a project that only manages Pods, and a modular build makes that possible.

The features that make this more than a typed REST wrapper are the ones further down the README's contents list. There is a DSL, in the repository topics, for building resources fluently. There is `Passing a reference of a resource to the client`, which is about attaching a resource to a client without a round trip. There is `Adapting a client`, with a subsection on adapting and closing, which is the OpenShift mechanism described above and the lifecycle question that comes with it.

Two capabilities are worth calling out because they change how you work rather than what you write. `Mocking Kubernetes` has its own section and its own repository topics, `mock-server` and `mocking-kubernetes`, which means you can test code that creates resources without a cluster. And there is a section on generating Java from a CRD alongside the reverse, generating a CRD from Java, with both documented under `doc/` in the repository.

How the model classes are generated, from the Makefile

The Makefile at the repository root is where the real engineering shows, and it is worth reading even if you never build the project. The default goal is `quickly`, Maven arguments default to parallel builds with `-T 1C`, and the OpenAPI paths point into `kubernetes-model-generator/openapi`.

The generation sequence is visible in the targets. To regenerate the schemas, the build changes into the generator directory, runs `go generate`, builds a binary named `generator` from `./cmd`, then runs that binary twice: once with a `reflection` argument against the schemas directory, and once with an `open-api` argument. There is a comment noting that this must be run from the root of the Go project so the tool can reach the sources and module information.

That tells you the model classes are not written by hand. They are derived from the Kubernetes OpenAPI schema through a Go-based generator, which is why a client can track upstream API changes without a volunteer editing thousands of Java files. The Java classes are then produced by a separate target that first installs the model generator with the `generate` profile, and it is annotated as discovering the `extensions/**/model` modules rather than listing them, which is how the build stays consistent as extensions are added.

The alternative would be hand-written builders or a runtime reflection layer. Both exist in the Java ecosystem and both have costs: hand-written classes drift, and reflection gives up compile-time checking, which for a client whose whole value is catching mistakes at compile time would be self-defeating. Generating the classes is the expensive-but-correct answer, and the build pays that cost so your build does not.

Reading the module layout as a map of the project's scope

The top-level tree tells you what this project considers its own responsibility, and the list is long. `kubernetes-client-api/` is the API surface, `kubernetes-client/` the implementation, and `kubernetes-model-generator/` the code generation described above. `crd-generator/` handles the CRD direction, `java-generator/` the other generator, and `generator-annotations/` and `bom-generator-plugin/` the supporting tooling.

The HTTP layer is the part with the most visible design choice. There are four separate modules: `httpclient-jdk`, `httpclient-jetty`, `httpclient-okhttp` and `httpclient-vertx`, plus a fifth for Vert.x 5 specifically. Making the HTTP client pluggable is the difference between a library you can drop into an application that already has an HTTP stack and one that forces its own, and the count of implementations suggests the maintainers take that seriously.

Then the test infrastructure, which is unusually visible. `kubernetes-tests/` and `kubernetes-itests/` are separate, `kubernetes-itests-envtest/` is specifically for the envtest harness, `chaos-tests/` is a distinct suite, and `kubernetes-client-deps-compatibility-tests/` exists to check dependency compatibility, presumably across HTTP client choices and Kubernetes versions. That last one is the directory that tells you the maintainers know the dependency matrix is the hard part of this project.

The rest of the tree is documentation and support: `doc/` with the CRD generator guide, the Java generation guide, the cheat sheet, the kubectl Java equivalents and the FAQ, plus `kubernetes-examples/`, `platforms/`, `uberjar/`, `zjsonpatch/` for JSON patch handling, `junit/`, `log4j/`, `extensions/`, `ide-config/`, `scripts/` and `.mvn/`. The `CLAUDE.md` and `AGENTS.md` files at the root follow a pattern now common in actively maintained repositories.

Release cadence, compatibility, and what it costs to adopt

Recent releases are steady and roughly quarterly: v7.7.0 on 2026-05-12, v7.8.0 on 2026-06-29, and v7.9.0 on 2026-09-04. The last push was on 2026-09-23. That is a healthy cadence for a project whose whole job is tracking an upstream API, and the version numbers line up with the way Kubernetes itself versions, which is the point: a client release usually exists because an API changed.

The README includes a section on Kubernetes and Red Hat OpenShift compatibility, which tells you where to look when a cluster version and a client version disagree. It also publishes a cheat sheet and a page of kubectl Java equivalents, which is a candid admission that many people arrive at this library already knowing the command line and wanting the Java form of what they know.

The real cost is the dependency tree. Four HTTP client implementations, an OpenAPI generator written in Go that ships as build tooling, Jackson underneath for serialization, and seven extension modules that exist but do not have to be on your classpath. For a Spring Boot service already managing dozens of clusters this is unremarkable. For a five-line script that lists pods it is absurd, and `kubectl` invoked from a shell is the better tool.

The comparison to the official Kubernetes clients for other languages is also real. The Go client is the upstream one and is what the API server's own controllers use. The Python client is the most commonly used. If you are writing in Java, Fabric8's advantage is generated typed models for OpenShift and CRDs plus the mock server; if you are not writing in Java, this is a strong argument to write in the language whose client already exists. The licence is Apache-2.0, which is permissive for commercial use, and the project is sponsored by Red Hat, which is visible in the Makefile header and in the OpenShift support that no other client can offer.

Editorial conclusion

The Fabric8 Kubernetes Client is the right tool for a Java operator, an OpenShift client, or anyone generating typed code from a CRD, because typed model classes and a mock server are not things the official clients offer. It is the wrong choice for a small script, where the kubectl binary is less code than a Maven dependency tree. The specific first step is `new KubernetesClientBuilder().build()` against your current kubeconfig, which picks up the same credential sources as kubectl. Before adopting it, check which Kubernetes version line your cluster runs against, because the client's generated model is tied to that version and the release cadence is roughly quarterly.

Frequently asked questions

Official sources

1. fabric8io/kubernetes-client on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases