Could you kindly clarify how to read or edit files on a (using longhorn sc) persistent volume? Would you kindly provide a quick explanation of this with examples?
Kubernetes version: 1.24.3
Cloud being used: (put bare-metal on-premise)
Installation method: kubeadm
Host OS: Ubuntu arm64 20.04
CNI and version: cri-o://1.23.3
CRI and version: flannel
You can format your yaml by highlighting it and pressing Ctrl-Shift-C, it will make your output easier to read.
When you provide a persistent volume in the pod definition, you specify where the volume is mounted in the pod’s filesystem; in the following example (copied from Volumes), the volume is mounted on
The application running in the container (
k8s.gcr.io/test-webserver in the example) can read or write as it would normally do in Linux. Say you want to create a file in the volume, you can just
echo "Hello world" > /test-ebs/hello.txt and read it using
As you created the volume (or requested one) specifying a StorageClass, the details on how to specifically “talk” to the storage backend are known to Kubernetes, so your process inside the container does not have to care about how it is actually “writing bytes” to the storage support.
If you deployed your pod in AWS and requested a volume, it would likely be an EBS volume. If you want to test the same application of your on-premises cluster (having Longhorn as a storage backend), the application will keep writing and reading files as it did when it is deployed in AWS.
Again, all the application running inside the pod cares about is that the volume is mounted in the pod’s filesystem, so it will write to and read from the mount point no matter what the storage backend is.
- image: k8s.gcr.io/test-webserver
- mountPath: /test-ebs
- name: test-volume
# This AWS EBS volume must already exist.
volumeID: "<volume id>"
Thanks, This is going to work. I must connect to the PV using FTP, though, in order to access the files with read and update privileges.I tried the NFS technique, and it worked, but would PV work?