Releases

Longhorn v1.12.0 promotes the V2 Data Engine to GA, ships dual-stack/IPv6 support, and fixes critical instance-manager panics and replica scheduling bugs that caused cascading volume failures.

• breakingMigrate V2 backing image volumes before upgrading

  Any V2 volume created from a backing image cannot be upgraded in-place. Before upgrading to v1.12.0, back up each affected volume, delete it, and restore from backup — the restored volume has no backing image dependency. Skipping this step will cause attach failures post-upgrade. Use CDI for future VM disk image imports.

• breakingDetach V2 volumes before patch-level upgrades

  V2 volumes do not support live upgrades between v1.12.x patch releases. Plan maintenance windows to detach all V2 volumes before applying patch upgrades. Live upgrade across minor versions (v1.12 to v1.13) is planned but not yet available.

• breakingEncrypted migratable volumes need engine image upgrade before live migration

  The LUKS2 header pre-allocation fix for encrypted volumes introduces a constraint: live migration of encrypted volumes requires engine image CLI API version 12 or later. Upgrade the engine image to v1.12.0+ before attempting live migration; otherwise migration will fail.

• enhancementReview SPDK CPU allocation on existing V2 deployments

  The default CPU mask now uses 2 cores instead of 1. For clusters already running V2 volumes with a manually set single-core mask, consider increasing it — single-core configs under heavy I/O cause RPC starvation and operational instability. On ARM64 with NVMe-backed node disks, avoid multi-core SPDK configs for now and use AIO-backed disks until the stuck I/O bug is resolved.

• enhancementEnable dual-stack networking — but verify node IP family ordering first

  Dual-stack Kubernetes clusters are now supported, but only when all nodes have IP families configured in the same order (all IPv4-first or all IPv6-first). Audit your node network configs before enabling. Mixed ordering causes replica-to-engine connectivity failures with no obvious error surface.

Knative Serving v1.22.1 is a focused patch fixing an idle connection leak in the network prober, a memory leak in webhook matchers, and adding a 3MiB webhook request body size limit.

• securityApply the 3MiB webhook body limit immediately

  The new hard cap on webhook request body size closes a potential vector for memory exhaustion via oversized payloads. If you run Knative Serving in a multi-tenant or externally-exposed environment, upgrade to v1.22.1 now — don't wait for your next maintenance window.

• breakingWebhook requests larger than 3MiB will now be rejected

  If any of your workloads submit unusually large objects to Knative's admission webhooks (e.g., Services or Configurations with very large env var blocks or annotations), those requests will start failing after this upgrade. Audit object sizes before rolling out, and trim any oversized metadata or spec fields.

• enhancementUpgrade to stop slow memory and connection accumulation

  The prober connection leak and the expired-matcher memory leak are both cumulative — they degrade pod health gradually over time rather than causing immediate crashes. Clusters that have been running v1.22.0 for a while may already be affected. After upgrading, watch activator and webhook pod memory trends to confirm they stabilize.

Knative Serving v1.21.3 is a patch release fixing memory leaks, a connection leak in the network prober, and adding a 3MiB webhook request body size limit.

• security3MiB webhook body limit now enforced — test before upgrading

  The webhook request body is now hard-limited to 3MiB. If your workloads send large Knative resource specs (e.g., Services with extensive annotations, large env var blocks, or embedded configs), they could start getting rejected after this upgrade. Audit your largest Knative Service manifests before rolling this out to production. Anything approaching or exceeding 3MiB in a single admission request will fail.

• enhancementPatch memory and connection leaks — upgrade promptly

  Two resource leaks are fixed here: a memory leak in expired matchers and an idle connection leak in the network prober. In long-running clusters with frequent reconciliation or active health-checking, these leaks accumulate. If you've noticed gradual memory growth in the Knative controller or networking components, this patch is the likely fix. No config changes needed — just upgrade.

etcd v3.6.12 is a patch release in the 3.6 series. The release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingRead the CHANGELOG before upgrading

  The release notes for v3.6.12 are essentially empty — no changes are listed inline. Before upgrading any etcd cluster, pull the full CHANGELOG-3.6.md from the repo and review all entries since your current version. The official upgrade guide explicitly warns of potential breaking changes in the 3.6 series.

• enhancementVerify container registry targets in your pipelines

  etcd maintains two registries: gcr.io is primary, quay.io is secondary. If your CI/CD or deployment manifests pin to quay.io, confirm it stays in sync with the primary. For production clusters, prefer gcr.io/etcd-development/etcd to avoid lag.

