live wire
▸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▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat▸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▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat
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