live wire
▸JAVA · Quarkus 4.0.0.Beta1 moves to Java 21, adds HTTP/3 and starts extension migration (Oct. 1)Quarkus▸SECURITY · X41 shows shared /dev/shm can turn Envoy hot restart into cross-container lateral movementX41 D-Sec▸DATA · AWS and Red Hat map Confluent Platform on ROSA with HCP, CFK and OpenShift security controlsAWS IBM & Red Hat▸API · Red Hat resolves intermittent 3scale API Manager latencyRed Hat Status▸AI · IBM shows Maximo workflows exposed as approval-gated MCP tools on OpenShiftIBM Community▸AI · vLLM adds day-zero NVIDIA Vera Rubin support and reports 7.8× per-GPU throughputvLLM▸INTEGRATION · Apache Camel 4.23 makes Kamelets visible to AI tooling and validationApache Camel▸SECURITY · OpenShift 4.14.75 fixes five CVEs, including two SQLite code-execution flawsRed Hat Customer Portal▸SUPPLY CHAIN · Red Hat maps CRA-ready open source practices as EU reporting rules take effectRed Hat Blog▸AI · Red Hat AI Inference on IBM Cloud adds an OpenAI-compatible Embeddings APIIBM Cloud▸API · Red Hat investigates degraded 3scale API Management SaaS APIsRed Hat Status▸PLATFORM · Red Hat and Cloudera validate a 100-VM analytics stack on OpenShift VirtualizationRed Hat Blog▸DEVELOPER HUB · Red Hat maps a four-zone, quota-aware Dev Spaces architectureRed Hat Developer▸INTEGRATION · Camel 4.23 teaches agent tools to discover and validate KameletsApache Camel▸JAVA · Quarkus 4.0.0.Beta1 moves to Java 21, adds HTTP/3 and starts extension migration (Oct. 1)Quarkus▸SECURITY · X41 shows shared /dev/shm can turn Envoy hot restart into cross-container lateral movementX41 D-Sec▸DATA · AWS and Red Hat map Confluent Platform on ROSA with HCP, CFK and OpenShift security controlsAWS IBM & Red Hat▸API · Red Hat resolves intermittent 3scale API Manager latencyRed Hat Status▸AI · IBM shows Maximo workflows exposed as approval-gated MCP tools on OpenShiftIBM Community▸AI · vLLM adds day-zero NVIDIA Vera Rubin support and reports 7.8× per-GPU throughputvLLM▸INTEGRATION · Apache Camel 4.23 makes Kamelets visible to AI tooling and validationApache Camel▸SECURITY · OpenShift 4.14.75 fixes five CVEs, including two SQLite code-execution flawsRed Hat Customer Portal▸SUPPLY CHAIN · Red Hat maps CRA-ready open source practices as EU reporting rules take effectRed Hat Blog▸AI · Red Hat AI Inference on IBM Cloud adds an OpenAI-compatible Embeddings APIIBM Cloud▸API · Red Hat investigates degraded 3scale API Management SaaS APIsRed Hat Status▸PLATFORM · Red Hat and Cloudera validate a 100-VM analytics stack on OpenShift VirtualizationRed Hat Blog▸DEVELOPER HUB · Red Hat maps a four-zone, quota-aware Dev Spaces architectureRed Hat Developer▸INTEGRATION · Camel 4.23 teaches agent tools to discover and validate KameletsApache Camel
upstreambeat.ai
releaseINTEGRATION

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.

Old Camel K runtime versus new plain Quarkus default.
Side by side: what changed
By The News Desk· Sep 20, 2026the quick take — two AI hosts go live when you do

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

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.