How many StorageClasses
exist in the cluster right now? 1
$ kubectl get sc
NAME local-path (default)
PROVISIONER rancher.io/local-path
RECLAIMPOLICY Delete
VOLUMEBINDINGMODE WaitForFirstConsumer
ALLOWVOLUMEEXPANSION false
$ kubectl get sc local-path -o yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: local-path
provisioner: rancher.io/local-path
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
How about now? How many Storage Classes exist in the cluster? 3 We just created a few new Storage Classes. Inspect them.
$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION
local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false
local-storage kubernetes.io/no-provisioner Delete WaitForFirstConsumer false
portworx-io-priority-high kubernetes.io/portworx-volume Delete Immediate false
$ kubectl get sc local-storage -o yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: local-storage
**provisioner: kubernetes.io/no-provisioner**
reclaimPolicy: Delete
**volumeBindingMode: WaitForFirstConsumer**
$ kubectl get sc portworx-io-priority-high -o yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: portworx-io-priority-high
parameters:
priority_io: high
repl: "1"
snap_interval: "70"
**provisioner: kubernetes.io/portworx-volume**
reclaimPolicy: Delete
**volumeBindingMode: Immediate**
volumeBindingMode The
Immediate
mode indicates that volume binding and dynamic provisioning occurs once the PersistentVolumeClaim is created. TheWaitForFirstConsumer
mode will delay the binding and provisioning of a PersistentVolume until a Pod using the PersistentVolumeClaim is created.
What is the name of the Storage Class
that does not support dynamic
volume provisioning? local-storage
https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner
(…) It does not support dynamic provisioning.
What is the Volume Binding Mode
used for this storage class (the one identified in the previous question)? WaitForFirstConsumer
What is the Provisioner
used for the storage class called portworx-io-priority-high
?
$ kubectl get sc portworx-io-priority-high -o yaml
(...)
metadata:
name: portworx-io-priority-high
(...)
**provisioner: kubernetes.io/portworx-volume**
(...)
Is there a PersistentVolumeClaim
that is consuming the PersistentVolume
called local-pv
?
$ kubectl get pvc --all-namespaces
No resources found
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY **STATUS** **CLAIM** STORAGECLASS
local-pv 500Mi RWO Retain **Available** local-storage
Let's fix that. Create a new PersistentVolumeClaim
by the name of local-pvc
that should bind to the volume local-pv
.
Inspect the pv local-pv
for the specs.
$ kubectl get pv local-pv -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
**name: local-pv**
spec:
**accessModes:
- ReadWriteOnce**
**capacity:
storage: 500Mi**
local:
path: /opt/vol1
persistentVolumeReclaimPolicy: Retain
**storageClassName: local-storage**
volumeMode: Filesystem
status:
phase: Available
Quando storageClassName: “”
o PV não foi obtido(bound) pelo PVC.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 30s default-scheduler 0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
Quando storageClassName: local-storage
o PV foi obtido(bound) pelo PVC.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: local-storage
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: local-pvc
spec:
storageClassName: local-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Mi
---
apiVersion: v1
kind: Pod
metadata:
name: use-pvc
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- name: test-vol
mountPath: /teste
volumes:
- name: test-vol
persistentVolumeClaim:
claimName: local-pvc
$ kubectl get sc,pv,pvc,pod
**NAME** PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION
**local-storage** kubernetes.io/no-provisioner Delete WaitForFirstConsumer false
NAME **CAPACITY** **ACCESSMODES** **RECLAIMPOLICY** **STATUS** **CLAIM** **STORAGECLASS** REASON
local-pv **500Mi** **RWO** **Retain** **Bound** **default/local-pvc** **local-storage**
**NAME** **STATUS** **VOLUME** **CAPACITY** **ACCESS** MODES **STORAGECLASS**
**local-pvc** **Bound** **local-pv** **500Mi** **RWO** **local-storage**
NAME READY STATUS RESTARTS AGE
use-pvc 1/1 Running 0 6m38s
What is the status of the newly created Persistent Volume Claim? Pending
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS
local-pvc Pending local-storage
Why is the PVC in a pending state despite making a valid request to claim the volume called local-pv
? Inspect the PVC events.
k describe pvc local-pvc
Name: local-pvc
Namespace: default
StorageClass: local-storage
Status: Pending
Volume:
Labels: <none>
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Used By: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal WaitForFirstConsumer 15s (x10 over 2m15s) persistentvolume-controller waiting for first consumer to be created before binding
The Storage Class called local-storage
makes use of VolumeBindingMode
set to WaitForFirstConsumer
. This will delay the binding and provisioning of a PersistentVolume until a Pod using the PersistentVolumeClaim is created.