nerdexam
Google

PROFESSIONAL-CLOUD-DEVELOPER · Question #297

You recently deployed an application to GKE where Pods are writing files to a Compute Engine persistent disk. You have created a PersistentVolumeClaim (PVC) and a PersistentVolume (PV) object on…

The correct answer is C. Set the spec.resources.requests.storage value of the PVC object to match the size of the. In Kubernetes, resizing a PersistentVolume is driven by updating the PVC's spec.resources.requests.storage to the new desired size. The Kubernetes volume expansion controller detects this change, triggers the CSI driver to resize the underlying disk, and then resizes the…

Managing application infrastructure

Question

You recently deployed an application to GKE where Pods are writing files to a Compute Engine persistent disk. You have created a PersistentVolumeClaim (PVC) and a PersistentVolume (PV) object on Kubernetes for the disk, and you reference the PVC in the deployment manifest file. You recently expanded the size of the persistent disk because the application has used up almost all of the disk space. You have logged on to one of the Pods, and you notice that the disk expansion is not visible in the container file system. What should you do?

Options

  • ASet the spec.capacity.storage value of the PV object to match the size of the persistent disk.
  • BRecreate the application Pods by running the kubectl delete deployment DEPLOYMENT_NAME
  • CSet the spec.resources.requests.storage value of the PVC object to match the size of the
  • DIn the Pod, resize the disk partition to the maximum value by using the fdisk or parted utility.

How the community answered

(27 responses)
  • A
    4% (1)
  • B
    4% (1)
  • C
    81% (22)
  • D
    11% (3)

Explanation

In Kubernetes, resizing a PersistentVolume is driven by updating the PVC's spec.resources.requests.storage to the new desired size. The Kubernetes volume expansion controller detects this change, triggers the CSI driver to resize the underlying disk, and then resizes the filesystem inside the container (if allowVolumeExpansion: true is set on the StorageClass). Simply expanding the underlying Compute Engine disk does not signal Kubernetes to resize the PVC. Option A (manually editing PV capacity) is incorrect - PV capacity is updated automatically by the controller after the PVC request is changed; manually editing it does not trigger filesystem resize. Option B (deleting pods) may cause the pod to remount the volume at a new size but does not trigger the actual filesystem resize. Option D (using fdisk/parted inside the container) is a workaround that bypasses Kubernetes lifecycle management and is not durable.

Topics

#Kubernetes Storage#PersistentVolumeClaim (PVC)#Volume Expansion#GKE

Community Discussion

No community discussion yet for this question.

Full PROFESSIONAL-CLOUD-DEVELOPER Practice