Camel K 2.11 changes its runtime baseline and narrows the operator control plane

Apache Camel K 2.11.0 changes two assumptions platform teams may have encoded into their operator deployments: which application runtime new integrations use, and where shared operator configuration belongs. The live release notes, published August 31, list the move to plain Camel Quarkus alongside a broad set of API, trait and installation changes.

What changed

Camel K now defaults new integrations to the plain Quarkus runtime. The merged runtime change explicitly closes the project’s work to deprecate the old Camel K runtime, while the release notes identify Camel Quarkus 3.39.1 and Camel 4.22.0 in the release train.

The operational defaults also move. The release notes record non-root security and health as defaults, add Camel custom-component support, and add resource requests and limits for init and sidecar containers. They also introduce allow-list controls around Maven repositories, builder node-selector keys, affinity labels and toleration taints. Those changes make the upgrade relevant to admission policy, scheduling and build configuration—not only to integration code.

The control-plane migration

Camel K 2.11 deprecates IntegrationPlatform. In the merged deprecation change, the project describes this as a prerequisite for a simpler next-generation architecture and says configuration previously held in the custom resource must move to operator environment variables.

The release simultaneously adds multi-namespace watching. That gives an operator an explicit tenancy option between a single watched namespace and unrestricted cluster-wide operation, but it also means platform teams should test the installation mode and its permissions instead of assuming their previous IntegrationPlatform-based layout will carry forward unchanged.

The release notes also mark custom builder tasks, the Prometheus trait, Knative Eventing integration, environment pull-secret behavior and Integration.spec.profile for deprecation. Maven extensions, Maven profile configuration and the Jolokia trait are removed.

What teams should check

Before upgrading a shared Camel K installation, operators should inventory three things: integrations that rely on the old runtime, configuration stored in IntegrationPlatform, and policies that depend on the prior security or scheduling defaults. They should also test namespace scope and RBAC with the intended installation mode.

Application teams need a representative build-and-run check against the new plain Quarkus baseline, including custom components and sidecars where used. Platform teams should separately verify operator environment variables, repository allow lists, node-selection controls and any removed traits. Camel K 2.11 is therefore best treated as a runtime and control-plane migration, not a routine operator refresh.