Kubernetes-Native Development with Quarkus and Eclipse JKube
This article explains what Eclipse JKube Remote Development is and how can it help developers build Kubernetes-native applications with Quarkus.
As mentioned in my previous article, Kubernetes-native inner loop development with Quarkus, microservices don’t exist in a vacuum. They typically communicate with other services, such as databases, message brokers, or other microservices. Because of this distributed nature, developers often struggle to develop (and test!) individual microservices that are part of a larger system.
The previous article examines some common inner-loop development cycle challenges and shows how Quarkus, combined with other technologies, can help solve some of the challenges. Eclipse JKube Remote Development was not one of the technologies mentioned because it did not exist when the article was written. Now that it does exist, it certainly belongs to be mentioned.
Eclipse JKube provides tools that help bring Java applications to Kubernetes and OpenShift. It is a collection of plugins and libraries for building container images and generating and deploying Kubernetes or OpenShift manifests.
Eclipse JKube Remote Development is a preview feature first released as part of Eclipse JKube 1.10. This new feature is centered around Kubernetes, allowing developers the ability to run and debug Java applications from a local machine while connected to a Kubernetes cluster. It is logically similar to placing a local development machine inside a Kubernetes cluster. Requests from the cluster can flow into a local development machine, while outgoing requests can flow back onto the cluster.
We previously used Skupper as a proxy to connect a Kubernetes cluster to a local machine. As of the 1.10 release, Eclipse JKube removes the need to use Skupper or install any of its components on the Kubernetes cluster or your local machine. Eclipse JKube handles all the underlying communication to and from the Kubernetes cluster by mapping Kubernetes
Service ports to and from the local machine.
The new Eclipse JKube Remote Development feature can make the Quarkus Superheroes example very interesting. If we wanted to reproduce the scenario shown in Figure 1, all we’d have to do is re-configure the
rest-fights application locally a little bit and then run it in Quarkus dev mode.
First, deploy the Quarkus Superheroes to Kubernetes. Then, add the Eclipse JKube configuration into the
<plugins> section in the
<plugin> <groupId>org.eclipse.jkube</groupId> <artifactId>openshift-maven-plugin</artifactId> <version>1.11.0</version> <configuration> <remoteDevelopment> <localServices> <localService> <serviceName>rest-fights</serviceName> <port>8082</port> </localService> </localServices> <remoteServices> <remoteService> <hostname>rest-heroes</hostname> <port>80</port> <localPort>8083</localPort> </remoteService> <remoteService> <hostname>rest-villains</hostname> <port>80</port> <localPort>8084</localPort> </remoteService> <remoteService> <hostname>apicurio</hostname> <port>8080</port> <localPort>8086</localPort> </remoteService> <remoteService> <hostname>fights-kafka</hostname> <port>9092</port> </remoteService> <remoteService> <hostname>otel-collector</hostname> <port>4317</port> </remoteService> </remoteServices> </remoteDevelopment> </configuration> </plugin>
Version 1.11.0 of the
This configuration tells OpenShift to proxy requests going to the OpenShift
rest-fights on port
8082 to the local machine on the same port. Additionally, it forwards the local machine ports
4317 back to the OpenShift cluster and binds them to various OpenShift Services.
Now that the configuration is in place you need to open two terminals in the
rest-fights directory. In the first terminal, run
./mvnw oc:remote-dev to start the remote dev proxy service. Once that starts, move to the second terminal and run
./mvnw quarkus:dev \ -Dkafka.bootstrap.servers=PLAINTEXT://localhost:9092 \ -Dmp.messaging.connector.smallrye-kafka.apicurio.registry.url=http://localhost:8086
This command starts up a local instance of the
rest-fights application in Quarkus dev mode. Requests from the cluster will come into your local machine. The local application will connect to other services back on the cluster, such as the
rest-heroes applications, the Kafka broker, the Apicurio Registry instance, and the OpenTelemetry collector. With this configuration, Quarkus Dev Services will spin up a local MongoDB instance for the locally-running application, illustrating how you could combine local services with other services available on the remote cluster.
You can live code changes to the local application while requests flow through the Kubernetes cluster, down to your local machine, and then back to the cluster! You could even enable continuous testing while you make local changes to ensure your changes do not break anything.
The main difference between Quarkus Remote Development and Eclipse JKube Remote Development is that, with Quarkus Remote Development, the application is running in the remote Kubernetes cluster. Local changes are synchronized between the local machine and the remote environment. With JKube Remote Development, the application runs on the local machine, and traffic flows from the cluster, into the local machine, and back out to the cluster.
As you can see, Eclipse JKube Remote Development compliments the Quarkus Developer Joy story quite well. It allows you to easily combine the power of Quarkus with Kubernetes to help create a better developer experience, whether local, distributed, or somewhere in between.