Developing your own Kubernetes controller in Java

In order to execute REST calls in Java, one needs to generate the bindings first. There are several ways to get those: . The most tedious one is to do that manually: one needs to carefully get hold of all possible JSON request and response combinations, develop the corresponding Java objects, choose the JSON serialization framework, as well as the HTTP client. . The next best option is to use proprietary code generators such as Swagger or Apiary . This requires the API provider to provide the model in one of the possible formats. On the downside, one needs to use the relevant tool. Sometimes, the format is more or less open, such as the OpenAPI specification . In that case, the tool can be chosen among those that implement the format. . In the best of cases, the bindings are already provided.

This is the case with Kubernetes: the project provides their own bindings, for a variety of languages . The issue is that the language wrapper is very close to the REST API, too close for my taste. For example, this is how one lists all pods across all namespaces:

ApiClient client = Config.defaultClient();
CoreV1Api core = new CoreV1Api(client);
V1PodList pods =
    core.listPodForAllNamespaces(null, null, null, null, null, null, null, null); (1)

This is what was meant by "the wrapper code being very close to the REST API"". Fortunately, there’s another option available. The Fabric8 organization offers a fluent Java API on Github . The code equivalent to the above one is:

KubernetesClient client = new DefaultKubernetesClient();
PodList pods = client.pods().inAnyNamespace().list();    (1)

In a few words, with Fabric8’s API, all Kubernetes resources are available on the KubernetesClient instance e.g. :

• client.namespaces()
• client.services()
• client.nodes()
• etc.

Depending on the nature of the resource, it can be scoped by a namespace - or not:

• client.pods().inAnyNamespace()
• client.pods().inNamespace("ns")

At that point, the verb can be invoked:

List all pods in all namespaces

client.pods().inAnyNamespace().list();

Delete all pods in the namespace ns

client.pods().delete(client.pods().inNamespace("ns").list().getItems());

Create a new namespace with the name ns

client.namespaces()
  .createNew()
    .withApiVersion("v1")
    .withNewMetadata()
      .withName("ns")
    .endMetadata()
  .done();

Remember that a Kubernetes controller is just a control loop that watches the state of the cluster, and reconciles it with the desired state. In order to be aware of scheduling/deleting events, one needs the Observer pattern. The application will subscribe to such events, and the relevant callbacks will be triggered when they happen.

This class diagram is a very simplified diagram of the API:

To actually implement a watcher is just a matter of the following lines:

public class DummyWatcher implements Watcher<Pod> {

  @Override
  public void eventReceived(Action action, Pod pod) {
    switch (action) {
      case ADDED:            (1)
        break;
      case MODIFIED:         (2)
        break;
      case DELETED:          (3)
        break;
      case ERROR:            (4)
        break;
    }
  }

  @Override
  public void onClose(KubernetesClientException cause) {
                             (5)
  }
}

client.pods()
  .inAnyNamespace()
  .watch(DummyWatcher());

At this point, we have everything that is required to implement the sidecar pattern. I won’t show the whole code - it’s available on GitHub , but a few key things need to be highlighted.

client.pods()
  .inNamespace("ns")
  .createNew()
    .withNewMetadata()
      .addNewOwnerReference()
        .withApiVersion("v1")
        .withKind("Pod")
        .withName(podName)
        .withUid(pod.getMetadata().getUid())
      .endOwnerReference()
    .endMetadata()
  .done();