K
Q

Persistent volume isn't matched with a claim

4/19/2019

I created a simple local storage volume. Something like this:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: vol1
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /srv/volumes/vol1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - my-node

The I create a claim:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage:1Gi

For unknow reason they don't get matches. What am I doing wrong?

-- Konstantin Solomatov
kubernetes
persistent-volume-claims
persistent-volumes

Similar Questions

Whitelisting IP addresses for network traffic through Istio gateways
FailedAttachVolume error on Kubernetes with StorageOS
Grabbing a pod's IP address from another pod
Kubernetes Master Worker Node Kubeadm Join issue
How to expose nginx in Minikube to outside
Getting ImagePullBackOff when starting a POD is AWS EKS

3 Answers

4/20/2019

I figured it out. I just needed a user. As long as I had a user, everything worked perfectly.

-- Konstantin Solomatov
Source: StackOverflow
4/26/2019

About local storage it is worth to note that:

Using local storage ties your application to that specific node, making your application harder to schedule. If that node or local volume encounters a failure and becomes inaccessible, then that pod also becomes inaccessible. In addition, many cloud providers do not provide extensive data durability guarantees for local storage, so you could lose all your data in certain scenarios.

This is for Kubernetes 1.10. In Kubernetes 1.14 local persistent volumes became GA.

You posted an answer that user is required. Just to clarify the user you meant is a consumer like a pod, deployment, statefullset etc. So using just a simple pod definition would make your PV to become bound:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

Now the problem happens when you would delete the pod and try to run another one. In this case if you or someone else wold look for a solution it has been described in this GitHub issue.

Hope this clears things out.

-- aurelius
Source: StackOverflow
4/20/2019

You should specify volumeName in your PVC to bind that specifically to the PV that you just created as so:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeName: "vol1"
  resources:
    requests:
      storage:1Gi

Additionally, if you specify storageClassName in your PVC, your PVC will also get bound to a PV matching that specification (though it doesn't guarantee that it will be bound to your "vol1" PV if there are more than 1 PVs for that storage class).

Hope this helps!

-- Frank Yucheng Gu
Source: StackOverflow