A Kubernetes manifest defines resources to apply to a cluster. It can describe an application Deployment, the Service that exposes it, and supporting resources. Writing these definitions by hand can be tedious and error-prone; Quarkus can generate complete manifests from an application's build configuration. section 11.3.3 section 11.3.1
Add `quarkus-kubernetes` to generate Kubernetes resources, `quarkus-openshift` for OpenShift-specific resources, or `quarkus-knative` for a serverless target. Quarkus uses Dekorate to generate sensible defaults. A build writes YAML and JSON manifests under `target/kubernetes` (`build/kubernetes` with Gradle), with filenames such as `kubernetes.yml`. When an image extension is also present, the generated image reference is adjusted to match the image built or pushed for the application. section 11.3.1 section 11.3.3
Listing 11.11 Simplified version of the generated kubernetes.yml
apiVersion: v1
kind: Service
...
spec:
ports:
- name: grpc
port: 9000
protocol: TCP
targetPort: 9000
- name: http
port: 80
protocol: TCP
targetPort: 8083
---
apiVersion: apps/v1
kind: Deployment
...
spec:
...
spec:
containers:
- env:
...
image: quay.io/quarkus-in-action/inventory-service:1.0.0
imagePullPolicy: Always
Inspect the simplified `kubernetes.yml`: its Service exposes gRPC and HTTP ports, while its Deployment names the container image to run. section 11.3.3
Customize generated resources with Quarkus properties before building. Options include deployment kind, replica count, namespace, labels, annotations, environment variables, and volume mounts. These properties are processed when the image and manifests are built: changing them only when applying the manifest, or overriding them at application startup, does not change the generated resources. To combine your own resource definitions with generated ones, place `kubernetes.yml` in `src/main/kubernetes`; corresponding OpenShift, Knative, and JSON filenames are also supported. section 11.3.2
# The application resource type quarkus.kubernetes.deployment-kind=Deployment|StatefulSet|Job|CronJob # The number of replicas quarkus.kubernetes.replicas=5 # The namespace for the resources quarkus.kubernetes.namespace=custom-namespace # Annotations to add to the resources quarkus.kubernetes.annotations.ANNOTATION_KEY=annotation-value # Labels to add to the resources quarkus.kubernetes.labels.LABEL_KEY=label-value # Environment variables, env-var-key translates to ENV_VAR_KEY variable quarkus.kubernetes.env.vars.ENV_VAR_KEY=env-var-value # Volume mounts quarkus.kubernetes.mounts.MOUNT_KEY.name=name-of-the-volume-to-mount quarkus.kubernetes.mounts.MOUNT_KEY.path=/path/where/to/mount
Use these property examples to identify build-time controls for the resource kind, replicas, namespace, metadata, environment, and mounts. section 11.3.2
Build and apply an application manifest
For an Inventory service, run `quarkus ext add kubernetes`, then `quarkus build`. Inspect `target/kubernetes/kubernetes.yml`, especially its ports and image reference, then apply it with `kubectl apply -f inventory-service/target/kubernetes/kubernetes.yml`. Check the resulting pods with `kubectl get pods`. If its database runs in the cluster, configure the generated environment variable to use the database Service address rather than `localhost`, and rebuild before applying. section 11.3.3
The same workflow applies to OpenShift: rebuild each service's generated `openshift.yml`, then use `oc apply -f target/kubernetes/openshift.yml`. Ensure its image reference points to an image containing your changes; applying a changed manifest alone does not update application code in an unchanged image. A single manifest can also deploy dependent services and ConfigMaps. To remove resources defined in such a file, use `oc delete -f` with that manifest; ConfigMaps are not removed by `oc delete all --all`. section 11.6.3 section 11.6.2
