longhorn

Update Helm release longhorn to v1.12.1

Michi Kofler-Häusler

Michi Kofler-Häusler

— 9 min read
Share
Update Helm release longhorn to v1.12.1
Photo by Tony Garcia / Unsplash

No problems deploying to Proxmox VE K3s Kubernetes cluster via Helm Chart and Flux V2 reconciliation in a GitOps approach.

This MR contains the following updates:

Package Update Change
longhorn (source) patch 1.12.0 → 1.12.1

Release Notes

longhorn/longhorn (longhorn)

v1.12.1: Longhorn v1.12.1

Compare Source

Longhorn v1.12.1 Release Notes

Longhorn v1.12.1 introduces V2 Data Engine fast volume cloning and storage sharding (experimental), along with important improvements and bug fixes that enhance system quality, resilience, stability, and security.

We welcome feedback and contributions to help continuously improve Longhorn.

For terminology and context on Longhorn releases, see Releases.

Breaking Changes

Deprecation of Legacy V2 Linked Clone Volumes

V2 linked-clone volumes created in v1.12.0 or earlier are marked as legacy and deprecated starting in v1.12.1. The new linked-clone architecture introduced in Issue #​12552 is not compatible with the legacy design.

After upgrading to v1.12.1, legacy linked-clone volumes cannot be operated on except for detachment and deletion.

To replace, create new linked-clone volumes from the same source volumes that back the legacy ones. As long as a legacy volume exists, its source volume is guaranteed to still be present, so you can create a replacement linked clone directly; no data copy is required.

For more information, see Issue #​12552.

Highlighted Features

Fast Volume Cloning

Longhorn v1.12.1 enhances fast volume cloning for the V2 Data Engine. A linked-clone volume shares data blocks with its source instead of copying data. With the new architecture, a source replica can share its data blocks with multiple linked-clone volumes, and multiple clone replicas can be created in parallel.

Linked-clone volumes now support most operations available to regular volumes, including snapshots, expansion, replica rebuilding, and use as the source of nested linked clones.

For more information, see Issue #​12552 and CSI Volume Clone.

[!NOTE]
V2 fast cloning does not currently support volume backup and restore. This improvement is tracked in Issue #​13714.

Storage Sharding (Experimental)

Longhorn v1.12.1 introduces storage sharding as an experimental data protection and storage layout feature built on the V2 Data Engine. Instead of storing a full copy of the volume on each replica, sharding uses erasure coding to encode written data into data and parity chunks, which are distributed across multiple nodes. This allows a volume to grow beyond the capacity of a single disk or node while using less disk space to achieve the same level of fault tolerance.

Because this feature is experimental, it is intended for evaluation and testing only and is not recommended for production use.

For more information, see Issue #​1061 and Sharding with Erasure Coding.

Important Improvements and Fixes

This release includes several important improvements and critical stability fixes.

Internal Network Policies

Longhorn v1.12.1 enables ingress NetworkPolicy resources for internal component endpoints and RPCs by default to improve security by restricting access to Longhorn internal services, including the instance-manager gRPC endpoint used for engine control. These policies only take effect when a NetworkPolicy provider is available in the cluster.

Longhorn has validated the internal network policies with the following Kubernetes distribution and CNI plugin combinations. See the CNI Plugin Compatibility table for the validated combinations. The minimum required Kubernetes version is v1.25.

For more information and troubleshooting guidance, see Internal Network Policies and Issue #​13438.

[!NOTE]
ServiceMonitor discovery does not automatically authorize network traffic. Cross-namespace Prometheus scrapers might be blocked by the Longhorn Manager's network policy. To allow this traffic, apply a scoped additive policy as detailed in the Prometheus and Grafana setup guide.

Instance Manager gRPC mTLS Coverage

In previous versions, mutual TLS (mTLS) for the instance-manager gRPC endpoint only covered the instance and proxy services when the longhorn-grpc-tls secret was configured. Other services, including the disk service and the SPDK service, accepted plaintext connections.

