nfs-subdir-external-provisioner VS kustomize

Using nfs-subdir-external-provisioner instead of csi-driver-nfs

I am trying to run sonarr inside my k3s cluster. Since I have multiple nodes, in order to keep data persistant I have been using a NAS and the Kubernetes NFS external provisioner as my Storage Class.

There's this, if you want your nfs storage available to pods as PVCs, with some limitations: https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

NFS Provisioner

Depends on how much resiliency you need . Something like https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner works well for a lab or non-prod cluster. You could even use something like this in prod if you have access to highly reliably NFS mounts.

I first installed a NFS Server via this helm chart: https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner Eventually I deployed Longhorn cause I needed expandable volumes, which the first repo doesn't support. I guess for best performance you should go for a ceph cluster, but I'm not an expert.

I used the NFS provisioner for persistent volumes until I got the Ceph side up and running. I created a share on my NAS specifically for k8s. It worked very well and had the bonus of being just a regular file system that you could browse/edit easily (just place files in or edit config). I would agree with not moving plex into k8s. I right now just have a barebones 1 control 2 worker setup using k3s.

However, is it too difficult to create new pods/deployments etc on your own? I find it super easy to just create a PVC (via https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner ) and create a MySQL pod in a new namespace for every micro service I create.

This is what you need https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner Point it to a folder and it will create subfolders for each PVC.

kustomize: brew install kustomize

It's a built in feature of kustomize https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/helmchartargs.go

I think the combination of Kustomize and helm works in my experience. For advanced use cases, you can also see KRM functions in Kustomize.

See for instance a related issue: https://github.com/kubernetes-sigs/kustomize/issues/3866

Using a strategic merge is the safest way so you avoid the index fragility.

Rendering out the manifests is something I have been pushing for. Not having to understand how every templating tool works and what actually is being changed is key. Though, it gets complicated when you use helm (or any templating/patching tool) that produces many variants. You also lose any release/deployment time hooks that are provided (helm hooks or recently "patched" kustomize env variables).

https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md (edit: oh I see the other commenter also included this link, oops)

Kustomize is an open-source project that “lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as is.” It’s now the most popular tool for customizing Kubernetes manifests reasonably, and it’s even built directly into the Kubernetes CLI since K8s v1.14.