The local-path-provisioner is a persistent volume provisioner dedicated for a kind based kubernetes cluster. Using it both simplifies helm charts and provides a better compatibility with EKS gp2 and gp3 storage clasess. In this post we will see how to use it.
Working Without a Provisioner
In case we don't have a provisioner we need to manually handle the persistent volume creation as part of the helm chart. This can be done using a new dedicated storage class for our kind development cluster. For example:
{{- if eq .Values.data.storageClass "development-storage" }}
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-1
labels:
type: local
spec:
storageClassName: development-storage-class
capacity:
storage: 10G
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/hostpath/data"
{{- end }}
Then we need to specify this storage class as part of the persistent volume claim:
volumeClaimTemplates:
- metadata:
name: my-pvc
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "development-storage-class"
resources:
requests:
storage: 10G
Using The Local-Path-Provisioner
To use the local-path-provisioner we install it:
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
And then all we need it to specify local-path as the storage class, for example:
volumeClaimTemplates:
- metadata:
name: my-pvc
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "local-path"
resources:
requests:
storage: 10G
We not only gain this simpler helm chart, but also permissions respectful provisioner. This simplifies life for pods that use modified security context such as grafana and clickhouse:
securityContext:
runAsUser: 50001
runAsGroup: 50001
fsGroup: 50001
fsGroupChangePolicy: OnRootMismatch
Final Note
Actually, I guess I've got used to using the old method without the local-path-provisioner that I took it as is. Now that I know the local-path-provisioner, I think to myself, well why the complexity, I should have known it earlier.
No comments:
Post a Comment