Quarkus - Kubernetes Client

Having a Kubernetes Client extension in Quarkus is very useful in order to unlock the power of Kubernetes Operators.Kubernetes Operators are quickly emerging as a new class of Cloud Native applications.These applications essentially watch the Kubernetes API and react to changes on various resources and can be used to manage the lifecycle of all kinds of complex systems like databases, messaging systems and much much more.Being able to write such operators in Java with the very low footprint that native images provide is a great match.

Once you have your Quarkus project configured you can add the kubernetes-client extensionto your project by running the following command in your project base directory.

/mvnw quarkus:add-extension -Dextensions="kubernetes-client"

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-kubernetes-client</artifactId>
</dependency>

Usage

Quarkus configures a Bean of type KubernetesClient which can be injected into application code using the well known CDI methods.This client can be configured using various properties as can be seen in the following example:

quarkus.kubernetes-client.trust-certs=false
quarkus.kubernetes-client.namespace=default

Note that the full list of properties is available in the class.

An example of this can be seen in the following snippet:

@ApplicationScoped
public class KubernetesClientProducer {
    @Produces
    public KubernetesClient kubernetesClient() {
        // here you would create a custom client
        return new DefaultKubernetesClient();
    }
}

To make testing against a mock Kubernetes API extremely simple, Quarkus provides the KubernetesMockServerTestResource which automatically launchesa mock of the Kubernetes API server and sets the proper environment variables needed so that the Kubernetes Client configures itself to use said mock.Tests can inject the mock and set it up in any way necessary for the particular testing using the @MockServer annotation.

Let’s assume we have a REST endpoint defined like so:

We could write a test for this endpoint very easily like so:

@QuarkusTestResource(KubernetesMockServerTestResource.class)
@QuarkusTest
public class KubernetesClientTest {
    @MockServer
    KubernetesMockServer mockServer;
    @BeforeEach
    public void before() {
        final Pod pod1 = new PodBuilder().withNewMetadata().withName("pod1").withNamespace("test").and().build();
        final Pod pod2 = new PodBuilder().withNewMetadata().withName("pod2").withNamespace("test").and().build();
        mockServer.expect().get().withPath("/api/v1/namespaces/test/pods")
                .andReturn(200,
                        new PodListBuilder().withNewMetadata().withResourceVersion("1").endMetadata().withItems(pod1, pod2)
                                .build())
                .always();
    @Test
    public void testInteractionWithAPIServer() {
        RestAssured.when().get("/pod/test").then()
                .body("size()", is(2));
    }
}

Note that to take advantage of these features, the quarkus-test-kubernetes-client dependency needs to be added, for example like so:

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-test-kubernetes-client</artifactId>
    <scope>test</scope>
</dependency>

Note on implementing the Watcher interface

client.pods().watch(new Watcher<Pod>() {
    @Override
    public void eventReceived(Action action, Pod pod) {
        // do something
    }
    @Override
    public void onClose(KubernetesClientException e) {
        // do something
    }
});

or

Note that defining the generic type via a class hierarchy similar to the following example will also work correctly:

public abstract class MyWatcher<S> implements Watcher<S> {
}
...
client.pods().watch(new MyWatcher<Pod>() {
    @Override
    public void eventReceived(Action action, Pod pod) {
        // do something
    }
});

public class ResourceWatcher<T extends HasMetadata> implements Watcher<T> {
    @Override
    public void eventReceived(Action action, T resource) {
    }
    @Override
    public void onClose(KubernetesClientException e) {
        // do something
    }
}
client.pods().watch(new ResourceWatcher<Pod>());

In many cases in order to access the Kubernetes API server a ServiceAccount, Role and RoleBinding will be necessary.An example that allows listing all pods could look something like this:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: <applicationName>
  namespace: <namespace>
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: <namespace>
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: <applicationName>
  namespace: <namespace>
roleRef:
  kind: Role
  name: <applicationName>
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount
    name: <applicationName>
    namespace: <namespace>

Replace <applicationName> and <namespace> with your values.Have a look at to get further information.

Configuration Reference

Configuration property fixed at build time - ️ Configuration property overridable at runtime