Important Notes
This page lists important notes for Longhorn v1.5.4. Please see here for the full release note.
Notes
Supported Kubernetes Versions
Please ensure your Kubernetes cluster is at least v1.21 before upgrading to Longhorn v1.5.4 because this is the minimum version Longhorn v1.5.4 supports.
Detach All V2 Volumes Before Upgrade
Please note that Longhorn does not support the upgrade when v2 volumes are attached. Prior to initiating the upgrade process, ensure that all v2 volumes are detached.
Offline Upgrade Required To Fully Prevent Unexpected Replica Expansion
Longhorn v1.5.2 introduces a new mechanism to prevent unexpected replica expansion. This mechanism is entirely transparent. However, a volume is only protected if it is running a new version of longhorn-engine inside a new version of longhorn-instance-manager and managed by a new version of longhorn-manager. The live upgrade process results in a volume running a new version of longhorn-engine in an old version of longhorn-instance-manager until it is detached (by scaling its consuming workload down) and reattached (by scaling its consuming workload up). Consider scaling workloads down and back up again as soon as possible after upgrading from a version without this mechanism (v1.5.1 or older) to v1.5.4.
Attachment/Detachment Refactoring Side Effect On The Upgrade Process
In Longhorn v1.5.0, we refactored the internal volume attach/detach mechanism. As a side effect, when you are upgrading from v1.4.x to v1.5.x, if there are in-progress operations such as volume cloning, backing image export from volume, and volume offline expansion, these operations will fail. You will have to retry them manually. To avoid this issue, please don't perform these operations during the upgrade. Ref: https://github.com/longhorn/longhorn/issues/3715#issuecomment-1562305097
Recurring Jobs
The behavior of the recurring job types Snapshot
and Backup
will attempt to delete old snapshots first if they exceed the retained count before creating a new snapshot. Additionally, two new recurring job types have been introduced, Snapshot Force Create
and Backup Force Create
. They retain the original behavior of taking a snapshot or backup first before deleting outdated snapshots.
Longhorn Uninstallation
To prevent Longhorn from being accidentally uninstalled (which leads to data lost), we introduce a new setting, deleting-confirmation-flag. If this flag is false, the Longhorn uninstallation job will fail. Set this flag to true to allow Longhorn uninstallation. See more in the uninstall section.
New Node Drain Policies Added
There are two new options for the Node Drain Policy setting. Both Block For Eviction
and Block for Eviction If Contains Last Replica
automatically evict replicas from draining nodes in
addition to preventing drain completion until volume data is sufficiently protected. Block for Eviction
maintains
maximum data redundancy during maintenance operations, and both new options enable automated cluster upgrades when some
volumes have only one replica. See the new Node Drain Policy
Recommendations section for help deciding which
policy to use.
Custom Resource Fields Deprecated
Starting in v1.5.4
, the following custom resource fields are deprecated. They will be removed in v1.7.0
:
- Volume.status.evictionRequested
Pod Security Policies Disabled & Pod Security Admission Introduction
-
Longhorn pods require privileged access to manage nodes' storage. In Longhorn
v1.3.x
or older, Longhorn was shipping some Pod Security Policies by default, (e.g., link). However, Pod Security Policy has been deprecated since Kubernetes v1.21 and removed since Kubernetes v1.25, link. Therefore, we stopped shipping the Pod Security Policies by default. For Kubernetes < v1.25, if your cluster still enables Pod Security Policy admission controller, please do:- Helm installation method: set the helm value
enablePSP
totrue
to installlonghorn-psp
PodSecurityPolicy resource which allows privileged Longhorn pods to start. - Kubectl installation method: need to apply the podsecuritypolicy.yaml manifest in addition to applying the
longhorn.yaml
manifests. - Rancher UI installation method: set
Other Settings > Pod Security Policy
totrue
to installlonghorn-psp
PodSecurityPolicy resource which allows privileged Longhorn pods to start.
- Helm installation method: set the helm value
-
As a replacement for Pod Security Policy, Kubernetes provides a new mechanism, Pod Security Admission. If you enable the Pod Security Admission controller and change the default behavior to block privileged pods, you must add the correct labels to the namespace where Longhorn pods run to allow Longhorn pods to start successfully (because Longhorn pods require privileged access to manage storage). For example, adding the following labels to the namespace that is running Longhorn pods:
apiVersion: v1
kind: Namespace
metadata:
name: longhorn-system
labels:
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/enforce-version: latest
pod-security.kubernetes.io/audit: privileged
pod-security.kubernetes.io/audit-version: latest
pod-security.kubernetes.io/warn: privileged
pod-security.kubernetes.io/warn-version: latest
Updating CSI Snapshot CRD v1beta1
to v1
, v1beta1
Removed
Support for the v1beta1
version of CSI snapshot CRDs was previously deprecated in favor of the v1
version.
The CSI components in Longhorn v1.5.4 only function with the v1
version.
Please follow the instructions at Enable CSI Snapshot Support to update CSI snapshot CRDs and the CSI snapshot controller.
If you have Longhorn volume manifests or scripts that are still using v1beta1
version, you must upgrade them to v1
as well.