From 33aae9b7e5b0c2e9ff8ab867c0e40d16663584aa Mon Sep 17 00:00:00 2001 From: Matt Cary <34742400+mattcary@users.noreply.github.com> Date: Mon, 13 Dec 2021 15:35:11 -0800 Subject: [PATCH] Update content/en/docs/concepts/storage/persistent-volumes.md Co-authored-by: Tim Bannister --- content/en/docs/concepts/storage/persistent-volumes.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 241f05b5cc..41dab6b043 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -255,9 +255,12 @@ size. This triggers expansion of the volume that backs the underlying Persistent new PersistentVolume is never created to satisfy the claim. Instead, an existing volume is resized. {{< warning >}} -Editing the size of a PersistentVolume can prevent resize of the volume. If the -capacity of a PersistentVolume edited, then the PersistentVolumeClaim size is edited to increase to -the same value, no resize will happen. Kubernetes will think the backing volume has been manually +Directly editing the size of a PersistentVolume can prevent an automatic resize of that volume. +If you edit the capacity of a PersistentVolume, and then edit the `.spec` of a matching +PersistentVolumeClaim to make the size of the PersistentVolumeClaim match the PersistentVolume, +then no storage resize happens. +The Kubernetes control plane will see that the desired state of both resources matches, +conclude that the backing volume size has been manually increased and that no resize is necessary. {{< /warning >}}