Running on Kubernetes

Now that we have our application built, let's move it into containers and into the cloud.

Installing the Kubernetes Extension

Quarkus offers the ability to automatically generate Kubernetes resources based on sane defaults and user supplied configuration. We'll also need the Jib extension to build the image for us.

Run the following command to add the Kubernetes extension to the project:
mvn quarkus:add-extension -Dextensions="kubernetes,jib"

Updating the Application Properties

Before building and deploying the container image, we need to update the application properties for our configuration. Edit src/main/resources/ and enter the following values:
Note: These values are specific to a minikube installation. Consult the extension documentation for more information on other possible configuration values and how to adapt them for your cluster.

Preparing for Deployment

The container image needs to be available to the Kubernetes cluster in order for a pod to be created from it. It's possible to use the extensions to push to a hosted repository such as Docker Hub or However, for simplicity when using a minikube installation, we'll simply push it directly into the minikube Docker daemon.
Minikube provides a command to export the necessary configuration to use its Docker daemon. You'll need to add that information to your environment before running the build commands. This can be done by running:
eval $(minikube docker-env)

Building & Deploying the Container Image

An extra flag is necessary to the package goal to trigger the image build and deployment:
mvn clean package -Dquarkus.kubernetes.deploy=true
You'll see output similar to the following to indicate the image build took place:
[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Starting container image build
[WARNING] [io.quarkus.container.image.jib.deployment.JibProcessor] Base image 'fabric8/java-alpine-openjdk11-jre' does not use a specific image digest - build may not be reproducible
[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] The base image requires auth. Trying again for fabric8/java-alpine-openjdk11-jre...
[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Using base image with digest: sha256:b459cc59d6c7ddc9fd52f981fc4c187f44a401f2433a1b4110810d2dd9e98a07
[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Container entrypoint set to [java, -Djava.util.logging.manager=org.jboss.logmanager.LogManager, -jar, quarkus-run.jar]
[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Created container image getting-started:1.0 (sha256:79b5aca19a9f23cd48cd8e6401df88886364e929560d0b8f2b47c1a0b6d5575d)
[INFO] [io.quarkus.kubernetes.deployment.KubernetesDeployer] Deploying to kubernetes server: in namespace: default.
[INFO] [io.quarkus.kubernetes.deployment.KubernetesDeployer] Applied: Service getting-started.
[INFO] [io.quarkus.kubernetes.deployment.KubernetesDeployer] Applied: Deployment getting-started.
[INFO] [io.quarkus.deployment.QuarkusAugmentor] Quarkus augmentation completed in 13998ms

Verifying the Deployment

Once the deployment has finished, you can see that the container has been created by looking for the pod in your cluster:
kubectl get pods
You should see output similar to the following (the exact name of the pod will vary):
getting-started-6cc5b7f575-kszx8 1/1 Running 0 47m
If you're using minikube, you can find the application URL by running:
minikube service list

The URL will be the entry with the name getting-started. For example:

|  NAMESPACE  |      NAME       | TARGET PORT  |            URL             |
| default     | getting-started | http/8080    | |
| default     | kubernetes      | No node port |                            |
| kube-system | kube-dns        | No node port |                            |
Using that URL, use the same endpoint as before to test that the application is running:
Daniel Oh
Daniel Oh
Senior Principal Developer Advocate
Daniel Oh is a Senior Principal Developer Advocate at Red Hat. He works to evangelize building cloud-native microservices and serverless functions with cloud-native runtimes to developers. He also continues to contribute to various open-source cloud projects and ecosystems as a Cloud Native Computing Foundation (CNCF) ambassador for accelerating DevOps adoption in enterprises. Daniel also speaks at technical seminars, workshops, and meetups to elaborate on new emerging technologies for enterprise developers, SREs, platform engineers, and DevOps teams.