Chapter 6. Camel K trait configuration reference
This chapter provides reference information about advanced features and core capabilities that you can configure on the command line at runtime using traits. Camel K provides feature traits to configure specific features and technologies. Camel K provides platform traits to configure internal Camel K core capabilities.
The Red Hat Integration - Camel K 1.6 includes the OpenShift and Knative profiles. The Kubernetes profile has community-only support. It also includes Java, and YAML DSL support for integrations. Other languages such as XML, Groovy, JavaScript, and Kotlin have community-only support.
This chapter includes the following sections:
Camel K feature traits
Camel K core platform traits
- Section 6.3.1, “Builder Trait”
- Section 6.3.3, “Camel Trait”
- Section 6.3.2, “Container Trait”
- Section 6.3.4, “Dependencies Trait”
- Section 6.3.5, “Deployer Trait”
- Section 6.3.6, “Deployment Trait”
- Section 6.3.7, “Environment Trait”
- Section 6.3.8, “Error Handler Trait”
- Section 6.3.9, “Jvm Trait”
- Section 6.3.10, “Kamelets Trait”
- Section 6.3.11, “Openapi Trait”- Technology Preview
- Section 6.3.12, “Owner Trait”
- Section 6.3.13, “Platform Trait”
- Section 6.3.14, “Quarkus Trait”
6.1. Camel K trait and profile configuration
This section explains the important Camel K concepts of traits and profiles, which are used to configure advanced Camel K features at runtime.
Camel K traits
Camel K traits are advanced features and core capabilities that you can configure on the command line to customize Camel K integrations. For example, this includes feature traits that configure interactions with technologies such as 3scale API Management, Quarkus, Knative, and Prometheus. Camel K also provides internal platform traits that configure important core platform capabilities such as Camel support, containers, dependency resolution, and JVM support.
Camel K profiles
Camel K profiles define the target cloud platforms on which Camel K integrations run. Supported profiles are OpenShift and Knative profiles.
When you run an integration on OpenShift, Camel K uses the Knative profile when OpenShift Serverless is installed on the cluster. Camel K uses the OpenShift profile when OpenShift Serverless is not installed.
You can also specify the profile at runtime using the kamel run --profile option.
Camel K provides useful defaults for all traits, taking into account the target profile on which the integration runs. However, advanced users can configure Camel K traits for custom behavior. Some traits only apply to specific profiles such as OpenShift or Knative. For more details, see the available profiles in each trait description.
Camel K trait configuration
Each Camel trait has a unique ID that you can use to configure the trait on the command line. For example, the following command disables creating an OpenShift Service for an integration:
kamel run --trait service.enabled=false my-integration.yaml
You can also use the -t option to specify traits.
Camel K trait properties
You can use the enabled property to enable or disable each trait. All traits have their own internal logic to determine if they need to be enabled when the user does not activate them explicitly.
Disabling a platform trait may compromise the platform functionality.
Some traits have an auto property, which you can use to enable or disable automatic configuration of the trait based on the environment. For example, this includes traits such as 3scale, Cron, and Knative. This automatic configuration can enable or disable the trait when the enabled property is not explicitly set, and can change the trait configuration.
Most traits have additional properties that you can configure on the command line. For more details, see the descriptions for each trait in the sections that follow.
6.2. Camel K feature traits
6.2.1. Knative Trait
The Knative trait automatically discovers addresses of Knative resources and inject them into the running integration.
The full Knative configuration is injected in the CAMEL_KNATIVE_CONFIGURATION in JSON format. The Camel Knative component will then use the full configuration to configure the routes.
The trait is enabled by default when the Knative profile is active.
This trait is available in the following profiles: Knative.
6.2.1.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait knative.[key]=[value] --trait knative.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| Can be used to inject a Knative complete configuration in JSON format. |
|
|
| List of channels used as source of integration routes. Can contain simple channel names or full Camel URIs. |
|
|
| List of channels used as destination of integration routes. Can contain simple channel names or full Camel URIs. |
|
|
| List of channels used as source of integration routes. |
|
|
| List of endpoints used as destination of integration routes. Can contain simple endpoint names or full Camel URIs. |
|
|
| List of event types that the integration will be subscribed to. Can contain simple event types or full Camel URIs (to use a specific broker different from "default"). |
|
|
| List of event types that the integration will produce. Can contain simple event types or full Camel URIs (to use a specific broker). |
|
|
| Enables filtering on events based on the header "ce-knativehistory". Since this header has been removed in newer versions of Knative, filtering is disabled by default. |
|
|
| Allows binding the integration to a sink via a Knative SinkBinding resource. This can be used when the integration targets a single sink. It’s enabled by default when the integration targets a single sink (except when the integration is owned by a Knative source). |
|
|
| Enable automatic discovery of all trait properties. |
6.2.2. Knative Service Trait
The Knative Service trait allows to configure options when running the integration as Knative service instead of a standard Kubernetes Deployment.
Running integrations as Knative Services adds auto-scaling (and scaling-to-zero) features, but those features are only meaningful when the routes use a HTTP endpoint consumer.
This trait is available in the following profiles: Knative.
6.2.2.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait knative-service.[key]=[value] --trait knative-service.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
|
Configures the Knative autoscaling class property (e.g. to set Refer to the Knative documentation for more information. |
|
|
|
Configures the Knative autoscaling metric property (e.g. to set Refer to the Knative documentation for more information. |
|
|
| Sets the allowed concurrency level or CPU percentage (depending on the autoscaling metric) for each Pod. Refer to the Knative documentation for more information. |
|
|
| The minimum number of Pods that should be running at any time for the integration. It’s zero by default, meaning that the integration is scaled down to zero when not used for a configured amount of time. Refer to the Knative documentation for more information. |
|
|
| An upper bound for the number of Pods that can be running in parallel for the integration. Knative has its own cap value that depends on the installation. Refer to the Knative documentation for more information. |
|
|
| Automatically deploy the integration as Knative service when all conditions hold:
|
6.2.3. Prometheus Trait
The Prometheus trait configures a Prometheus-compatible endpoint. It also creates a PodMonitor resource, so that the endpoint can be scraped automatically, when using the Prometheus operator.
The metrics are exposed using MicroProfile Metrics.
The creation of the PodMonitor resource requires the Prometheus Operator custom resource definition to be installed. You can set pod-monitor to false for the Prometheus trait to work without the Prometheus Operator.
The Prometheus trait is disabled by default.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
6.2.3.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait prometheus.[key]=[value] --trait prometheus.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
|
Whether a |
|
|
|
The |
6.2.4. Pdb Trait
The PDB trait allows to configure the PodDisruptionBudget resource for the Integration pods.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
6.2.4.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait pdb.[key]=[value] --trait pdb.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
|
The number of pods for the Integration that must still be available after an eviction. It can be either an absolute number or a percentage. Only one of |
|
|
|
The number of pods for the Integration that can be unavailable after an eviction. It can be either an absolute number or a percentage (default |
6.2.5. Pull Secret Trait
The Pull Secret trait sets a pull secret on the pod, to allow Kubernetes to retrieve the container image from an external registry.
The pull secret can be specified manually or, in case you’ve configured authentication for an external container registry on the IntegrationPlatform, the same secret is used to pull images.
It’s enabled by default whenever you configure authentication for an external container registry, so it assumes that external registries are private.
If your registry does not need authentication for pulling images, you can disable this trait.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
6.2.5.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait pull-secret.[key]=[value] --trait pull-secret.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
|
The pull secret name to set on the Pod. If left empty this is automatically taken from the |
|
|
|
When using a global operator with a shared platform, this enables delegation of the |
|
|
|
Automatically configures the platform registry secret on the pod if it is of type |
6.2.6. Route Trait
The Route trait can be used to configure the creation of OpenShift routes for the integration.
The certificate and key contents may be sourced either from the local filesystem or in a Openshift secret object. The user may use the parameters ending in -secret (example: tls-certificate-secret) to reference a certificate stored in a secret. Parameters ending in -secret have higher priorities and in case the same route parameter is set, for example: tls-key-secret and tls-key, then tls-key-secret is used. The recommended approach to set the key and certificates is to use secrets to store their contents and use the following parameters to reference them: tls-certificate-secret, tls-key-secret, tls-ca-certificate-secret, tls-destination-ca-certificate-secret See the examples section at the end of this page to see the setup options.
This trait is available in the following profiles: OpenShift.
6.2.6.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait route.[key]=[value] --trait route.[key2]=[value2] integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| To configure the host exposed by the route. |
|
|
|
The TLS termination type, like Refer to the OpenShift route documentation for additional information. |
|
|
| The TLS certificate contents. Refer to the OpenShift route documentation for additional information. |
|
|
| The secret name and key reference to the TLS certificate. The format is "secret-name[/key-name]", the value represents the secret name, if there is only one key in the secret it will be read, otherwise you can set a key name separated with a "/". Refer to the OpenShift route documentation for additional information. |
|
|
| The TLS certificate key contents. Refer to the OpenShift route documentation for additional information. |
|
|
| The secret name and key reference to the TLS certificate key. The format is "secret-name[/key-name]", the value represents the secret name, if there is only one key in the secret it will be read, otherwise you can set a key name separated with a "/". Refer to the OpenShift route documentation for additional information. |
|
|
| The TLS CA certificate contents. Refer to the OpenShift route documentation for additional information. |
|
|
| The secret name and key reference to the TLS CA certificate. The format is "secret-name[/key-name]", the value represents the secret name, if there is only one key in the secret it will be read, otherwise you can set a key name separated with a "/". Refer to the OpenShift route documentation for additional information. |
|
|
| The destination CA certificate provides the contents of the ca certificate of the final destination. When using reencrypt termination this file should be provided in order to have routers use it for health checks on the secure connection. If this field is not specified, the router may provide its own destination CA and perform hostname validation using the short service name (service.namespace.svc), which allows infrastructure generated certificates to automatically verify. Refer to the OpenShift route documentation for additional information. |
|
|
| The secret name and key reference to the destination CA certificate. The format is "secret-name[/key-name]", the value represents the secret name, if there is only one key in the secret it will be read, otherwise you can set a key name separated with a "/". Refer to the OpenShift route documentation for additional information. |
|
|
|
To configure how to deal with insecure traffic, e.g. Refer to the OpenShift route documentation for additional information. |
6.2.6.2. Examples
These examples uses secrets to store the certificates and keys to be referenced in the integrations. Read Openshift route documentation for detailed information about routes. The PlatformHttpServer.java is the integration example.
As a requirement to run these examples, you should have a secret with a key and certificate.
6.2.6.2.1. Generate a self-signed certificate and create a secret
openssl genrsa -out tls.key openssl req -new -key tls.key -out csr.csr -subj "/CN=my-server.com" openssl x509 -req -in csr.csr -signkey tls.key -out tls.crt oc create secret tls my-combined-certs --key=tls.key --cert=tls.crt
6.2.6.2.2. Making an HTTP request to the route
For all examples, you can use the following curl command to make an HTTP request. It makes use of inline scripts to retrieve the openshift namespace and cluster base domain, if you are using a shell which doesn’t support these inline scripts, you should replace the inline scripts with the values of your actual namespace and base domain.
curl -k https://platform-http-server-`oc config view --minify -o 'jsonpath={..namespace}'`.`oc get dnses/cluster -ojsonpath='{.spec.baseDomain}'`/hello?name=Camel-KTo add an edge route using secrets, use the parameters ending in
-secretto set the secret name which contains the certificate. This route example trait references a secret namedmy-combined-certswhich contains two keys namedtls.keyandtls.crt.kamel run --dev PlatformHttpServer.java -t route.tls-termination=edge -t route.tls-certificate-secret=my-combined-certs/tls.crt -t route.tls-key-secret=my-combined-certs/tls.key
To add a passthrough route using secrets, the TLS is setup in the integration pod, the keys and certificates should be visible in the running integration pod, to achieve this we are using the
--resourcekamel parameter to mount the secret in the integration pod, then we use some camel quarkus parameters to reference these certificate files in the running pod, they start with-p quarkus.http.ssl.certificate. This route example trait references a secret namedmy-combined-certswhich contains two keys namedtls.keyandtls.crt.kamel run --dev PlatformHttpServer.java --resource secret:my-combined-certs@/etc/ssl/my-combined-certs -p quarkus.http.ssl.certificate.file=/etc/ssl/my-combined-certs/tls.crt -p quarkus.http.ssl.certificate.key-file=/etc/ssl/my-combined-certs/tls.key -t route.tls-termination=passthrough -t container.port=8443
To add a reencrypt route using secrets, the TLS is setup in the integration pod, the keys and certificates should be visible in the running integration pod, to achieve this we are using the
--resourcekamel parameter to mount the secret in the integration pod, then we use some camel quarkus parameters to reference these certificate files in the running pod, they start with-p quarkus.http.ssl.certificate. This route example trait references a secret namedmy-combined-certswhich contains two keys namedtls.keyandtls.crt.kamel run --dev PlatformHttpServer.java --resource secret:my-combined-certs@/etc/ssl/my-combined-certs -p quarkus.http.ssl.certificate.file=/etc/ssl/my-combined-certs/tls.crt -p quarkus.http.ssl.certificate.key-file=/etc/ssl/my-combined-certs/tls.key -t route.tls-termination=reencrypt -t route.tls-destination-ca-certificate-secret=my-combined-certs/tls.crt -t route.tls-certificate-secret=my-combined-certs/tls.crt -t route.tls-key-secret=my-combined-certs/tls.key -t container.port=8443
To add a reencrypt route using a specific certificate from a secret for the route and Openshift service serving certificates for the integration endpoint. This way the Openshift service serving certificates is set up only in the integration pod. The keys and certificates should be visible in the running integration pod, to achieve this we are using the
--resourcekamel parameter to mount the secret in the integration pod, then we use some camel quarkus parameters to reference these certificate files in the running pod, they start with-p quarkus.http.ssl.certificate. This route example trait references a secret namedmy-combined-certswhich contains two keys namedtls.keyandtls.crt.kamel run --dev PlatformHttpServer.java --resource secret:cert-from-openshift@/etc/ssl/cert-from-openshift -p quarkus.http.ssl.certificate.file=/etc/ssl/cert-from-openshift/tls.crt -p quarkus.http.ssl.certificate.key-file=/etc/ssl/cert-from-openshift/tls.key -t route.tls-termination=reencrypt -t route.tls-certificate-secret=my-combined-certs/tls.crt -t route.tls-key-secret=my-combined-certs/tls.key -t container.port=8443
Then you should annotate the integration service to inject the Openshift service serving certificates
oc annotate service platform-http-server service.beta.openshift.io/serving-cert-secret-name=cert-from-openshift
To add an edge route using a certificate and a private key provided from your local filesystem. This example uses inline scripts to read the certificate and private key file contents, then remove all new line characters, (this is required to set the certificate as parameter’s values), so the values are in a single line.
kamel run PlatformHttpServer.java --dev -t route.tls-termination=edge -t route.tls-certificate="$(cat tls.crt|awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}')" -t route.tls-key="$(cat tls.key|awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}')"
6.2.7. Service Trait
The Service trait exposes the integration with a Service resource so that it can be accessed by other applications (or integrations) in the same namespace.
It’s enabled by default if the integration depends on a Camel component that can expose a HTTP endpoint.
This trait is available in the following profiles: Kubernetes, OpenShift.
6.2.7.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait service.[key]=[value] --trait service.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| To automatically detect from the code if a Service needs to be created. |
|
|
| Enable Service to be exposed as NodePort |
6.3. Camel K platform traits
6.3.1. Builder Trait
The builder trait is internally used to determine the best strategy to build and configure IntegrationKits.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The builder trait is a platform trait: disabling it may compromise the platform functionality.
6.3.1.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait builder.[key]=[value] --trait builder.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| Enable verbose logging on build components that support it (e.g., OpenShift build pod). Kaniko and Buildah are not supported. |
|
|
| A list of properties to be provided to the build task |
6.3.2. Container Trait
The Container trait can be used to configure properties of the container where the integration will run.
It also provides configuration for Services associated to the container.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The container trait is a platform trait: disabling it may compromise the platform functionality.
6.3.2.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait container.[key]=[value] --trait container.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| |
|
|
| The minimum amount of CPU required. |
|
|
| The minimum amount of memory required. |
|
|
| The maximum amount of CPU required. |
|
|
| The maximum amount of memory required. |
|
|
| Can be used to enable/disable exposure via kubernetes Service. |
|
|
|
To configure a different port exposed by the container (default |
|
|
|
To configure a different port name for the port exposed by the container (default |
|
|
|
To configure under which service port the container port is to be exposed (default |
|
|
|
To configure under which service port name the container port is to be exposed (default |
|
|
|
The main container name. It’s named |
|
|
| The main container image |
|
|
|
ProbesEnabled enable/disable probes on the container (default |
|
|
| Number of seconds after the container has started before liveness probes are initiated. |
|
|
| Number of seconds after which the probe times out. Applies to the liveness probe. |
|
|
| How often to perform the probe. Applies to the liveness probe. |
|
|
| Minimum consecutive successes for the probe to be considered successful after having failed. Applies to the liveness probe. |
|
|
| Minimum consecutive failures for the probe to be considered failed after having succeeded. Applies to the liveness probe. |
|
|
| Number of seconds after the container has started before readiness probes are initiated. |
|
|
| Number of seconds after which the probe times out. Applies to the readiness probe. |
|
|
| How often to perform the probe. Applies to the readiness probe. |
|
|
| Minimum consecutive successes for the probe to be considered successful after having failed. Applies to the readiness probe. |
|
|
| Minimum consecutive failures for the probe to be considered failed after having succeeded. Applies to the readiness probe. |
6.3.3. Camel Trait
The Camel trait can be used to configure versions of Apache Camel K runtime and related libraries, it cannot be disabled.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The camel trait is a platform trait: disabling it may compromise the platform functionality.
6.3.3.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait camel.[key]=[value] --trait camel.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
6.3.4. Dependencies Trait
The Dependencies trait is internally used to automatically add runtime dependencies based on the integration that the user wants to run.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The dependencies trait is a platform trait: disabling it may compromise the platform functionality.
6.3.4.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait dependencies.[key]=[value] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
6.3.5. Deployer Trait
The deployer trait can be used to explicitly select the kind of high level resource that will deploy the integration.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The deployer trait is a platform trait: disabling it may compromise the platform functionality.
6.3.5.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait deployer.[key]=[value] --trait deployer.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
|
Allows to explicitly select the desired deployment kind between |
6.3.6. Deployment Trait
The Deployment trait is responsible for generating the Kubernetes deployment that will make sure the integration will run in the cluster.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The deployment trait is a platform trait: disabling it may compromise the platform functionality.
6.3.6.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait deployment.[key]=[value] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
6.3.7. Environment Trait
The environment trait is used internally to inject standard environment variables in the integration container, such as NAMESPACE, POD_NAME and others.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The environment trait is a platform trait: disabling it may compromise the platform functionality.
6.3.7.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait environment.[key]=[value] --trait environment.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
|
Enables injection of |
6.3.8. Error Handler Trait
The error-handler is a platform trait used to inject Error Handler source into the integration runtime.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The error-handler trait is a platform trait: disabling it may compromise the platform functionality.
6.3.8.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait error-handler.[key]=[value] --trait error-handler.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| The error handler ref name provided or found in application properties |
6.3.9. Jvm Trait
The JVM trait is used to configure the JVM that runs the integration.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The jvm trait is a platform trait: disabling it may compromise the platform functionality.
6.3.9.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait jvm.[key]=[value] --trait jvm.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| Activates remote debugging, so that a debugger can be attached to the JVM, e.g., using port-forwarding |
|
|
| Suspends the target JVM immediately before the main class is loaded |
|
|
|
Prints the command used the start the JVM in the container logs (default |
|
|
|
Transport address at which to listen for the newly launched JVM (default |
|
|
| A list of JVM options |
|
|
|
Additional JVM classpath (use |
6.3.9.2. Examples
Include an additional classpath to the
Integration:$ kamel run -t jvm.classpath=/path/to/my-dependency.jar:/path/to/another-dependency.jar ...
6.3.10. Kamelets Trait
The kamelets trait is a platform trait used to inject Kamelets into the integration runtime.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The kamelets trait is a platform trait: disabling it may compromise the platform functionality.
6.3.10.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait kamelets.[key]=[value] --trait kamelets.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| Automatically inject all referenced Kamelets and their default configuration (enabled by default) |
|
|
| Comma separated list of Kamelet names to load into the current integration |
6.3.11. Openapi Trait
The OpenAPI DSL trait is internally used to allow creating integrations from a OpenAPI specs.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The openapi trait is a platform trait: disabling it may compromise the platform functionality.
6.3.11.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait openapi.[key]=[value] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
6.3.12. Owner Trait
The Owner trait ensures that all created resources belong to the integration being created and transfers annotations and labels on the integration onto these owned resources.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The owner trait is a platform trait: disabling it may compromise the platform functionality.
6.3.12.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait owner.[key]=[value] --trait owner.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| The set of annotations to be transferred |
|
|
| The set of labels to be transferred |
6.3.13. Platform Trait
The platform trait is a base trait that is used to assign an integration platform to an integration.
In case the platform is missing, the trait is allowed to create a default platform. This feature is especially useful in contexts where there’s no need to provide a custom configuration for the platform (e.g. on OpenShift the default settings work, since there’s an embedded container image registry).
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The platform trait is a platform trait: disabling it may compromise the platform functionality.
6.3.13.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait platform.[key]=[value] --trait platform.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
|
|
| To create a default (empty) platform when the platform is missing. |
|
|
| Indicates if the platform should be created globally in the case of global operator (default true). |
|
|
| To automatically detect from the environment if a default platform can be created (it will be created on OpenShift only). |
6.3.14. Quarkus Trait
The Quarkus trait activates the Quarkus runtime.
It’s enabled by default.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
The quarkus trait is a platform trait: disabling it may compromise the platform functionality.
6.3.14.1. Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait quarkus.[key]=[value] --trait quarkus.[key2]=[value2] Integration.java
The following configuration options are available:
| Property | Type | Description |
|---|---|---|
|
|
| Can be used to enable or disable a trait. All traits share this common property. |
6.3.14.2. Supported Camel Components
When running with Quarkus enabled, Camel K only supports those Camel components that are available as Camel Quarkus Extensions. You can see the list of extensions from the Camel Quarkus documentation.