etcd v3.5.31 is a patch release on the 3.5 branch. Release notes are minimal — check the full CHANGELOG for specifics before upgrading.

• breakingCheck the upgrade guide even for patch versions

  The etcd team explicitly calls out that breaking changes can appear in patch releases. Don't skip the upgrade guide assuming this is safe to apply blindly. Verify any API or storage format changes against your current deployment before scheduling maintenance.

• enhancementReview CHANGELOG before upgrading

  The release notes published here are sparse. Before rolling this out, pull the full CHANGELOG-3.5.md directly from the etcd repo to identify any bug fixes or behavioral changes that affect your cluster. Patch releases on 3.5 have historically included compaction fixes and lease handling improvements — worth verifying what specifically landed here.

etcd v3.4.45 is a maintenance release on the 3.4 branch. Release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingCheck the official upgrade guide even for patch releases

  The release explicitly flags that breaking changes may exist. Etcd 3.4.x is a mature but still-active branch used heavily in Kubernetes clusters. Verify the upgrade guide at etcd.io before rolling this out, especially in production environments where quorum and data integrity are non-negotiable.

• enhancementReview CHANGELOG before upgrading — release notes are intentionally minimal

  This release page contains almost no detail. Before upgrading, pull up CHANGELOG-3.4.md directly in the etcd GitHub repo to understand what actually changed. Blind upgrades on etcd — your cluster's source of truth — are a bad idea regardless of how minor a patch looks.

v1.17.9 fixes a targeted bug where workflows using Azure Cosmos DB as their actor state store get permanently stuck in a purge loop when the customStatus row is absent.

• breakingUpgrade immediately if using Cosmos DB for workflow state

  Any deployment using state.azure.cosmosdb as the workflow actor state store is at risk. Affected workflows never get purged past their TTL, and the scheduler fires a purge attempt every second forever — burning CPU, generating log noise, and inflating your dapr_runtime_workflow_operation_count{status=failed} metrics. Upgrade to 1.17.9 and restart sidecars; stuck workflows recover on the next retention reminder fire automatically. No manual cleanup needed after upgrade.

• enhancementCheck metrics now to assess blast radius before upgrading

  Before upgrading, query dapr_runtime_workflow_operation_count with labels operation=purge_workflow and status=failed. A non-zero and growing count on a Cosmos DB deployment confirms you have stuck workflows. This tells you how many workflows will self-heal post-upgrade and gives you a clear before/after signal to verify the fix took effect.

flagd core v0.16.0 changes disabled flag evaluation from an error response to a successful resolution with reason=DISABLED, affecting gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit any code that checks errorCode or reason on flag evaluations

  If your code branches on FLAG_DISABLED error codes or checks the reason field from direct gRPC/OFREP responses, it will no longer receive that error path for disabled flags — it'll get a success with reason=DISABLED instead. Search your codebase for FLAG_DISABLED string matches, error-code switch statements, and reason-field conditionals before upgrading. SDK users who only consume the resolved value are unaffected and can upgrade without changes.

• enhancementUse reason=DISABLED for observability and audit logging

  The new behavior is actually cleaner for telemetry. Since disabled flags now resolve successfully, you can distinguish 'flag disabled' from 'evaluation error' in your metrics and logs without special-casing error codes. Update your dashboards and alerting rules to treat reason=DISABLED as an expected, non-error signal rather than filtering it out as noise.

flagd v0.16.0 changes disabled flag evaluation from an error to a successful resolution with reason=DISABLED, affecting direct gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit error-handling code that checks FLAG_DISABLED or errorCode

  If your application checks the evaluation reason or error code after a flag resolution — whether through direct gRPC calls, OFREP HTTP calls, or Go imports of core/pkg/model — you need to update that logic. FLAG_DISABLED errors will no longer appear; instead expect a successful response with reason=DISABLED. SDK users who only read the resolved value are unaffected, but any monitoring, alerting, or branching logic that keys off FLAG_DISABLED will silently stop triggering. Grep your codebase for FLAG_DISABLED and errorCode checks before upgrading.

KEDA v2.20 ships four breaking removals, an RBAC migration for Kubernetes events, two new scalers, and a wave of bug fixes including credential-leak and connection-leak patches across several scalers.

