Deployments
Where possible, I converted my Kubernetes StatefulSets to Deployments. Because that’s what you do.
Local Persistent Volumes
The evolution of my cluster has been something like this:
- Single node
- Multi-node with Longhorn StorageClass
- Single node with Longhorn StorageClass
- Single node with no StorageClass, using HostPath for pod storage
This isn’t intrinsically bad, but it does cause problems with Helm charts.
- Install the Helm release
- A PersistentVolumeClaim is created
- Shit doesn’t work because no PersistentVolume gets made
My terrible workaround for this was to install a Helm chart, then go and edit the Deployment/StatefulSet to use hostPath.
This is not a good way of doing things, primarily because an upgrade to the installed Helm release blows away my hostPath modifications and then my service stops working. Because of this, things which I have installed using Helm are infrequently updated, which is bad.
So, I did a bit of research, and came across this blog post. This seemed to address my problems exactly. Then, I read the documentation. And it worked! This is how things should be done in the future:
- Install the Helm release
- Check the PersistantVolumeClaims that it made
- Manually create PersistentVolumes corresponding to the PVCs
- PVCs bind to the PVs and pods come up as expected!
This creates some a lot of rework, but should facilitate easier maintenance going forward. For each installed Helm release:
- Adjust answers/values.yaml with good storage capacity
- Re-install Helm release
- Check the PersistentVolumeClaims that were created
- Create corresponding local PersistentVolumes
- Sleep well knowing that keeping my services up-to-date just got a lot easier.
Also need to apply the same treatment to services installed via manifests. Time consuming, but not difficult.
tl;dr – hostPath BAD, local volumes GOOD.
sig-storage-local-static-provisioner looks to be a thing to help with local volume management. I’ll test this in a VM before throwing into my running cluster.
Leave a Reply