Skip to content


Repository files navigation

Deploying a Knative service powered by Vert.x

This how-to shows you how to deploy a Vert.x-based Knative service.

What you will build

  • You will write a service that accepts Asciidoc text, and produces a HTML rendering with Asciidoctor.

  • This service will be written in Kotlin.

  • A container image with the function will be created with Jib.

  • This service will be deployed with Knative/serving.

What you need

  • A text editor or IDE

  • Java 8 higher

  • Maven or Gradle

  • Docker

  • A working Kubernetes cluster with Knative/serving.

What is a Knative service and why is Vert.x a good match?

Knative starts container images (3 by default) to respond to requests, and scales down to 0 after some delay without traffic. A "function" served by Knative/serving is simply a HTTP service written in any language, and packaged as a container image.

Vert.x is ideal for writing Knative services on the JVM, because:

  1. Vert.x applications start very fast since there is no magic happening at run time,

  2. GraalVM can be used compilation to further reduce the startup and memory footprint (out of the scope of this how-to),

  3. Vert.x applications are resource-efficient and remain responsive even under heavy load,

  4. Vert.x offers a large ecosystem of reactive clients to other middlewares (databases, messaging, etc),

  5. a main method / function suffices to bootstrap a Vert.x application!

Create a project

The code of this project contains Maven and Gradle build files that are functionally equivalent.

With Gradle

Here is the content of the build.gradle.kts file that you should be using:

  1. We need Kotlin, vertx-web and asciidoctorj.

  2. The Gradle application plugin allows us to run the application locally with the run command.

  3. Jib configuration to produce an image.

With Maven

Here is the content of the pom.xml file that you should be using:

  1. We need Kotlin, vertx-web and asciidoctorj.

  2. Allows running with mvn exec:java.

  3. Jib configuration to produce an image.

Writing the service

The service exposes a HTTP server. Asciidoc is passed to the function through HTTP POST requests. For each request, Asciidoctor is used to perform the conversion to HTML:

  1. We create a Vert.x context.

  2. We configure a Asciidoctor render.

  3. We install a HTTP request body handler, so we can just process the whole body rather than manually assemble buffers.

  4. For each request, we render the HTML from the Asciidoc.

We could have written the Vert.x code as a verticle, but doing so in the main function reduces the boilerplate code since we would only be deploying a single verticle here anyway.

Running the function locally

We can easily test that the service works:

  1. from your IDE, run the main function, or

  2. with Gradle: ./gradlew run (Linux, macOS) or gradle run (Windows).

  3. with Maven: mvn compile exec:java.

You can then upload the content of a Asciidoc file, like the README.adoc file at the root of this repository. With HTTPie, you would run a command similar to:

$ http POST :8080/ @README.adoc

Preparing your cluster

The commands in this how-to assume that you have installed Knative with Minikube.

Building your container image

The Jib plugin in your Gradle or Maven build will automatically assemble a container image with the correct entry point to run the application, and port 8080 being exposed. The container image then has to be pushed to your favorite repository.

If you are using Minikube, you can directly build and tag the container image:

$ eval $(minikube docker-env)
$ ./gradlew jibDockerBuild    # or mvn package jib:dockerBuild

Docker should then list the image:

$ docker image ls
REPOSITORY                                    TAG       IMAGE ID
dev.local/jponge/knative-vertx-asciidoctor    latest    4ca7aafd590c
dev.local/jponge/knative-vertx-asciidoctor    v1        4ca7aafd590c

Describing a service for Knative

Here is the descriptor in file service.yaml for exposing our service with Knative/serving:


We can then apply the configuration and check that the service is available:

$ kubectl apply -f service.yaml created
$ kubectl get ksvc
NAME                        DOMAIN                                          LATESTCREATED                     LATESTREADY                       READY     REASON
knative-vertx-asciidoctor   knative-vertx-asciidoctor-jc4sw   knative-vertx-asciidoctor-pztr6   Unknown

Testing the service exposed by Knative

In our case the service is exposed under the domain. It is available via the istio-ingressgateway service (check all available services with kubectl get services --all-namespaces).

With Minikube, making a request to the function is similar to:

$ http POST $(minikube ip):31380 '' @README.adoc

You should see HTML in the response. You should also see pods for your service:

$ kubectl get pods
NAME                                                          READY   STATUS    RESTARTS   AGE
knative-vertx-asciidoctor-mlhwq-deployment-5cc999bdb7-jx2ff   3/3     Running   0          2m5s

After a while, you can check that the Knative auto-scaler has removed all pods:

$ kubectl get pods
No resources found.

Issue a new request, and see that new pods have been created again.


  • We wrote a Knative service with Vert.x and Kotlin that renders Asciidoc text to HTML.

  • We built a container image.

  • We deployed this service with Knative/serving.


Deploying a Knative service powered by Vert.x







No releases published


No packages published