Camel K 2.11 makes plain Quarkus the default—and turns upgrades into migrations
The operator’s runtime switch brings newer Camel and Quarkus defaults, but existing deployments need to review compatibility, security context and deprecated platform settings.
Apache Camel K 2.11 changes more than a version number. The Kubernetes operator now uses the regular Camel Quarkus runtime—the plain-quarkus provider—by default, replacing the project-specific Camel K Runtime that had remained the default through Camel 4.8.5. For platform teams, that makes an upgrade a runtime migration that deserves an explicit compatibility pass rather than a routine operator rollout.
What changed
The new default aligns Camel K with Quarkus Platform 3.39.1 and Camel 4.22.0. Apache says this should make Camel K applications more compatible with ordinary Camel Quarkus applications and let the operator adopt current Camel and Quarkus work more directly.
The release also changes the default operational posture for integrations created with plain-quarkus: containers run as non-root, Camel health and Prometheus endpoints are enabled through the observability-services dependency, and Kubernetes readiness probes are enabled. Those defaults improve the baseline, but they can expose assumptions in workloads that still need root privileges or expect readiness to be reported before Camel itself is ready.
Camel K 2.11 also adds a MultiNamespace installation mode. An operator can reconcile a defined set of tenant namespaces without receiving the cluster-wide reach of the existing all-namespaces option. New allow-list settings cover external Maven repositories, builder node selectors, affinity labels and toleration taints.
Who needs to act
Teams upgrading existing Camel K installations should first identify integrations that rely on the old Camel K Runtime. Apache documents an opt-out: set the Camel trait’s runtimeProvider to quarkus and pin runtimeVersion to 3.15.3 if those applications must remain on the prior provider during migration.
Operators should also check security contexts, readiness timing and policy controls. Existing integrations that require root can set runAsNonRoot to false, while environments already using custom repositories, node selectors, affinity labels or tolerations may need matching entries in the new allow lists.
The longer migration
The release deprecates IntegrationPlatform in favor of operator environment variables and namespace-scoped IntegrationProfile configuration. It also deprecates custom tasks, the Prometheus and Knative Eventing traits, pull-secret auto-configuration and the integration profile parameter. Maven extensions, the Jolokia trait and Maven profile configuration have been removed.
The practical move is to stage 2.11 in a non-production namespace, inventory deprecated fields and traits, and compare generated deployments before moving shared environments. The new runtime narrows the distance between Camel K and mainstream Camel Quarkus, but that benefit arrives with deliberate migration work.
sources
- Camel K 2.11.0camel.apache.org
comments · 0