Longhorn v1.12.1 extends mTLS to all remaining instance-manager gRPC services, so every gRPC port now requires a valid client certificate when the longhorn-grpc-tls secret is configured.

For more information, see Issue #​7787.

CPU Core Allocation with the Kubernetes CPU Manager

Longhorn v1.12.1 can allocate exclusive CPU cores to the SPDK target daemon, which runs in each V2 Instance Manager pod, through the Kubernetes CPU Manager by using the data-engine-number-of-cpu-cores setting.

The setting can be applied only when the kubelet CPU Manager policy is set to static on all worker nodes; otherwise, the update is rejected. When the value is positive, it takes precedence, and data-engine-cpu-mask is ignored.

For more information, see Issue #​13248.

Host CPU Isolation

The data-engine-cpu-isolation-enabled setting now also configures host network Receive Packet Steering (RPS) to steer RX softirq processing away from the CPU cores used by the SPDK target daemon, in addition to hardware IRQs and unbound kernel workqueue workers. Without this, the kernel can distribute incoming network packets to the SPDK reactor cores, and the resulting softirq work competes with the reactor's busy-poll loop, degrading volume I/O under network load.

For more information, see Issue #​13483 and Issue #​13502.

V2 Data Engine SPDK iobuf Pool Size Configuration

Longhorn v1.12.1 allows tuning the SPDK iobuf buffer pools used by the V2 Data Engine. The data-engine-iobuf-large-pool-size and data-engine-iobuf-small-pool-size settings configure the large and 8 KiB small buffer pools, respectively. Increasing the small pool can relieve buffer exhaustion under high-queue-depth workloads with small I/O sizes. Because iobuf pools can only be sized at SPDK target startup, changing either setting recreates V2 Instance Manager pods that have no running instances.

For more information, see Issue #​13322 and Issue #​13674.

Encrypted Volume Size Correction

Longhorn reserves an additional 16 MiB of raw capacity for the LUKS2 metadata used by encrypted volumes, allowing the mapped device to expose the full capacity requested by the workload. Previously, the metadata was taken from usable capacity, so a requested 1 GiB encrypted volume exposed only 1008 MiB. This discrepancy could cause operations such as block-level copies between equally sized unencrypted and encrypted volumes to fail.

  • V1 Data Engine: This correction was introduced in Longhorn v1.12.0. Existing encrypted V1 volumes created with v1.11.x or earlier receive the additional capacity automatically when their engine image is upgraded to v1.12 or later. Encrypted migratable V1 volumes cannot be live-migrated until they are upgraded to the version (>= v1.12.0).
  • V2 Data Engine: Longhorn v1.12.1 applies the correction to newly created encrypted V2 volumes.

[!NOTE]
Encrypted V2 volumes created before v1.12.1, and volumes restored from the backup of such volumes, do not receive the additional 16 MiB of raw capacity and continue to expose 16 MiB less than requested. Existing data is preserved.

For more information, see Issue #​9205 and Issue #​13163.

Installation

[!IMPORTANT]
Ensure that your cluster is running Kubernetes v1.25 or later before installing Longhorn v1.12.1.

You can install Longhorn using a variety of tools, including Rancher, Kubectl, and Helm. For more information about installation methods and requirements, see Quick Installation in the Longhorn documentation.

Upgrade

[!IMPORTANT]
Ensure that your cluster is running Kubernetes v1.25 or later before installing Longhorn v1.12.1.

Longhorn only allows upgrades from supported versions. For more information about upgrade paths and procedures, see Upgrade in the Longhorn documentation.

Post-Release Known Issues

For information about issues identified after this release, see Release-Known-Issues.

Resolved Issues in this release

Highlight
Feature
Improvement
Bug
Resilience
  • [BACKPORT][v1.12.1][BUG] Transient SPDK lvol metadata failure can permanently fault a healthy v2 replica 13542 - @​roger-ryao
Misc

Contributors

Read more

Me on Mastodon - This link is here for verification purposes.