When I push my deployments, for some reason, I'm getting the error on my pods:
pod has unbound PersistentVolumeClaims
Here are my YAML below:
This is running locally, not on any cloud solution.
apiVersion: extensions/v1beta1
kind: Deployment
metadata: annotations: kompose.cmd: kompose convert kompose.version: 1.16.0 () creationTimestamp: null labels: io.kompose.service: ckan name: ckan
spec: replicas: 1 strategy: {} template: metadata: creationTimestamp: null labels: io.kompose.service: ckan spec: containers: image: slckan/docker_ckan name: ckan ports: - containerPort: 5000 resources: {} volumeMounts: - name: ckan-home mountPath: /usr/lib/ckan/ subPath: ckan volumes: - name: ckan-home persistentVolumeClaim: claimName: ckan-pv-home-claim restartPolicy: Always
status: {}kind: PersistentVolumeClaim
apiVersion: v1
metadata: name: ckan-pv-home-claim labels: io.kompose.service: ckan
spec: storageClassName: ckan-home-sc accessModes: - ReadWriteOnce resources: requests: storage: 100Mi volumeMode: Filesystem
---
kind: StorageClass
apiVersion:
metadata: name: ckan-home-sc
provisioner:
mountOptions: - dir_mode=0755 - file_mode=0755 - uid=1000 - gid=1000 3 Answers
You have to define a PersistentVolume providing disc space to be consumed by the PersistentVolumeClaim.
When using storageClass Kubernetes is going to enable "Dynamic Volume Provisioning" which is not working with the local file system.
To solve your issue:
- Provide a PersistentVolume fulfilling the constraints of the claim (a size >= 100Mi)
- Remove the
storageClassfrom the PersistentVolumeClaim or provide it with an empty value ("") - Remove the StorageClass from your cluster
How do these pieces play together?
At creation of the deployment state-description it is usually known which kind (amount, speed, ...) of storage that application will need.
To make a deployment versatile you'd like to avoid a hard dependency on storage. Kubernetes' volume-abstraction allows you to provide and consume storage in a standardized way.
The PersistentVolumeClaim is used to provide a storage-constraint alongside the deployment of an application.
The PersistentVolume offers cluster-wide volume-instances ready to be consumed ("bound"). One PersistentVolume will be bound to one claim. But since multiple instances of that claim may be run on multiple nodes, that volume may be accessed by multiple nodes.
A PersistentVolume without StorageClass is considered to be static.
"Dynamic Volume Provisioning" alongside with a StorageClass allows the cluster to provision PersistentVolumes on demand. In order to make that work, the given storage provider must support provisioning - this allows the cluster to request the provisioning of a "new" PersistentVolume when an unsatisfied PersistentVolumeClaim pops up.
Example PersistentVolume
In order to find how to specify things you're best advised to take a look at the API for your Kubernetes version, so the following example is build from the API-Reference of K8S 1.17:
apiVersion: v1
kind: PersistentVolume
metadata: name: ckan-pv-home labels: type: local
spec: capacity: storage: 100Mi hostPath: path: "/mnt/data/ckan"The PersistentVolumeSpec allows us to define multiple attributes.
I chose a hostPath volume which maps a local directory as content for the volume. The capacity allows the resource scheduler to recognize this volume as applicable in terms of resource needs.
Additional Resources:
6I ran into this issue but I realized that I was creating my PV's with "manual" StorageClass type.
YOUR POD Expects what kind of storage class?
YOUR PVC Definition volumeClaimTemplates --> storageClassName : "standard"
PV spec --> storageClassName : "standard"
If your using rancher k3s kubernetes distribution, set storageClassName to local-path as described in the doc
apiVersion: v1
kind: PersistentVolumeClaim
metadata: name: local-path-pvc namespace: default
spec: accessModes: - ReadWriteOnce storageClassName: local-path resources: requests: storage: 2GiTo use it on other distributions use