kubectl patch pv manually update the capacity information of a PV

Customers have a service PV need to expand capacity, because the service has just been initialized has not been formally online, and the storage volume is used in the cloud disk, support for dynamic resizing, the assessment decided to use kubectl patch pv manually update the capacity of the pv information, of course, the premise needs to be expanded to the specified capacity of the cloud disk first.This method in production is very dangerous, please assess the risk!

Operational Steps:

1. Find the storage volume used by the pod and log in to the cloud vendor console to find the corresponding storage volume to expand to the specified capacity.

kubectl get pvc -A | grep pod-name
 
kubectl get pv -A | grep pod-name
 
kubectl describe pv <pv-name>

2. Usekubectl patch pvManually update capacity information for pv

Although it is possible to usekubectl patchcommand modifies the capacity information in the PV object, but theDoesn’t really change the size of the underlying storage resource. This only leads to inconsistencies between the PV capacity information in the Kubernetes cluster and the size of the actual underlying storage resources, which can lead to various problems such as data loss or applications not working properly.Use the following command only if you have already resized the underlying storage resource by other means and need to update the capacity information of the PV:

kubectl patch pv <pv-name> -p '{"spec":{"capacity":{"storage":"<new-size>"}}}'

<pv-name>replacing it with the name of your PV.<new-size>Replace with new capacity size (e.g., 500)Gi)。

After confirming that the capacity change is complete, enter pod and use the dd command in the mount directory to test whether the file can be created normally, the command is as follows, and remember to delete the test file after the test is complete.

dd if=/dev/zero of=./file-test bs=4M count=10

The following are some indirect methods of adjusting PV capacity, as well as their risks and limitations, so please choose to use them carefully.May result in data loss or application not working properly

  1. Modify the size of the underlying storage resource directly: the

  • Applicable Scenario.hostPath, NFS, local storage, and other types of PVs.

  • Methods.Log in to the host or storage server and use the appropriate tool (for example, theresize2fsThe PVs are then manually updated to match the size of the underlying storage resources. Then, you need to manually update the capacity information of the PV to match the size of the underlying storage resource.

  • 风险:Very high. Direct manipulation of the underlying storage resources can result in data loss or corruption. If not done correctly, this could cause a Kubernetes cluster to fail.

  • Limitations.Not all storage types support online resizing.

Using the tools provided by the storage vendor.

  • Applicable Scenario.Storage services provided by cloud vendors (e.g. AWS EBS, Azure Disk, GCP Persistent Disk).

  • Methods.Use the tools provided by the cloud vendor (e.g. AWS CLI, Azure PowerShell, GCP gcloud) to resize the storage volume. Then, you need to manually update the capacity information of the PVs to match the new volume size.

  • 风险:Medium. Using tools provided by cloud vendors is generally safer than directly manipulating the underlying storage resources, but there is still some risk.

  • Limitations.Not all cloud vendors support online resizing of storage volumes.

To use the Volume Expansion feature (if supported).

  • Applicable Scenario.Some CSI drivers and storage plug-ins support the Volume Expansion feature.

  • Methods.Editing of PVCspec.resources.requests.storagefield, modify its value to the new capacity size. If the storage driver and file system support online expansion, the capacity of the PV is automatically adjusted.

  • 风险:Low. This is the safest method, but requires the storage driver and file system to support the Volume Expansion feature.

  • Limitations.Not all storage drivers and file systems support the Volume Expansion feature.

While it is technically possible to usekubectl patchcommand modifies some fields of the PV, such as labels or annotations, but this usually does not change the underlying storage resources of the PV, such as theCapacity, access mode, and recycling policy, which are typically immutable after the PV is created

Fields that can be modified.

  • Labels (标签):It is possible to usekubectl patchAdds, modifies, or deletes tags for PVs.

kubectl patch pv <pv-name> -p '{"metadata":{"labels":{"key":"value"}}}'
  • Annotations (注解):It is possible to usekubectl patchAdds, modifies, or deletes notes for a PV.

kubectl patch pv <pv-name> -p '{"metadata":{"annotations":{"key":"value"}}}'

Fields that cannot be modified (usually).

  • Capacity (容量):The capacity of a PV cannot be changed after it is created.

  • Access Modes.The access mode of a PV cannot be changed after it is created.

  • Reclaim Policy (回收策略):The reclamation policy for a PV typically cannot be changed after it is created, but some cloud vendors’ storage plug-ins may allow modifications.

kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'
  • Storage Class (存储类):The storage class of a PV cannot be changed after it is created.

  • Underlying Storage Resources. kubectl patchThe underlying storage resource corresponding to the PV is not modified.

If you must use these methods, be sure to back up your data and test them in a non-production environment before operating.


Again, all of the above methods carry some risk and are not recommended for use in a production environment.The safest and recommended method is to create new PVs and PVCs and migrate applications to the new PVCs as follows:

  1. Create new PV.Create a new PV based on the new capacity requirement.

  2. Creating a new PVC.Create a new PVC and bind it to the new PV.

  3. Migrate the application to the new PVC.Configure the application to use the new PVC.

Here are the steps on how to resize PVC capacity:

  1. Confirm StorageClass support for expansion.

    utilizationkubectl describe sc <storageclass-name>command to view the details of the StorageClass.recognizeallowVolumeExpansionThe field is set totrueIf the StorageClass does not support expansion, you need to create a new StorageClass that does. If the StorageClass does not support expansion, you need to create a new StorageClass that supports expansion.

  2. utilizationkubectl patchkubectl editAdjustment of PVC capacity.

    The capacity of the PVC can be modified using one of the following two methods:

  • kubectl patch:

kubectl patch pvc <pvc-name> -p '{"spec":{"resources":{"requests":{"storage":"<new-size>"}}}}'

Replace <pvc-name> with the name of your PVC and <new-size> with the new capacity size (e.g. 20Gi, 500Mi).

  • kubectl edit:

kubectl edit pvc <pvc-name>

Find the spec.resources.requests.storage field and change its value to the new capacity size. Save and close the file.

Verify that the PVC capacity has been changed.

utilizationkubectl get pvc <pvc-name>kubectl describe pvc <pvc-name>command to view the details of the PVC and confirm whether the capacity has been updated.

(if necessary) Restart Pod.

Some storage drivers and file systems require a restart of the Pod to recognize the new capacity size. If the application does not automatically recognize the new capacity, restart the Pod using that PVC.

Caution.

  • Not all storage drivers support online expansion.

  • Reducing PVC capacity is usually not supported and may result in data loss.

  • Ensure that the application can handle changes in storage capacity.

If you are using a Kubernetes service provided by a cloud vendor, refer to its documentation for information on how to resize PV capacity, as the exact steps may vary. Some cloud vendors’ storage plug-ins may provide a safer way to resize PV capacity.

Reference :List of Kubernetes Command Memos