|
| 1 | +--- |
| 2 | +title: Version 3 redesign |
| 3 | +authors: |
| 4 | + - "@squakez" |
| 5 | +creation-date: 2026-10-22 |
| 6 | +last-updated: 2026-10-22 |
| 7 | +status: |
| 8 | +see-also: [] |
| 9 | +replaces: [] |
| 10 | +superseded-by: [] |
| 11 | +--- |
| 12 | + |
| 13 | +== V3 redesign |
| 14 | + |
| 15 | +Camel K is a project that have seen a great evolution in the last years. The project was implemented with many features that, along the way, have been deprecated in favour to others or dropped because no longer interesting for the community of its users. |
| 16 | + |
| 17 | +The Apache Camel community has grown a series of alternative projects that can be used to prototype and build Camel applications (ie, Camel JBang) and the new https://camel-tooling.github.io/camel-dashboard/[Camel Monitor Operator] has reached a level of maturity and completeness making the monitoring part of Camel K something we can deprecate in favour of the former. |
| 18 | + |
| 19 | +In the recent months we have also seen a rise in the attempt to exploit potential vulnerabilities, so we may take the opportunity to review the boundaries between the administrative roles and the user roles (which may be confusing now due to the high number of custom resource to manage). |
| 20 | + |
| 21 | +A new redesign that can introduce certain breaking compatibility change would be beneficial for the project at this moment in order to: |
| 22 | + |
| 23 | +- Clean the Kubernetes API and make user/admin operations easy |
| 24 | +- Clean the code and make it easier to maintain in the long term. |
| 25 | +- Harden security |
| 26 | + |
| 27 | +== Goals |
| 28 | + |
| 29 | +The goal of this document is to illustrate the new design at a high level view. When the new design is approved, it will serve as a reference for all different developments required to complete a first version 3 of the project. |
| 30 | + |
| 31 | +== Proposal |
| 32 | + |
| 33 | +The main goal of the project remain the same. The main feature of the Camel K operator is to transform a Camel DSL or project (for example, expressed as a git project) into a running cloud application. What we aim to change are the intermediate steps required to perform that task. |
| 34 | + |
| 35 | +The plan is to remove part of the API in order to make it simpler to manage the tool. We expect the following custom resources: |
| 36 | + |
| 37 | +- `Integration` |
| 38 | +- `IntegrationBuild` |
| 39 | +- `IntegrationProfile` |
| 40 | +- `Pipe` |
| 41 | +- `Kamelet` |
| 42 | + |
| 43 | +All custom resources should be considered as user namespaced resources. That means, a user is able to query them in its own namespace only (or any other authorized namespace). No cross namespaces operations are allowed for security reason. The `IntegrationProfile` can be used as a namespaced admin configuration used to control certain build capabilities that should not be left to the final user (for example, build Pod resources, registry settings, ...). |
| 44 | + |
| 45 | +The typical use case is still for the user to provide either an `Integration` or a `Pipe` and let the operator do the rest. |
| 46 | + |
| 47 | +The new `IntegrationBuild` custom resource is the equivalent of the v2 `Build` custom resource. The difference is that it is created when a new `Integration` is created or a new build for it is required. This is triggering a `Job` whose goal is to do the build and containerization of the Camel workload. A `Pod` will be used to create an opinionated pipeline with the following responsibilities: |
| 48 | + |
| 49 | +- Create the project via `camel export` (likely using `camel-jbang` image) |
| 50 | +- Build and push the project to a given registry (using `jib` profile in `camel export`) |
| 51 | + |
| 52 | +We won't support any custom task as we realize that, any customization requires a more specialized CICD tool such as Jenkins or Tekton (which will be still supported as "Self Managed Build Integration"). Once the build completes successfully, the operator will continue the deployment phase, generating the related `Deployment` and starting the application. This new design will probably allow us to eventually introduce other features such as rollback to previous builds, given that each `IntegrationBuild` will track the container image which should stay in the registry. |
| 53 | + |
| 54 | +Another interesting feature is that with this approach we will be able to build any supported Camel runtime out of the box. When we generate the project (via `camel export`) we just need to provide the runtime to which we want to export. |
| 55 | + |
| 56 | +The rest of operations should be maintained exactly as it is right now (gitops, trait configuration, ...). What we expect to remove entirely from the Camel K operator is the monitoring part, delegating it to the presence of Camel Monitor operator (which has to be installed separately). |
| 57 | + |
| 58 | +The Camel K operator `Pod` will be also much simpler as it won't require it to build the Maven project as it used to do previously (via `routine` build feature). |
| 59 | + |
| 60 | +=== Main features changes |
| 61 | + |
| 62 | +* Track all builds for an `Integration` |
| 63 | +* Possibility to rollback to previous `IntegrationBuild` versions |
| 64 | +* Namespaced only resource access |
| 65 | +* Build will happen in a Pod (namespaced) |
| 66 | +* Any Camel runtime support (Quarkus, Spring Boot or Main with Quarkus as default) |
| 67 | +* Monitoring delegated to **Camel Monitor Operator** |
| 68 | + |
| 69 | +=== Features we'll lose |
| 70 | + |
| 71 | +* Kit reusability |
| 72 | +* Managed custom pipeline (external CICD still available) |
| 73 | + |
| 74 | +== Compatibility |
| 75 | + |
| 76 | +The v3 operator will be still compatible with previous v2 Integrations custom resource. However we should expect that, as soon as a new v3 operator detects an Integration will rebuild it with the new building system. In this sense we should expect to break the compatibility: a v3 operator will rebuild any existing v2 Integration the first time it detects it (unless it runs as Self Managed Build Integration). |
| 77 | + |
| 78 | +Older deprecated custom resource (`Build`, `IntegrationKit`, `IntegrationPlatform`, `CamelCatalog`) will be maintained in order to let a v2 operator work in the same cluster where a v3 operator is installed. However, the new v3 operator will ignore the old resources. |
0 commit comments