How to reference a local volume in Kind (kubernetes in docker)

I'd like to set up a Persistent Volume (PV and PVC) shared by pods in a kind cluster. However, I need to ensure that the data is persisted on my laptop (host server) as well. Therefore, the volume's path should be on my laptop that I can directly access.

If I delete the kind cluster, the volume should be persisted and not destroyed.

I also want to be able to easily add, update, or copy files from that volume on my host laptop.

How can I make the pods in the Kind cluster aware of this setup?

Please find my kind.yaml file for your reference.

$ kind
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
- role: worker

Solution

When you create your kind cluster you can specify host directories to be mounted on a virtual node. If you do that, then you can configure volumes with hostPath storage, and they will refer to the mount paths on the node.

So you would create a kind config file:

apiVersion: kind.x-k8s.io/v1alpha4
kind: Cluster
nodes:
  - role: control-plane
    extraMounts:
      - hostPath: /home/bill/work/foo
        containerPath: /foo

and then run

kind create cluster --config kind-config.yaml

to create the cluster.

In your Kubernetes YAML file, you need to mount that containerPath as a "host path" on the node. A pod spec might contain in part:

volumes:
  - name: foo
    hostPath:
      path: /foo  # matches kind containerPath:
containers:
  - name: foo
    volumeMounts:
      - name: foo
        mountPath: /data  # in the container filesystem

Note that this setup is extremely specific to kind. Host paths aren't reliable storage in general: you can't control which node a pod gets scheduled on, and both pods and nodes can get deleted in real-world clusters. In some hosted setups (AWS EKS, Google GKE) you may not be able to control the host content at all.

You might revisit your application design to minimize the need for "files" as first-class objects. Rather than "update the volume" consider deploying a new Docker image with updated content; rather than "copy files out" consider an HTTP service you can expose through an ingress controller.