I’m quite impressed with Longhorn and I’ve been using it since before v1 version. The stack is not without bug, but it becomes more and more stable with new useful features added over time.
These are some issues that I encountered in the past and how to solve them.
Perhaps, because I’m using self-managed Kubernetes (I construct the cluster myself in Hetzner), very often my nodes experienced “disruptions”. My nodes are in Hetzner Cloud, which is a shared VPS. I assume, since it is a shared VPS, there are some limit imposed by Hetzner that cause all of my pods in that node be killed. In this situation, Kubernetes will not create new pods, but instead restart the container.
The problem is, when the container restarts, the CSI doesn’t attach anymore so you get container with invalid state, it can’t access the volumes. It will be stuck in a restart loop.
How to fix:
You restart the Deployment/Statefulset manually. This will cause the pods to be recreated again, so Longhorn will attach the volume.
Since Longhorn 1.2.0, they implemented a default behavior that if a volume were detached unexpectedly, the pods will be recreated. You can change this settings by looking at this reference
This happens randomly sometimes when pods are migrated to different node. Usually from eviction rules, or if the node is Cordoned/Drained. Even when you recreate the pods multiple times, the event log says that it can’t start the pod because it can’t attach a set of volumes (it will tell you which PVC can’t be attached).
How to fix:
Take note of PVCs that can’t be attached. Track down which PersistentVolume it bounds to. The reason this happens is because Longhorn still thinks that a different node owns the Volume attachment.
How do I know it? It’s a little bit complicated, but in summary you need to get the attachment process logs and know how Longhorn works. When Longhorn attach a Volume, it will only attach a Replica. From the Longhorn Volume CRD, you will get the replicas. From Longhorn Replica CRD, you will get the name of the instance manager. Then you tail the logs of the instance manager pod that does the attachment.
Long story stort, before proceeding, make sure that no one is actually accessing your volume. Scale down any pods that uses the Volume. Use Longhorn UI to make sure that the Volumes are in a Detached state.
Open Longhorn Volume CRD (not Kubernetes core PersistentVolume object). I usually uses Rancher to see the YAML manifests, but you can use other tools. For example, the equivalent kubectl command:
# if you don't know the full CRD name, list it using api-resources kubectl get api-resources | grep longhorn # You will see that the Longhorn Volume CRD is in volumes.longhorn.io API # The Volume itself is stored in your Longhorn namespace, usually in longhorn-system kubectl -n longhorn-system edit volumes.longhorn.io <volume-name>
Here’s an example of the resource. It is truncated to show only the relevant part:
apiVersion: longhorn.io/v1beta1 kind: Volume name: pvc-d84ab4dc-11d9-4436-9f2f-8d07cafb5a46 namespace: longhorn-system spec: nodeID: worker-large4 status: currentNodeID: worker-large4 ownerID: worker-large4 pendingNodeID: ""
If your volume is stuck to any particular node, which is not the node the pod is trying to run, then it will not attach. What you do is to make sure that all
Once you apply the edit. Attach the volume again by running the pods/scale up. It doesn’t matter if after you apply, the Volume resources still got assigned a nonempty node ID fields in any keys I mentioned above. What is important is that when you edit the resources and save, the manager will be notified and takes care the detachment. So, this time the attachment will work.
If your pod still doesn’t run. Check the pod event again. Perhaps more than one volumes are stuck, so you need to take care all of them.
If you are using Longhorn since before v1, you will know that Longhorn only supports RWO (ReadWriteOnce) Volume. That means, it can only be attached to a single node, but it can be attached to more than one pods in the same node.
If the Pod event says the Volume can’t be attached because it is already been attached elsewhere, then you don’t have any other options. You must schedule all the pods that access the same Volume to be in the same node. There is no other way.
Of course this defeats the purpose of Horizontal Scalability, but that is another topic. With RWO Volume, you can only use multiple pods in one node to access the same Volume.
How to fix:
There are several ways to do this. Refer to Kubernetes documentation on how to schedule pods. Here’s some of them:
- In Pod template spec in your workload, assign directly to the name of the node where the Volume is currently attached
- Use Pod Affinity so that one Workload can decide where it is going to be run, then other Workload’s Pod uses Pod Affinity to be placed in the same node with the previous Workload.
Alternatively, Longhorn now supports (somewhat experimental) RWX (ReadWriteMany) Volumes, which is a regular Longhorn Volume, but exposed via NFS by Longhorn Share Manager. You can move your data to this new volume type and then mount the volume from any node in the cluster (no need to use affinity).
It is a very rare case, since Longhorn can handle Faulted replicas just fine. But it can happen if you only have one replica, not enough disk space, and then your node got disrupted. If you have enough space, Longhorn can make a snapshot and try to recover the replica even with just one replica. But if you don’t have enough space it will not know what to do. You need to make decision. This is called a “Salvage” operation by Longhorn.
How to fix:
You can try the Salvage button first from the Longhorn UI of the Volume. If it doesn’t do anything, then definitely you only have one replica with not enough disk space in the node.
To force mount the volume, we need to do a little trick to let Longhorn think that the volume is okay.
Find your Faulted replica name from the Longhorn UI (easiest method I can think of). Of course you can also track it via CLI by opening the CRD, but via Longhorn UI is the fastest:
- Open the Volume tab in Longhorn UI, filter by Status, choose Faulted.
- Click your Faulted Volume.
- In the Volume menu, click Salvage (if you have more than one replicas). If it doesn’t work, just delete the Faulted replicas so Longhorn will create a new one
- If you only have one replica and you want to try to force mount, take note of the replica name.
Now with the replica name, you can edit it’s resource YAML manifests. I used to do it via Rancher, but if you want to do it via kubectl:
# if you don't know the full CRD name, list it using api-resources kubectl get api-resources | grep longhorn # You will see that the Longhorn Replica CRD is in replicas.longhorn.io API # The Replica itself is stored in your Longhorn namespace, usually in longhorn-system kubectl -n longhorn-system edit replicas.longhorn.io <replica-name>
Here’s the sample YAML, trimmed to only show relevant section:
apiVersion: longhorn.io/v1beta1 kind: Replica metadata: name: pvc-04b355d9-d2ac-4e20-9aad-c545d3cda70b-r-3d6b5e4d namespace: longhorn-system spec: failedAt: "2021-12-16T13:46:18Z"
However, I should mention that this is a very hacky thing to do. If you experience this very often and your data is very important (like transaction logs or something), I suggest you to use multiple replicas instead next time.
Those issues I mentioned above are the most common. If you use Longhorn, you will find that it’s snapshotting ability is what really important. You can have fault any day but if you have snapshots, you will be fine. As you may have know, Kubernetes already defines alpha/beta volume snapshot spec, but not every CSI supports it. Longhorn allow us to fill this gap with useful UI and scheduled snapshot abilities. This is the reason why I’m still using Longhorn instead of Hetzner CSI driver, because Hetzner volume can’t be snapshotted to my knowledge.