This is an automated email from the ASF dual-hosted git repository. davsclaus pushed a commit to branch feature/CAMEL-23722-cli-docs-restructure in repository https://gitbox.apache.org/repos/asf/camel.git
commit baf2ee2249999393f5dc2e7f3d61576cee6b37f0 Author: Claus Ibsen <[email protected]> AuthorDate: Tue Jun 9 20:10:16 2026 +0200 CAMEL-23722: Tighten Kubernetes Plugin page prose (1758 -> 749 lines) Co-Authored-By: Claude <[email protected]> Signed-off-by: Claus Ibsen <[email protected]> --- .../modules/ROOT/pages/camel-jbang-kubernetes.adoc | 1211 ++------------------ 1 file changed, 101 insertions(+), 1110 deletions(-) diff --git a/docs/user-manual/modules/ROOT/pages/camel-jbang-kubernetes.adoc b/docs/user-manual/modules/ROOT/pages/camel-jbang-kubernetes.adoc index a6badd60fe63..d5ba00f683b3 100644 --- a/docs/user-manual/modules/ROOT/pages/camel-jbang-kubernetes.adoc +++ b/docs/user-manual/modules/ROOT/pages/camel-jbang-kubernetes.adoc @@ -1,103 +1,38 @@ = Camel Kubernetes plugin -This plugin helps you to get started with running Camel applications on Kubernetes. -Please make sure to meet these prerequisites for running Camel integrations on Kubernetes: +Export, build, push, and deploy Camel integrations to Kubernetes — develop locally with Camel CLI, then promote to any cluster. -* Install a Kubernetes command line tooling (https://kubernetes.io/docs/tasks/tools/#kubectl[kubectl]) -* Connect to a running Kubernetes cluster where you want to run the Camel integration +Prerequisites: https://kubernetes.io/docs/tasks/tools/#kubectl[kubectl] installed, connected to a Kubernetes cluster (remote, https://kind.sigs.k8s.io/docs/user/quick-start/[Kind], or https://minikube.sigs.k8s.io/docs/start/[Minikube]). -You can connect to a remote Kubernetes cluster or set up a local cluster. -To set up a local Kubernetes cluster, you have a variety of options. - -* https://kind.sigs.k8s.io/docs/user/quick-start/[Kind] -* https://minikube.sigs.k8s.io/docs/start/[Minikube] - -Camel CLI is able to interact with any of these Kubernetes platforms (remote or local). - -Running Camel routes on Kubernetes is quite simple with Camel CLI. -In fact, you can develop and test your Camel route locally with Camel CLI and then promote the same source to running it as an integration on Kubernetes. - -The Camel CLI Kubernetes functionality is provided as a command plugin. -This means you need to enable the `kubernetes` plugin first to use the subcommands in Camel CLI. +Enable the plugin: [source,bash] ---- camel plugin add kubernetes ---- -You should see the `kubernetes` plugin listed as an installed plugin. - -[source,bash] ----- -camel plugin get ----- - -[source,bash] ----- - NAME COMMAND DEPENDENCY DESCRIPTION - kubernetes kubernetes org.apache.camel:camel-jbang-plugin-kubernetes Run Camel applications on Kubernetes ----- - -Now Camel CLI is able to run the subcommands offered by the plugin. -You can inspect the help page to see the list of available plugin subcommands. - -[source,bash] ----- -camel kubernetes --help ----- +TIP: Run `camel kubernetes --help` to see all subcommands. == Kubernetes export -The Kubernetes plugin works with the Camel CLI export functionality. -The project export generates a proper Maven/Gradle project following one of the available runtime types Quarkus, SpringBoot or camel-main. - -In case you export the project with the Kubernetes plugin the exported project holds all information (e.g. sources, properties, dependencies, etc.) and is ready to build, push and deploy the application to Kubernetes, too. -The export generates a Kubernetes manifest (kubernetes.yml) that holds all resources (e.g. Deployment, Service, ConfigMap) required to run the application on Kubernetes. - -You can create a project export with the following command. +Export a Maven project with a Kubernetes manifest (`kubernetes.yml`) containing Deployment, Service, ConfigMap, and other resources: [source,bash] ---- camel kubernetes export route.yaml --dir some/path/to/project ---- -The command receives one or more source files (e.g. Camel routes), and performs the export. -As a result, you will find the Maven/Gradle project sources generated into the given project path. - -The default runtime of the project is Quarkus. -You can adjust the runtime with an additional command option `--runtime=quarkus`. - -If you want to run this application on Kubernetes, you need to build the container image, push it to a registry and deploy the application to Kubernetes. - -TIP: The Camel CLI Kubernetes plugin provides a `run` command that combines these steps (export, container image build, push, deploy) into a single command. - -You can now navigate to the generated project folder and build the project artifacts for instance with this Maven command. +The default runtime is Quarkus (`--runtime=quarkus`). Build and deploy: [source,bash] ---- ./mvnw package -Dquarkus.container-image.build=true ----- - -According to the runtime type (e.g., quarkus) defined for the export this builds and creates a Quarkus application artifact JAR in the Maven build output folder (e.g. `target/route-1.0-SNAPSHOT.jar`). - -The option `-Dquarkus.container-image.build=true` also builds a container image that is ready for deployment to Kubernetes. -More precisely, the exported project uses the very same tooling and options as an arbitrary Quarkus/SpringBoot application would do. -This means you can easily customize the container image and all settings provided by the runtime provider (e.g., Quarkus or SpringBoot) after the export. - -The Kubernetes deployment resources are automatically generated with the export, too. - -You can find the Kubernetes manifest in `src/main/kubernetes/kubernetes.yml`. - -For instance with the option `-Dquarkus.kubernetes.deploy=true` uses this manifest to trigger the Kubernetes deployment as part of the Maven build. - -[source,bash] ----- ./mvnw package -Dquarkus.kubernetes.deploy=true ---- -You will see the Deployment on Kubernetes shortly after this command has finished. +TIP: The `camel kubernetes run` command combines export, build, push, and deploy into a single step. -The Camel CLI Kubernetes export command provides several options to customize the exported project. +The export command provides several options to customize the project: [width="100%",cols="1m,3",options="header",] |======================================================================= @@ -173,56 +108,27 @@ The Camel CLI Kubernetes export command provides several options to customize th |The developer xref:manual::camel-jbang-running.adoc#_using_profiles[profile] to use a specific configuration in configuration files using the naming style `application-<profile>.properties`. |======================================================================= -The Kubernetes plugin export command also inherits all options from the arbitrary Camel CLI export command. +TIP: Run `camel kubernetes export --help` for all options (includes inherited Camel CLI export options). -TIP: See the possible options by running: `camel kubernetes export --help` for more details. +=== Health probes -=== Kubernetes Container Health Probes +The export includes `camel-observability-services` by default, which prefixes health probes with `/observe`: -The Observability Services component is set by default in the project created by the export command, then the health path probes are prefixed with the `/observe` endpoint, regardless if they are Quarkus or Spring Boot. - -These are the HTTP Container probe endpoints. - -For Quarkus. -[source] ----- -/observe/health/live -/observe/health/ready -/observe/health/started ----- - -For Spring Boot (there is no startup probe) -[source] ----- -/observe/health/liveness -/observe/health/readiness ----- - -Note that these container probes are generated by jkube plugin, when you run the `k8s:resource` to generate the manifests in the `target/kubernetes/kubernetes.yml`. - -You can export to a project and manually remove the `camel-observability-services` artifact from the `pom.xml`. +- Quarkus: `/observe/health/live`, `/observe/health/ready`, `/observe/health/started` +- Spring Boot: `/observe/health/liveness`, `/observe/health/readiness` == Kubernetes manifest options -The Kubernetes manifest (kubernetes.yml) describes all resources to successfully run the application on Kubernetes. -The manifest usually holds the deployment, a service definition, config maps and much more. +Customize the Kubernetes manifest using traits (from Camel K). Trait configuration precedence: -You can use several options on the `export` command to customize this manifest with the traits. -The trait concept was born out of Camel K, and the Camel K operator uses the traits to configure the Kubernetes resources that are managed by an integration. -You can use the same options to also customize the Kubernetes manifest that is generated as part of the project export. +1. `--trait` command options +2. Annotations with prefix `trait.camel.apache.org/*` +3. Properties in `application-<profile>.properties` with prefix `camel.jbang.trait.*` +4. Properties in `application.properties` with prefix `camel.jbang.trait.*` -The configuration of the traits is used by the given order: +=== Container trait -1. Use the `--trait` command options values -2. Any annotation starting with the prefix `trait.camel.apache.org/*` -3. Any properties from the specific configuration `application-<profile>.properties` for the profile defined by the command option `--profile` with the prefix `camel.jbang.trait.*` -4. Any properties from the default configuration `application.properties` with the prefix `camel.jbang.trait.*` - -=== Container trait options - -The container specification is part of the Kubernetes Deployment resource and describes the application container image, exposed ports and health probes, for example. - -The container trait is able to customize the container specification with the following options: +Customize the container specification (image, ports, resources): [cols="2m,1m,5a"] |=== @@ -278,79 +184,22 @@ The container trait is able to customize the container specification with the fo |=== -The syntax to specify container trait options is as follows: - -[source,bash] ----- -camel kubernetes export Sample.java --trait container.[key]=[value] ----- - -You may specify these options with the export command to customize the container specification. +Example: [source,bash] ---- -camel kubernetes export Sample.java --trait container.name=my-container --trait container.port=8088 --trait container.imagePullPolicy=IfNotPresent --trait container.request-cpu=0.005 --trait container.request-memory=100Mi ----- - -This results in the following container specification in the Deployment resource. - -[source,yaml] ----- -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - camel.apache.org/integration: sample - name: sample -spec: - selector: - matchLabels: - camel.apache.org/integration: sample - template: - metadata: - labels: - camel.apache.org/integration: sample - spec: - containers: - - image: quay.io/sample:1.0-SNAPSHOT #<1> - imagePullPolicy: IfNotPresent #<2> - name: my-container #<3> - ports: - - containerPort: 8088 #<4> - name: http - protocol: TCP - resources: - requests: - memory: 100Mi - cpu: '0.005' +camel kubernetes export Sample.java --trait container.name=my-container --trait container.port=8088 --trait container.request-cpu=0.005 --trait container.request-memory=100Mi ---- -<1> Container image running the application -<2> Customized image pull policy -<3> Custom container name -<4> Custom container port exposed - -=== Cronjob -It's possible to run the workload as a https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/[CronJob], it allows to set some parameters as `schedule`, `timezone`, `startingDeadlineSeconds`, `activeDeadlineSeconds`, `backoffLimit`, and `durationMaxIdleSeconds`. When the CronJob trait is used, it doesn't contain the container health probes, since the Cronjob doesn't use them to start or check the pods. +=== CronJob trait -To generate the CronJob manifest, these are required trait parameters: `enabled=true` and `schedule`. - -.Example +Generate a https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/[CronJob] instead of a Deployment (requires `enabled=true` and `schedule`): [source,bash] ---- -camel kubernetes export Sample.java \ - --trait=cronjob.enabled=true \ - --trait=cronjob.schedule="* * * * 2" \ - --trait=cronjob.timezone="Europe/Lisbon" \ - --trait=cronjob.startingDeadlineSeconds=3 \ - --trait=cronjob.activeDeadlineSeconds=7 \ - --trait=cronjob.backoffLimit=4 \ - --trait=cronjob.durationMaxIdleSeconds=2 +camel kubernetes export Sample.java --trait=cronjob.enabled=true --trait=cronjob.schedule="* * * * 2" ---- -The CronJob configuration parameters: - [cols="2m,1m,5a"] |=== |Property | Type | Description @@ -387,128 +236,26 @@ The CronJob configuration parameters: === Labels and annotations -You may need to add labels or annotations to the generated Kubernetes resources. -By default, the generated resources will have the label `camel.apache.org/integration` set to the exported project name. - -When the `--observe` command option is present (it is by default) then the generated resources will also have the label `camel.apache.org/app` set to the exported project name. - -You can add labels and annotations with these options on the export command: - -[source,bash] ----- -camel kubernetes export Sample.java --annotation [key]=[value] --label [key]=[value] ----- - -.Example +By default, resources have the label `camel.apache.org/integration` set to the project name. +Add custom labels and annotations: [source,bash] ---- -camel kubernetes export Sample.java --annotation project.team=camel-experts +camel kubernetes export Sample.java --annotation project.team=camel-experts --label env=staging ---- -[source,yaml] ----- -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - project.team: camel-experts #<1> - labels: - camel.apache.org/integration: sample - name: sample -spec: - selector: - matchLabels: - camel.apache.org/integration: sample - template: - metadata: - labels: - camel.apache.org/integration: sample - spec: - containers: - - image: quay.io/sample:1.0-SNAPSHOT - name: sample ----- -<1> Custom deployment annotation - === Environment variables -The environment trait is there to set environment variables on the container specification. - -The environment trait provides the following configuration options: - -[cols="2m,1m,5a"] -|=== -|Property | Type | Description - -| environment.vars -| []string -| A list of environment variables to be added to the integration container. -The syntax is KEY=VALUE separated by a comma, e.g., `'MY_VAR="my value"','MY_OTHER_VAR="my value"'` . - -These take precedence over the previously defined environment variables. - -|=== - -The syntax to specify environment trait options is as follows: +Set environment variables with `--trait environment.vars=KEY=VALUE` or the shortcut `--env KEY=VALUE`: [source,bash] ---- -camel kubernetes export Sample.java --trait environment.[key]=[value] ----- - -There is also a shortcut option `--env` that you can use. - -[source,bash] ----- -camel kubernetes export Sample.java --env [key]=[value] ----- - -.Example -[source,bash] ----- -camel kubernetes export Sample.java --trait environment.vars=MY_ENV=foo --env FOO_ENV=bar ----- - -This results in the following container specification in the Deployment resource. - -[source,yaml] ----- -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - camel.apache.org/integration: sample - name: sample -spec: - selector: - matchLabels: - camel.apache.org/integration: sample - template: - metadata: - labels: - camel.apache.org/integration: sample - spec: - containers: - - image: quay.io/sample:1.0-SNAPSHOT - name: sample - env: #<1> - - name: MY_ENV - value: foo - - name: FOO_ENV - value: bar +camel kubernetes export Sample.java --env MY_ENV=foo --env FOO_ENV=bar ---- -<1> Environment variables set in the container specification - -=== Service trait options - -The Service trait enhances the Kubernetes manifest with a Service resource so that the application can be accessed by other components in the same namespace. -The service resource exposes the application with a protocol (e.g., TCP/IP) on a given port and uses either `ClusterIP`, `NodePort` or `LoadBalancer` type. -The Camel CLI plugin automatically inspects the Camel routes for exposed Http services and adds the service resource when applicable. -This means when one of the Camel routes exposes a Http service (for instance by using the `platform-http` component) the Kubernetes manifest also creates a Kubernetes Service resource besides the arbitrary Deployment. +=== Service trait -You can customize the generated Kubernetes service resource with trait options: +A Service resource is auto-generated when routes expose HTTP endpoints (e.g., `platform-http`). Customize it: [cols="2m,1m,5a"] |=== @@ -528,21 +275,13 @@ You can customize the generated Kubernetes service resource with trait options: |=== -=== Knative service trait options - -https://knative.dev/docs/serving/[Knative serving] defines a set of resources on Kubernetes to handle Serverless workloads with automatic scaling and scale-to-zero functionality. - -When Knative serving is available on the target Kubernetes cluster, you may want to use the Knative service resource instead of an arbitrary Kubernetes service resource. -The Knative service trait will create such a resource as part of the Kubernetes manifest. - -NOTE: The `knative-service` trait is disabled by default, you need to enable the Knative service trait with `--trait knative-service.enabled=true` option. Otherwise, the Camel CLI export will always create an arbitrary Kubernetes service resource. +=== Knative service trait -NOTE: If you enable the knative-service trait and deploys to minikube and uses the docker builder to build the container image in the minikube registry addon, it's likely the container image published won't contain the digest value, and https://knative.dev/docs/serving/configuration/deployment/#skipping-tag-resolution[knative-serving has a verification to check the image digest], so the pod will fail to start with the error message `failed to resolve image to digest`, so for development [...] +Use https://knative.dev/docs/serving/[Knative serving] for serverless workloads with auto-scaling and scale-to-zero. -WARN: Currently knative-service doesn't work in OpenShift, work is underway to fix it. +NOTE: Disabled by default — enable with `--trait knative-service.enabled=true`. - -The trait offers following options for customization: +WARN: Currently does not work on OpenShift. [cols="2m,1m,5a"] |=== @@ -611,21 +350,11 @@ Refer to the Knative documentation for more information. |=== -=== Connecting to Knative - -The previous section described how the exported Apache Camel application can leverage the Knative service resource with auto-scaling as part of the deployment to Kubernetes. - -Apache Camel also provides a Knative component that makes you easily interact with https://knative.dev/docs/eventing/[Knative eventing] and https://knative.dev/docs/serving/[Knative serving]. +=== Knative component trait -The Knative component enables you to exchange data with the Knative eventing broker and other Knative services deployed on Kubernetes. -The Camel CLI Kubernetes plugin provides some autoconfiguration options when connecting with the Knative component. -The export command assists you in configuring both the Knative component and the Kubernetes manifest for connecting to Knative resources on the Kubernetes cluster. +Configure the Camel Knative component to interact with https://knative.dev/docs/eventing/[Knative eventing] and https://knative.dev/docs/serving/[Knative serving]. The export auto-configures both the component and the Kubernetes manifest. -You can configure the Knative component with the Knative trait. - -NOTE: The `knative` trait is disabled by default, you need to enable the Knative trait with `--trait knative.enabled=true` option. - -The trait offers the following options for customization: +NOTE: Disabled by default — enable with `--trait knative.enabled=true`. [cols="2m,1m,5a"] |=== @@ -682,17 +411,7 @@ Refer to the Knative documentation for more information. === Knative trigger -The concept of a Knative trigger allows you to consume events from the https://knative.dev/docs/eventing/[Knative eventing] broker. -In case your Camel route uses the Knative component as a consumer you may need to create a trigger in Kubernetes -to connect your Camel application with the Knative broker. - -The Camel CLI Kubernetes plugin is able to automatically create this trigger for you. - -NOTE: The `knative` trait is disabled by default, you need to enable the Knative trait with `--trait knative.enabled=true` option. - -The following Camel route uses the Knative event component and references a Knative broker by its name. -The plugin inspects the code and automatically generates the Knative trigger as part of the Kubernetes manifest that is used -to run the Camel application on Kubernetes. +When a route consumes from `knative:event`, the plugin automatically generates a Knative Trigger in the manifest: [source,yaml] ---- @@ -706,239 +425,18 @@ to run the Camel application on Kubernetes. uri: log:info ---- -The route consumes Knative events of type `camel.evt.type`. -If you export this route with the Camel CLI Kubernetes plugin, you will see a Knative trigger being generated as part of the Kubernetes manifest (kubernetes.yml). - -[source,bash] ----- -camel kubernetes export knative-route.yaml ----- - -The generated export project can be deployed to Kubernetes, and as part of the deployment, the trigger is automatically created so the application can start consuming events. - -The generated trigger looks as follows: - -[source,yaml] ----- -apiVersion: eventing.knative.dev/v1 -kind: Trigger -metadata: - name: my-broker-knative-route-camel-evt-type -spec: - broker: my-broker - filter: - attributes: - type: camel.evt.type - subscriber: - ref: - apiVersion: v1 - kind: Service - name: knative-route - uri: /events/camel-evt-type ----- - -The trigger uses a default filter on the event type CloudEvents attribute and calls the Camel application via the exposed Kubernetes service resource. - -The Camel application is automatically configured to expose an Http service so incoming events are handed over to the Camel route. -You can review the Knative service resource configuration that makes Camel configure the Knative component. -The configuration has been automatically created in `src/main/resources/knative.json` in the exported project. - -Here is an example of the generated `knative.json` file: - -[source,json] ----- -{ - "resources" : [ { - "name" : "camel-event", - "type" : "event", - "endpointKind" : "source", - "path" : "/events/camel-event", - "objectApiVersion" : "eventing.knative.dev/v1", - "objectKind" : "Broker", - "objectName" : "my-broker", - "reply" : false - } ] -} ----- - -The exported project has everything configured to run the application on Kubernetes. -Of course, you need Knative eventing installed on your target cluster, and you need to have a Knative broker named `my-broker` available in the target namespace. - -Now you can just deploy the application using the Kubernetes manifest and see the Camel route consuming events from the broker. +Export with `camel kubernetes export knative-route.yaml` — the trigger, service, and `knative.json` configuration are all generated automatically. === Knative channel subscription -Knative channels represent another form of producing and consuming events from the Knative broker. -Instead of using a trigger, you can create a subscription for a Knative channel to consume events. - -NOTE: The `knative` trait is disabled by default, you need to enable the Knative trait with `--trait knative.enabled=true` option. - -The Camel route that connects to a Knative channel in order to receive events looks like this: - -[source,yaml] ----- -- route: - from: - uri: knative:channel/my-channel - steps: - - to: - uri: log:info ----- - -The Knative channel is referenced by its name. -The Camel CLI Kubernetes plugin will inspect your code to automatically create a channel subscription as part of the Kubernetes manifest. -You just need to export the Camel route as usual. - -[source,bash] ----- -camel kubernetes export knative-route.yaml ----- - -The code inspection recognizes the Knative component that references the Knative channel, and the subscription automatically becomes part of the exported Kubernetes manifest. - -Here is an example subscription that has been generated during the export: - -[source,yaml] ----- -apiVersion: messaging.knative.dev/v1 -kind: Subscription -metadata: - name: my-channel-knative-route -spec: - channel: - apiVersion: messaging.knative.dev/v1 - kind: Channel - name: my-channel - subscriber: - ref: - apiVersion: v1 - kind: Service - name: knative-route - uri: /channels/my-channel ----- - -The subscription connects the Camel application with the channel, so each event on the channel is sent to the Kubernetes service resource that also has been created as part of the Kubernetes manifest. - -The Camel Knative component uses a service resource configuration internally to create the proper Http service. -You can review the Knative service resource configuration that makes Camel configure the Knative component. -The configuration has been automatically created in `src/main/resources/knative.json` in the exported project. - -Here is an example of the generated `knative.json` file: - -[source,json] ----- -{ - "resources" : [ { - "name" : "my-channel", - "type" : "channel", - "endpointKind" : "source", - "path" : "/channels/my-channel", - "objectApiVersion" : "messaging.knative.dev/v1", - "objectKind" : "Channel", - "objectName" : "my-channel", - "reply" : false - } ] -} ----- - -Assuming that you have Knative eventing installed on your cluster and that you have set up the Knative channel `my-channel` you can start consuming events right away. -The deployment of the exported project uses the Kubernetes manifest to create all required resources, including the Knative subscription. +Similarly, routes consuming from `knative:channel/my-channel` automatically generate a Knative Subscription in the manifest. The `knative.json` configuration is auto-generated. === Knative sink binding -When connecting to a Knative resource (Broker, Channel, Service) in order to produce events for Knative eventing you probably want to use a `SinkBinding` that resolves the URL to the Knative resource for you. -The sink binding is a Kubernetes resource that makes Knative eventing automatically inject the resource URL into your Camel application on startup. -The Knative URL injection uses environment variables (`K_SINK`, `K_CE_OVERRIDES`) on your deployment. -The Knative eventing operator will automatically resolve the Knative resource (e.g. a Knative broker URL) and inject the value so your application does not need to know the actual URL when deploying. - -The Camel CLI Kubernetes plugin leverages the sink binding concept for all routes that use the Knative component as an output. - -NOTE: The `knative` trait is disabled by default, you need to enable the Knative trait with `--trait knative.enabled=true` option. - -The following route produces events on a Knative broker: - -[source, yaml] ----- -- route: - from: - uri: timer:tick - steps: - - setBody: - constant: Hello Camel !!! - - to: - uri: knative:event/camel.evt.type - parameters: - name: my-broker ----- - -The route produces events of type `camel.evt.type` and pushes the events to the broker named `my-broker`. -At this point, the actual Knative broker URL is unknown. -The sink binding is going to resolve the URL and inject its value at deployment time using the `K_SINK` environment variable. - -The Camel CLI Kubernetes plugin export automatically inspects such a route and automatically creates the sink binding resource for us. -The sink binding is part of the exported Kubernetes manifest and is created on the cluster as part of the deployment. - -A sink binding resource created by the export command looks like follows: - -[source,bash] ----- -camel kubernetes export knative-route.yaml ----- +Routes that produce to `knative:event`, `knative:channel`, or `knative:endpoint` automatically get a `SinkBinding` resource in the manifest. Knative injects the target URL via the `K_SINK` environment variable at deployment time, so the route doesn't need to know the actual URL. +=== Mount trait -[source,yaml] ----- -apiVersion: sources.knative.dev/v1 -kind: SinkBinding -metadata: - finalizers: - - sinkbindings.sources.knative.dev - name: knative-route -spec: - sink: - ref: - apiVersion: eventing.knative.dev/v1 - kind: Broker - name: my-broker - subject: - apiVersion: apps/v1 - kind: Deployment - name: knative-route ----- - -In addition to creating the sink binding, the Camel CLI plugin also takes care of configuring the Knative Camel component. -The Knative component uses a configuration file that you can find in `src/main/resources/knative.json`. -As you can see the configuration uses the `K_SINK` injected property placeholder as a broker URL. - -[source,json] ----- -{ - "resources" : [ { - "name" : "camel-evt-type", - "type" : "event", - "endpointKind" : "sink", - "url" : "{{k.sink}}", - "objectApiVersion" : "eventing.knative.dev/v1", - "objectKind" : "Broker", - "objectName" : "my-broker", - "reply" : false - } ] -} ----- - -As soon as the Kubernetes deployment for the exported project has started the sink binding will inject the `K_SINK` environment variable so that the Camel applicaiton is ready to send events to the Knative broker. - -The sink binding concept works for Knative Broker, Channel and Service resources. -You just reference the resource by its name in your Camel route when sending data to the Knative component as an output of the route (`to("knative:event|channel|endpoint/<resource-name>")`). - -=== Mount trait options - -The mount trait is able to configure volume mounts on the Deployment resource in order to inject data from Kubernetes resources such as config maps or secrets. - -There are also shortcut options like `--volume`, `--config` and `--resource` for the mount trait. -These options are described in more detail in the next section. -For now let's have a look into the pure mount trait configuration options. - -The mount trait provides the following configuration options: +Configure volume mounts from ConfigMaps, Secrets, and PVCs. Shortcuts: `--volume`, `--config`, `--resource`. [cols="2m,1m,5a"] |=== @@ -964,151 +462,18 @@ Syntax: [configmap\|secret]:name[/key][@path], where name represents the resourc |=== -The syntax to specify mount trait options is as follows: +Example: [source,bash] ---- -camel kubernetes export Sample.java --trait mount.[key]=[value] +camel kubernetes export Sample.java --config secret:my-credentials --resource configmap:my-data --volume my-pvc:/container/path ---- -.Example -[source,bash] ----- -camel kubernetes export Sample.java --trait mount.configs=configmap:my-data --trait mount.volumes=my-pvc:/container/path ----- - -This results in the following container specification in the Deployment resource. - -[source,yaml] ----- -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - camel.apache.org/integration: sample - name: sample -spec: - selector: - matchLabels: - camel.apache.org/integration: sample - template: - metadata: - labels: - camel.apache.org/integration: sample - spec: - containers: - - image: quay.io/sample:1.0-SNAPSHOT - name: sample - volumeMounts: - - mountPath: /etc/camel/conf.d/_configmaps/my-data #<1> - name: my-data - readOnly: true - - mountPath: /container/path #<2> - name: my-pvc - readOnly: false - volumes: - - name: my-data #<3> - configMap: - name: my-data - - name: my-pvc #<4> - persistentVolumeClaim: - claimName: my-pvc ----- -<1> The config map `my-data` mounted into the container with default mount path for configurations -<2> The volume mounted into the container with given path -<3> The config map reference as volume spec -<4> The persistent volume claim `my-pvc` - -=== ConfigMaps, volumes and secrets - -In the previous section, we have seen how to mount volumes, configs, and resources into the container. - -The Kubernetes export command provides some shortcut options for adding configmaps and secrets as volume mounts. -The syntax is as follows: - -[source,bash] ----- -camel kubernetes export Sample.java --config [key]=[value] --resource [key]=[value] --volume [key]=[value] ----- - -The options expect the following syntax: - -[cols="2m,5a"] -|=== -|Option | Syntax - -| config -| Add a runtime configuration from a ConfigMap or a Secret (syntax: [configmap\|secret]:name[/key], where name represents the configmap or secret name and key optionally represents the configmap or secret key to be filtered). - -| resource -| Add a runtime resource from a Configmap or a Secret (syntax: [configmap\|secret]:name[/key][@path], where name represents the configmap or secret name, key optionally represents the configmap or secret key to be filtered and the path represents the destination path). - -| volume -| Mount a volume into the integration container, for instance "--volume pvcname:/container/path". - -|=== - -.Example -[source,bash] ----- -camel kubernetes export Sample.java --config secret:my-credentials --resource configmap:my-data --volume my-pvc:/container/path ----- - -[source,yaml] ----- -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - camel.apache.org/integration: sample - name: sample -spec: - selector: - matchLabels: - camel.apache.org/integration: sample - template: - metadata: - labels: - camel.apache.org/integration: sample - spec: - containers: - - image: quay.io/sample:1.0-SNAPSHOT - name: sample - volumeMounts: - - mountPath: /etc/camel/conf.d/_secrets/my-credentials - name: my-credentials #<1> - readOnly: true - - mountPath: /etc/camel/resources.d/_configmaps/my-data - name: my-data #<2> - readOnly: true - - mountPath: /container/path - name: my-pvc #<3> - readOnly: false - volumes: - - name: my-credentials #<4> - secret: - secretName: my-credentials - - name: my-data #<5> - configMap: - name: my-data - - name: my-pvc #<6> - persistentVolumeClaim: - claimName: my-pvc ----- -<1> The secret configuration volume mount -<2> The config map resource volume mount -<3> The volume mount -<4> The secret configuration volume -<5> The config map resource volume -<6> The persistent volume claim volume - -The trait volume mounts follow some best practices in specifying the mount paths in the container. Configurations and resources, secrets, and configmaps do use different paths in the container. The Camel application is automatically configured to read these paths as resource folders, so you can use the mounted data in the Camel routes via classpath reference, for instance. - -=== Ingress trait options +Mount paths follow Camel conventions: configs go to `/etc/camel/conf.d/`, resources to `/etc/camel/resources.d/`, and the application is auto-configured to read these paths. -The ingress trait enhances the Kubernetes manifest with an Ingress resource to expose the application to the outside world. This requires the presence in the Kubernetes manifest of a Service Resource. +=== Ingress trait -The ingress trait provides the following configuration options: +Add an Ingress resource to expose the application externally (requires a Service resource): [cols="2m,1m,5a"] |=== @@ -1148,60 +513,16 @@ The ingress trait provides the following configuration options: |=== -The syntax to specify container trait options is as follows: +Example: [source,bash] ---- -camel kubernetes export Sample.java --trait ingress.[key]=[value] +camel kubernetes export Sample.java --trait ingress.enabled=true --trait ingress.host=example.com --trait ingress.path=/sample ---- -You may specify these options with the export command to customize the Ingress Resource specification. - -[source,bash] ----- -camel kubernetes export Sample.java --trait ingress.enabled=true --trait ingress.host=example.com --trait ingress.path=/sample(/|$)(.*) --trait ingress.pathType=ImplementationSpecific --trait ingress.annotations=nginx.ingress.kubernetes.io/rewrite-target=/\$2 --trait ingress.annotations=nginx.ingress.kubernetes.io/use-regex=true ----- - - -This results in the following container specification in the Ingress resource. - -[source,yaml] ----- -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - annotations: #<1> - nginx.ingress.kubernetes.io/rewrite-target: /$2 - nginx.ingress.kubernetes.io/use-regex: "true" - labels: - app.kubernetes.io/name: sample - name: sample -spec: - ingressClassName: nginx - rules: - - host: example.com - http: - paths: - - backend: - service: - name: route-service - port: - name: http #<2> - path: /sample(/|$)(.*) #<3> - pathType: ImplementationSpecific #<4> - - ----- -<1> Custom annotations configuration for ingress behavior -<2> Service port name -<3> Custom ingress backend path -<4> Custom ingress backend path type - -=== Route trait options - -The Route trait enhances the Kubernetes manifest with a Route resource to expose the application to the outside world. This requires the presence in the Kubernetes manifest of a Service Resource. +=== Route trait (OpenShift) -The Route trait provides the following configuration options: +Add an OpenShift Route resource to expose the application externally: [cols="2m,1m,5a"] |=== @@ -1246,56 +567,16 @@ The Route trait provides the following configuration options: |=== -The syntax to specify container trait options is as follows: +Example: [source,bash] ---- -camel kubernetes export Sample.java --trait route.[key]=[value] +camel kubernetes export Sample.java --cluster-type=openshift --trait route.enabled=true --trait route.host=example.com --trait route.tls-termination=edge ---- -You may specify these options with the export command to customize the Route Resource specification. +=== Jolokia trait -[source,bash] ----- -camel kubernetes export Sample.java --cluster-type=openshift -t route.enabled=true --trait route.host=example.com -t route.tls-termination=edge -t route.tls-certificate=file:/tmp/tls.crt -t route.tls-key=file:/tmp/tls.key ----- - - -This results in the following container specification in the Route resource. - -[source,yaml] ----- -apiVersion: route.openshift.io/v1 -kind: Route -metadata: - name: route-service -spec: - host: example.com #<1> - port: - targetPort: http #<2> - tls: - certificate: | #<3> - ... - key: | #<4> - ... - termination: edge #<5> - to: #<6> - kind: Service - name: route-service ----- -<1> Custom route host -<2> Service port name -<3> Custom route TLS certificate content -<4> Custom route TLS certificate key content -<5> Custom route TLS termination -<6> Service Resource reference - - -=== Jolokia trait options - -The Jolokia trait enhances the Kubernetes manifest enabling JMX access to Camel application. This requires jolokia being configured in the Camel Application. - -The Jolokia trait provides the following configuration options: +Enable JMX access via Jolokia (requires Jolokia configured in the application): [cols="2m,1m,5a"] |=== @@ -1328,431 +609,141 @@ The Jolokia trait provides the following configuration options: |=== -The syntax to specify jolokia trait options is as follows: - -[source,bash] ----- -camel kubernetes export Sample.java --trait jolokia.[key]=[value] ----- - -You may specify these options with the export command to customize the Container and Service Resource specification for Jolokia. +Example: [source,bash] ---- -camel kubernetes export Sample.java --trait jolokia.enabled=true --trait jolokia.container-port=8779 --trait jolokia.container-port-name=jolokia-port --trait jolokia.expose=true --trait jolokia.service-port=8779 --trait jolokia.service-port-name=port-jolokia ----- - -This results in the following specifications in the Deployment and Service resources. - -[source,yaml] ----- -apiVersion: apps/v1 -kind: Deployment -metadata: - ... - name: sample -spec: - selector: - ... - template: - ... - spec: - containers: - - name: sample - ports: - - containerPort: 8080 - name: http - protocol: TCP - - containerPort: 8779 #<1> - name: jolokia-port #<2> - protocol: TCP -... +camel kubernetes export Sample.java --trait jolokia.enabled=true --trait jolokia.expose=true ---- -[source,yaml] ----- -apiVersion: v1 -kind: Service -metadata: -... - name: sample -spec: - ports: - - name: http - port: 80 - protocol: TCP - targetPort: http - - name: jolokia-port #<3> - port: 8779 #<4> - protocol: TCP - targetPort: jolokia-port #<2> -... ----- - -<1> Custom Jolokia container port -<2> Custom Jolokia container port name -<3> Custom Jolokia service port name -<4> Custom Jolokia service port - - -=== OpenApi specifications -You can mount OpenAPI specifications to the application container with this trait. +=== OpenAPI trait -The openapi trait provides the following configuration options: - -[cols="2m,1m,5a"] -|=== -|Property | Type | Description - -| openapi.configmaps -| []string -| The configmaps holding the spec of the OpenAPI - -|=== - -The syntax to specify openapi trait options is as follows: +Mount OpenAPI specs from ConfigMaps: [source,bash] ---- -camel kubernetes export Sample.java --trait openapi.[key]=[value] +camel kubernetes export Sample.java --open-api configmap:my-spec ---- -.Example -[source,bash] ----- -camel kubernetes export Sample.java --trait openapi.configmaps=configmap:my-spec ----- +== Deploy to OpenShift -TIP: There is also a shortcut option `--open-api=configmap:my-configmap`. +Use `--cluster-type=openshift` to generate OpenShift-specific resources (Route, ImageStream, BuildConfig): [source,bash] ---- -camel kubernetes export Sample.java --open-api configmap:[name-of-configmap] +camel kubernetes export Sample.java --cluster-type=openshift ---- -This results in the following container specification in the Deployment resource. +The default image builder switches to S2I for OpenShift. Override with `--image-builder=jib` to push to an external registry instead. -[source,yaml] ----- -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - camel.apache.org/integration: sample - name: sample -spec: - selector: - matchLabels: - camel.apache.org/integration: sample - template: - metadata: - labels: - camel.apache.org/integration: sample - spec: - containers: - - image: quay.io/sample:1.0-SNAPSHOT - name: sample - volumeMounts: - - mountPath: /etc/camel/resources.d/_configmaps/my-spec - name: my-spec #<1> - readOnly: true - volumes: - - name: my-spec #<2> - configMap: - name: my-spec ----- -<1> OpenAPI specification volume mount -<2> Volume referencing the config map holding the OpenAPI specification - -== Deploy to OpenShift - -By default, the Kubernetes manifest is suited for plain Kubernetes platforms. -In case you are targeting OpenShift as a platform you may want to leverage special resources such as Route, ImageStream or BuildConfig. - -You can set the `cluster-type=openshift` option on the export command to tell the Kubernetes plugin to create a Kubernetes manifest specifically suited for OpenShift. - -Also, the default image builder is S2I for OpenShift clusters. -This means by setting the cluster type, you will automatically switch from default Jib to S2I. -Of course, you can tell the plugin to use Jib with `--image-builder=jib` option. -The image may then get pushed to an external registry (docker.io or quay.io) so OpenShift can pull as part of the deployment in the cluster. - -TIP: When using S2I, you may need to explicitly set the `--image-group` option to the project/namespace name in the OpenShift cluster. -This is because S2I will push the container image to an image repository that uses the OpenShift project/namespace name as part of the image coordinates in the registry: `image-registry.openshift-image-registry.svc:5000/<project name>/<name>:<tag>` - -When using S2I as an image build option, the Kubernetes manifest also contains an ImageStream and BuildConfig resource. -Both resources are automatically added/removed when creating/deleting the deployment with the Camel Kubernetes JBang plugin. +TIP: With S2I, set `--image-group` to your OpenShift project/namespace name, since S2I uses it as part of the image coordinates: `image-registry.openshift-image-registry.svc:5000/<project>/<name>:<tag>` == Kubernetes run -The run command combines several steps into one single command. -The command performs a project export to a temporary folder, builds the project artifacts as well as the container images, pushes the image to an image registry and finally performs the deployment to Kubernetes using the generated Kubernetes manifest (`kubernetes.yml`). +The `run` command exports, builds, pushes, and deploys in one step: [source,bash] ---- camel kubernetes run route.yaml --image-registry=kind ---- -When connecting to a local Kubernetes cluster, you may need to specify the image registry where the application container image gets pushed to. -The run command is able to automatically configure the local registry when using predefined names such as `kind` or `minikube`, there is a detection mechanism to set some properties accordingly to the cluster type, currently it can auto detect Openshift and Minikube. If you want to disable the cluster detection, you have to set the `--disable-auto` cli parameter. +The command auto-detects local clusters (`kind`, `minikube`, OpenShift) and configures the registry accordingly. Disable with `--disable-auto`. -NOTE: When running minikube, the easiest way to push the image to the minikube container registry, is to enable the registry addon in minikube and to run `eval $(minikube docker-env)`. - -Use the `--image-group` or the `--image` option to customize the container image. +Customize the image: [source,bash] ---- camel kubernetes run route.yaml --image-registry=kind --image-group camel-experts ----- - -The command above builds and pushes the container image: `localhost:5001/camel-experts/route:1.0-SNAPSHOT`. - -[source,bash] ----- camel kubernetes run route.yaml --image quay.io/camel-experts/demo-app:1.0 ---- -The `--image` option forces the container image group, name, version as well as the image registry. +The `run` command supports the same trait options as `export` for customizing the Kubernetes manifest. -=== Customize the Kubernetes manifest +=== Auto reload with `--dev` -The `run` command provides the same options to customize the Kubernetes manifest as the `export` command. -You may want to add environment variables, mount secrets and configmaps, adjust the exposed service and many other things with trait options as described in the export command section. - -=== Auto reload with `--dev` option - -The `--dev` option runs the application on Kubernetes and automatically adds a file watcher to listen for changes on the Camel route source files. -In case the sources get changed, the process will automatically perform a rebuild and redeployment. -The command constantly prints the logs to the output, so you may see the changes directly being applied to the Kubernetes deployment. +Watch for source file changes and automatically rebuild/redeploy: [source,bash] ---- camel kubernetes run route.yaml --image-registry=kind --dev ---- -You need to terminate the process to stop the dev mode. -This automatically removes the Kubernetes deployment from the cluster on shutdown. +Terminate the process to stop dev mode — the deployment is automatically removed on shutdown. -NOTE: On macOS hosts, the file watch mechanism is known to be much slower and less stable compared to using the `--dev` option on other operating systems like Linux. -This is due to limited native file operations on macOS for Java processes. +NOTE: On macOS, the file watch mechanism is slower due to limited native file operations for Java processes. === Setting properties and resources at runtime -There are several ways to set runtime properties: - -==== Properties as command parameters - -The simplest way is to set the property as `key`=`value`: +Set properties inline, from files, or from Kubernetes resources: [source,bash] ---- camel kubernetes run route.yaml --property my-key=my-val ----- - -==== Properties from files - -You can also reference an existing properties file, which in this case the properties content will be read and set in the `src/main/resources/application.properties` file (in the maven project generated by the internal export command). - -[source,bash] ----- -camel kubernetes run route.yaml --property /some/directory/file.properties ----- - -You can also use the `file:` prefix - -[source,bash] ----- camel kubernetes run route.yaml --property file:/some/directory/file.properties ---- -==== Properties from ConfigMap and Secret kubernetes resources - -The `--config` supports mapping from `ConfigMap` and `Secret` kubernetes resources and materialize as properties files in the pod. There is a standard directory path materialized in the pod filesystem: - -* `--config configmap:` materialized in `/etc/camel/conf.d/_configmaps/<configmap name>/<key name>` -* `--config secret:` materialized in `/etc/camel/conf.d/_secrets/<secret name>/<key name>` - -NOTE: For each `--config` the following properties `camel.component.properties.location=<path>` and `camel.component.properties.ignore-missing-location=true` will be set in the generated application.properties, to allow the mapped properties to be readily available in the camel runtime with property placeholders `{{my key}}`. - -So, given the following `ConfigMap`, you can see there is a key named `game.properties` whose content is a set of key named values. - -[source,bash] ----- -kind: ConfigMap -apiVersion: v1 -metadata: - name: game-config -data: - game.properties: | - my-key=property from SINGLE game.properties - enemies.cheat=true - secret.code.lives=30 ----- +==== Properties from ConfigMaps and Secrets -Materialize the content of `ConfigMap/game-config` using the `--config` parameter: +Use `--config` to mount ConfigMap/Secret data as properties files, automatically configured for Camel property placeholders: [source,bash] ---- camel kubernetes run route.java --config configmap:game-config ----- - -It will set the following mount options in the deployment manifest: - -[source,yaml] ----- - volumeMounts: - - mountPath: /etc/camel/conf.d/_configmaps/game-config - name: game-config - readOnly: true -volumes: -- configMap: - name: game-config - name: game-config ----- - -Then it will materialize the following file in the pod filesystem: ----- -/etc/camel/conf.d/_configmaps/game-config/game.properties ----- - -Another example, with a `ConfigMap` with more key properties: - -[source,yaml] ----- -kind: ConfigMap -apiVersion: v1 -metadata: - name: multiple-config -data: - game.properties: | - my-key=property from game.properties - secret.code.lives=30 - ui.properties: | - how.nice.to.look=fairlyNice ----- - -[source,bash] ----- -camel kubernetes run route.java --config configmap:multiple-config ----- - -It will materialize the files: ----- -/etc/camel/conf.d/_configmaps/multiple-config/game.properties -/etc/camel/conf.d/_configmaps/multiple-config/ui.properties ----- - -Note that each `ConfigMap` key is the file name. - -You can also map specific keys from the `data` section by using the `/<key name>`: - ----- camel kubernetes run route.java --config configmap:game-config/game.properties +camel kubernetes run route.java --config secret:my-credentials ---- +Mount paths: `--config configmap:` maps to `/etc/camel/conf.d/_configmaps/<name>/<key>`, `--config secret:` maps to `/etc/camel/conf.d/_secrets/<name>/<key>`. Each ConfigMap key becomes a file. -==== Mounting generic files from ConfigMap - -The `--resource` supports mapping from `ConfigMap` and `Secret` kubernetes resources and materialize as files in the pod. There is a standard directory path materialized in the pod filesystem: +==== Mounting generic files -* `--resource configmap:` materialized in `/etc/camel/resources.d/_configmaps/<configmap name>/<key name>` -* `--resource secret:` materialized in `/etc/camel/resources.d/_secrets/<secret name>/<key name>` +Use `--resource` to mount files without property placeholder configuration. Syntax: `[configmap|secret]:name[/key][@path]`: -NOTE: The `--resource` parameter doesn't set the `camel.component.properties.location=<path>` as the `--config`. - -The `--resource` syntax is `[configmap|secret]:name[/key][@path]`, the `key` and `@path` are optionals. The `@path` allows you to override the materialized file path in the pod filesystem. - -Given the following command: [source,bash] ---- -camel kubernetes run route.java --resource configmap:multiple-config +camel kubernetes run route.java --resource configmap:my-data +camel kubernetes run route.java --resource configmap:my-data/config.xml@/etc/my-config.xml ---- -It will materialize the files, similar to `--config`: -[source,bash] ----- -/etc/camel/resources.d/_configmaps/multiple-config/game.properties -/etc/camel/resources.d/_configmaps/multiple-config/ui.properties ----- - -Given the following command: - -[source,bash] ----- -camel kubernetes run route.java --resource configmap:multiple-config/ui.properties@/etc/my-file.txt ----- - -It will materialize the `/etc/my-file.txt` in the pod filesystem whose content is the `ui.properties` key of the `configmap:multiple-config`. -[source,bash] ----- -cat /etc/my-file.txt ----- -[source,bash] ----- -color.good=purple -color.bad=yellow -allow.textmode=true -how.nice.to.look=fairlyNice -my-key=property from ui.properties ----- +Mount paths: `/etc/camel/resources.d/_configmaps/<name>/<key>` (or `_secrets`). Use `@path` to override the destination. == Show logs -To inspect the log output of a running deployment call: +Stream log output from a running deployment: [source,bash] ---- camel kubernetes logs --name=route ---- -The command connects to the running integration Pod on the cluster and streams the log output. -Just terminate the process to stop printing the logs. - -The `--name` option should point to a previously exported project (either via `run` or `export` command). - == Delete deployments -Of course, you may also delete a deployment from the cluster. +Remove a deployment and all its resources: [source,bash] ---- camel kubernetes delete --name=route +camel kubernetes delete --name=route --cluster-type=openshift ---- -Use the `--name` option to select a previously exported project (either via `run` or `export` command). -The delete operation will remove all resources defined in the Kubernetes manifest. +NOTE: If you used `--cluster-type` during export/run, you must specify it for delete as well. + +== Minikube deployment tips -If you used the `--cluster-type` option to create your project (either via `run` or `export` command) you will need to use it as well for the delete operation. +Quick start for local development with Minikube (Camel 4.10+): [source,bash] ---- -camel kubernetes delete --name=route --cluster-type=openshift +minikube start --addons registry --driver=docker +eval $(minikube -p minikube docker-env) +camel kubernetes run demo.camel.yaml --cluster-type=minikube \ + --build-property=quarkus.kubernetes.image-pull-policy=Never \ + --image-registry "$(kubectl -n kube-system get service registry -o jsonpath='{.spec.clusterIP}')" \ + --image-builder=docker ---- -== Minikube deployment tips and troubleshooting - -To run a local Kubernetes cluster with Minikube for development purposes. -Here are some tips from users that have been using this. - -The following steps have been known to be working with Camel 4.8.1+: - -1. `minikube start --addons registry --driver=docker` -2. `eval $(minikube -p minikube docker-env)` -3. `camel kubernetes run demo.camel.yaml --cluster-type=minikube --build-property=quarkus.kubernetes.image-pull-policy=Never` - -Most important `--build-property=quarkus.kubernetes.image-pull-policy=Never` without that it is not working, which is not clear from the current Minikube docs. - -The following steps have been known to be working with Camel 4.9+: - -1. `minikube start --addons registry --driver=docker` -2. `eval $(minikube -p minikube docker-env)` -3. `camel kubernetes run demo.camel.yaml --cluster-type=minikube --build-property=quarkus.kubernetes.image-pull-policy=Never --trait container.image-push=true --image-registry '$(kubectl -n kube-system get service registry -o jsonpath='{.spec.clusterIP}')' --image-builder=docker` - -The following steps have been known to be working with Camel 4.10+: - -1. `minikube start --addons registry --driver=docker` -2. `eval $(minikube -p minikube docker-env)` -3. `camel kubernetes run demo.camel.yaml --cluster-type=minikube --build-property=quarkus.kubernetes.image-pull-policy=Never --image-registry "$(kubectl -n kube-system get service registry -o jsonpath='{.spec.clusterIP}')" --image-builder=docker` +IMPORTANT: The `--build-property=quarkus.kubernetes.image-pull-policy=Never` flag is required for Minikube deployments. -Note that Docker multi-platform build is used. It requires to have followed these https://docs.docker.com/build/building/multi-platform/#build-multi-platform-images[Docker requirements]. +NOTE: Docker multi-platform build is used. Follow the https://docs.docker.com/build/building/multi-platform/#build-multi-platform-images[Docker multi-platform requirements].
