Kubernetes for Java Developers

Microservices is a style of architecture consisting of a small, individual application component with a single responsibility, with a high degree of autonomy in terms of deployment and scalability. These components communicate via a lightweight protocol like REST over HTTP. In consequence, development teams are small (the two-pizza rule), focused on a microservice. In practice the team owns the entire lifecycle from development to deployment — if you built it, you run it. This creates a problem. After all, dev teams' core competency is usually Maven, a microservices framework, say, Spring Boot, test frameworks like JUnit, and so on. But if we look at the steps involved in deploying a microservice:

• Package the application in a container like Docker. This involves writing a Dockerfile.
• Deploy the container to an orchestrator like Kubernetes. This involves writing several resources; description files for services, deployment, etc.

To use a term familiar to developers, this is an 'impedance mismatch.' To solve this problem, we need a class of tools that speak the language of developers and make the entire deployment steps transparent to them. The most famous of these is Jib, which we dealt with in a previous paper, which builds optimized Docker and OCI images for your Java applications and is available as a Maven plugin. There are other tools in this category like Dekorate which allows us to generate Kubernetes manifests using just Maven and Java annotations. The latest and comprehensive entry in this category is JKube from RedHat which our subject de jour.

JKube is a Maven plugin with the goal, among others, of building a Docker image and creating Kubernetes resource descriptors. The image and the descriptors can be generated with no configuration, based on some opiniated defaults based on the entries in the pom file, or alternatively can be customized with XML entries in the pom or in extremis with Dockerfiles and resource fragments. Here are the plugin’s goals:

To begin, I will assume that you have a local install of Docker and Kubernetes. There are several ways to do it. I will also assume that you have a basic knowledge of Docker and Kubernetes as outlined in [Docker] and [Kubernetes].

x

<plugin>

     <groupId>org.eclipse.jkube</groupId>

     <artifactId>kubernetes-maven-plugin</artifactId>

     <version>1.2.0</version>

</plugin>

Now we can generate the image:

xxxxxxxxxx

mvn k8s:build

After the usual Spring Boot song and dance, you can list the image:

You can customize the image. For instance, you may want to pick the base image other than the default that the plugin uses, by configuring the from element in the pom:

<configuration>

     <images>

      <image>

       <build>

           <from>your-base-image</from>

……..

You can also use your own Dockerfile. For instance, you may want to use JLink to create a custom JRE in order to minimize the image size. We showed before how to do this. We can now generate the resource files.

xxxxxxxxxx

mvn k8s:resource

This will generate two files <artifactid>-deployment.yml and <artifactid>-service.yml in target\classes\META-INF\jkube\kubernetes.

Notice that the deployment YML has a liveliness and readiness probe:

xxxxxxxxxx

livenessProbe:

         failureThreshold: 3

         httpGet:

           path: /actuator/health

           port: 8080

           scheme: HTTP

         initialDelaySeconds: 180

         successThreshold: 1

and 

xxxxxxxxxx

readinessProbe:

         failureThreshold: 3

         httpGet:

           path: /actuator/health

           port: 8080

           scheme: HTTP

         initialDelaySeconds: 10

         successThreshold: 1

This is because we included a dependency on Spring Boot Actuator. (Liveliness probe determines if a container is healthy and does not need to be restarted. A readiness probe determines when a service is ready to serve user requests.) This is an example of JKube using information from the pom and some defaults to configure the deployment.

The default service created is of type ClusterIP. But you won’t be able to access it from outside the cluster. To do that you will need to provide an additional parameter to Jkube (see below).

You can be more specific using resource fragments. A resource fragment is just what it sounds like — the fragment of a resource. For instance, we will use a resource fragment to configure a configMap. (A ConfigMap is a set of key-value pairs that configure the image per environment, such as dev, QA, test, prod, etc.). You can include a resource fragment in src/main/jkube directory.

xxxxxxxxxx

metadata:

  name: ${project.artifactId}

data:

  application.properties:

    welcome = Hello from Kubernetes in Dev!!!

In the deployments.yml in the same directory, you can specify how to mount this as a volume.

xxxxxxxxxx

spec:

     volumes:

       - name: config

         configMap:

           name: ${project.artifactId}

           items:

             - key: application.properties

               path: application.properties

     containers:

       - volumeMounts:

           - name: config

             mountPath: /deployments/config

On running k8s:resource you will see a <artifactid>-configmap.yml in target\classes\META-INF\jkube\kubernetes. (There seems to be a bug in generating the config map’s resource description. Unlike with other resource fragments, it does not lower case the artifactid for the resource description. So, you should name your artifactid in all lower cases. The problem is unless you follow the Kubernetes naming convention your resource will not deploy.)

Now we are ready to deploy to Kubernetes.

xxxxxxxxxx

mvn install k8s:build k8s:resource k8s:apply

You can check that you have a successful deployment:

To provide access from outside the cluster we change the service type to NodePort:

xxxxxxxxxx

mvn install k8s:build k8s:resource k8s:apply -Djkube.enricher.jkube-service.type=NodePort

You can do this is in one step if you modify your pom:

xxxxxxxxxx

<plugin>

   <groupId>org.eclipse.jkube</groupId>

   <artifactId>kubernetes-maven-plugin</artifactId>

   <version>1.2.0</version>

   <executions>

     <execution>

  <id>jkube</id>

  <goals>

    <goal>apply</goal>

    <goal>resource</goal>

    <goal>build</goal>

   </goals>

  </execution>

 </executions>

  </plugin>

Now you can deploy in one step: mvn install.

Finally, you can clean after yourself by un-deploying the resource: mvn k8s:undeploy.

The source is available on Github. You can get more information on JKube here, here, and here.

Many thanks to Rohan Kumar for his help.