K
Q

Kubernetes PersistentVolume and PersistentVolumeClaim could be causing issues for my pod which crashes while copying logs

9/25/2017

I have a PersistentVolume that I specified as the following:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv-shared
spec:
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 5Gi
  hostPath:
    path: /data/mypv-shared/

Then I created a PersistentVolumeClaim with the following specifications:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypv-shared-claim
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

But when I create the PVC, running kubectl get pv shows that it is bound to a randomly generated PV

NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM                           STORAGECLASS   REASON    AGE
pvc-38c77920-a223-11e7-89cc-08002719b642   5Gi        RWX           Delete          Bound       default/mypv-shared             standard                 16m

I believe this is causing issues for my pods when running tests because I am not sure if the pod is correctly mounting the specified directory. My pods crash at the end of the test when trying to copy over the test logs at the end of the run.

Is the cause really the persistentVolume/Claim or should I be looking into something else? Thanks!

-- appdap1
docker
kubernetes
minikube
selenium
selenium-grid

Similar Questions

Kubernetes dashboard - ServiceUnavailable (503 error)
Will a pod be restarted with send SIGTERM by Kubernetes
Does Kubernetes do network calls to containers on same host to reduce network traffic?
Ingress for SpringBoot service

1 Answer

9/25/2017

Creating the PVC dynamically provisioned a PV instead of using the one you created manually with the hostpath. On the PVC simply set .spec.storageClassName to and an empty string ("")

From the documentation:

A PVC with its storageClassName set equal to "" is always interpreted to be requesting a PV with no class, so it can only be bound to PVs with no class (no annotation or one set equal to ""). A PVC with no storageClassName is not quite the same ...

So create something like this (I've also added labels and selectors to make sure that the intended PV is paired up the PVC; you might not need that constraint):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv-shared
  labels:
    name: mypv-shared
spec:
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 5Gi
  hostPath:
    path: /data/mypv-shared/
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypv-shared-claim
spec:
  storageClassName: ""
  selector:
    matchLabels:
      name: mypv-shared
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
-- Janos Lenart
Source: StackOverflow