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. The WaitForFirstConsumer mode will delay the binding and provisioning of a PersistentVolume until a Pod using the PersistentVolumeClaim is created.

documentação

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

sig-storage-local-static-provisioner/default_example_storageclass.yaml at master · 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.