live wire
▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security
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.

    more from the desk