• securityPatch credential-leak and connection-leak issues in Pulsar, RabbitMQ, and AWS scalers

  The Pulsar scaler was leaking bearer/basic auth credentials on cross-host redirects or HTTPS-to-HTTP downgrades. RabbitMQ had an AMQP connection leak. AWS scalers (SQS, Kinesis, DynamoDB, CloudWatch) leaked TCP connections on scaler close. If you run any of these scalers, upgrading to v2.20 closes real attack surface and resource exhaustion vectors. No config changes needed, but consider rotating credentials used by Pulsar scalers as a precaution.

• breakingUpdate RBAC before upgrading — events.k8s.io migration is not optional

  If you use custom or restricted RBAC for KEDA, add create/patch on events.k8s.io/events to the operator role before you upgrade. The official Helm chart and manifests already handle this, but any out-of-tree RBAC will silently break event recording. Also audit your ScaledObjects for the four removed settings (GCP PubSub subscriptionSize, Huawei minMetricValue, IBM MQ tls, InfluxDB authToken in triggerMetadata) — resources using these will fail validation after upgrade.

• enhancementAWS cross-account scaling now works natively via External ID support

  The new External ID field in TriggerAuthentication podIdentity covers all AWS scalers. If you've been using workarounds for cross-account IAM assume-role scenarios, you can now use the native field. Update your TriggerAuthentication manifests to set the externalId field — no more custom IAM boundary hacks required.

Lima v2.1.2 is a broad maintenance release fixing hostagent resource leaks, zombie processes, and gRPC connection leaks — plus template updates for Kubernetes 1.36, Ubuntu 26.04, and Fedora 44.

• breakingAlpine template split — update your instance configs

  The generic `template:alpine` has been split into `template:alpine-3.21`, `template:alpine-3.22`, and `template:alpine-3.23`. If you reference `template:alpine` in scripts, CI, or configs, those references will break. Audit and update them to a specific versioned template before upgrading.

• breaking_LIMA_QEMU_UEFI_IN_BIOS is deprecated — stop using it

  If you have the `_LIMA_QEMU_UEFI_IN_BIOS` environment variable set in any scripts or dotfiles, remove it now. The flag is deprecated in this release and will likely be removed in a future version. Check wrapper scripts and CI pipelines that invoke limactl with QEMU.

• enhancementHostagent resource leak fixes — worth upgrading if you run long-lived instances

  Four separate hostagent fixes address GuestAgentClient leaks, inotify watcher accumulation, and gRPC stream mishandling on reconnect. If you've seen memory creep or stale connections in long-running Lima instances, this release directly addresses those issues. Upgrade proactively rather than waiting.

Volcano v1.15.0 ships gang-aware preemption/reclamation, DRA queue quota, autoscaler-friendly scheduling gates, and a batch of critical scheduler stability fixes addressing double-counting, race conditions, and rollback correctness.

• securityApply CVE-2026-44247 webhook DoS fix and Prometheus XSS patch

  v1.15.0 includes a mitigation for CVE-2026-44247, which allowed oversized webhook request bodies to exhaust webhook server memory. The Prometheus dependency is also updated for a stored XSS advisory (GHSA-vffh-x6r8-xx99). Upgrade to v1.15.0 if you expose Volcano admission webhooks — there's no workaround short of upgrading.

• breakingDon't mix gangPreempt/gangReclaim with legacy preempt/reclaim

  The new gangPreempt and gangReclaim actions are mutually exclusive with the legacy preempt and reclaim actions in a scheduler action list. If you upgrade and add gang-aware actions without removing the old ones, you'll get undefined behavior. Audit your scheduler ConfigMap before upgrading — pick one set or the other. Also note that DRA scheduling is now on by default; if your cluster doesn't have DRA-capable drivers, explicitly set predicate.DynamicResourceAllocationEnable: false.

• enhancementEnable Scheduling Gates to stop autoscaler over-scaling on queue limits

  If you run Cluster Autoscaler or Karpenter alongside Volcano, queue-blocked pods previously triggered unnecessary node scale-ups. The new scheduling gate feature fixes this cleanly. It's opt-in per pod via the scheduling.volcano.sh/queue-allocation-gate: 'true' annotation. Enable the feature gate on both the scheduler and webhook-manager, then annotate workloads that should respect queue admission before autoscaler signals fire. Good candidate workloads: batch jobs with strict queue quotas where you want to avoid wasted node provisioning.