リリース

Longhorn v1.11.3は、ボリューム操作・バックアップ・インスタンス管理にまたがる十数件の安定性問題を修正するバグフィックスロールアップです。CSI external provisionerがv6.3.0へ更新されたため、v1.10.xまたはv1.11.0からアップグレードする場合はKubernetes v1.34以降が前提条件となります。

• breakingv1.10.xまたはv1.11.0からのアップグレード時にKubernetes v1.34+が必要

  CSI external provisionerがv6.3.0に更新されたため、Longhorn v1.10.xまたはv1.11.0からアップグレードする場合はKubernetes v1.34以降が必要です。クラスタのKubernetesバージョンを先にv1.34+へ更新してからLonghornをアップグレードしてください。

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.

Longhorn v1.11.2 is a stability-focused patch fixing CSI scheduling breakage in compute/storage split architectures, infinite replica scheduling loops, and memory bloat in longhorn-manager.

• breakingFix CSI scheduling in compute/storage split clusters — action required

  If you run a dedicated compute/storage node architecture and use WaitForFirstConsumer PVCs, your pods may have been stuck pending due to compute nodes reporting 0 CSI capacity. Upgrade to v1.11.2 and configure the new CSIStorageCapacity setting to prevent capacity reporting on non-storage nodes. Check your Longhorn settings after upgrade and validate that pending PVCs now schedule correctly.

• breakingReplica Auto-Balance infinite loop — upgrade if you use Auto-Balance

  A bug caused Replica Auto-Balance to enter an infinite scheduling loop, which wastes CPU and can destabilize volume operations. If Auto-Balance is enabled in your cluster, this is a strong reason to prioritize this patch. No config change needed after upgrade — the fix is in the reconciliation logic.

• enhancementMemory savings in longhorn-manager — relevant for large clusters

  Informer caching for longhorn-manager has been optimized to reduce cluster-wide memory consumption. In large clusters with many nodes and volumes, this can meaningfully reduce the manager pod's footprint. No action required beyond upgrading, but worth monitoring memory usage before and after to quantify the improvement in your environment.

Longhorn v1.11.1 delivers critical bug fixes including a major memory leak in instance manager pods and backup failures with S3-compatible storage, making it an urgent upgrade for v1.11.0 users.

• securityBackup restore functionality compromised

  S3-compatible backup targets (Storj, GCS) were failing due to AWS SDK v2 authorization issues. Test your backup and restore workflows after upgrading, especially if using non-AWS S3 endpoints. Verify large backup transfers complete successfully.

• breakingUrgent upgrade required for v1.11.0 users

  Users running v1.11.0 experiencing high memory usage in instance manager pods must upgrade immediately. The memory leak can cause cluster instability and pod evictions. Plan upgrade maintenance window and monitor memory usage during rollout.

• enhancementImproved scheduling with topology awareness

  New CSI topology-aware nodeAffinity controls provide better volume placement. Review your storage class configurations to leverage allowedTopologies and strictTopology settings for multi-zone deployments and specific node scheduling requirements.