CODEWITHSUNDEEP
google-kubernetes-engineprometheus
Dhody Rahmad Hidayat
Dhody Rahmad Hidayat

Reputation: 457

PVC bound but not found by pods on GKE

I upgrade machine of GKE to the new larger machine. All application looks fine until one pod still on pending state. After cordon and drain set to the old pods, my prometheus pod still pending.

On pod describe it shows enter image description here

I already recreate both deployment and PVC, but the result still the same. On PVC it shows..

enter image description here

enter image description here

On the describe, it said that the PVC used by prometheus deployment. The fact is the deployment still at pending state. How to resolve this? any suggestion would be appreciated

Upvotes: 0

Views: 2274

Answers (1)

Jyothi Kiranmayi
Jyothi Kiranmayi

Reputation: 2498

Pending status of the PVCs could mean you have no corresponding PVs. If you use a PersistentVolumeClaim you typically need a volume provisioner for Dynamic Volume Provisioning

Unless you configure your cluster with dynamic volume provisioning , you will have to make the PV manually each time.

You have to define a PersistentVolume providing disk space to be consumed by the PersistentVolumeClaim. PersistentVolumeClaims will remain unbound indefinitely if a matching PersistentVolume does not exist.

When using storageClass Kubernetes is going to enable "Dynamic Volume Provisioning" which is not working with the local file system.

Dynamic volume provisioning allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make calls to their cloud or storage provider to create new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes.

To solve your issue:

  • Provide a PersistentVolume fulfilling the constraints of the claim (a size >= 100Mi).
  • Remove the storageClass from the PersistentVolumeClaim or provide it with an empty value ("").
  • Remove the StorageClass from your cluster.

Also make sure that PV capacity >= PVC capacity then PVC should be bound to PV. The capacity in the PV needs to be the same as in the claim to fix the unbound immediate PersistentVolumeClaims issue. If not then we'll get the unbound immediate PersistentVolumeClaims error in the pod level and no volume plugin matched name when describing the PVC.

Refer Configure a Pod to Use a PersistentVolume for Storage which describes how to create a PersistentVolume with a hostPath and refer stackpost for more information on pod has unbound PersistentVolumeClaims error.

Upvotes: 1

Related Questions