Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add documentation on storageClass.reclaimPolicy #5171

Merged
merged 2 commits into from
Sep 7, 2017
Merged

Add documentation on storageClass.reclaimPolicy #5171

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3d44fe0
Add documentation on storageClass.reclaimPolicy
wongma7 Aug 23, 2017
ff77db8
Merge branch 'release-1.8' into reclaimpolicy
chenopis Sep 1, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 9 additions & 7 deletions docs/concepts/storage/persistent-volumes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -107,7 +107,7 @@ However, the particular path specified in the custom recycler pod template in th

#### Deleting

For volume plugins that support the Delete reclaim policy, deletion removes both the `PersistentVolume` object from Kubernetes, as well as deleting the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned are always deleted. If that is not desired, currently, the only option is to edit or patch the PV after it is created. See [Change the Reclaim Policy of a PersistentVolume](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
For volume plugins that support the Delete reclaim policy, deletion removes both the `PersistentVolume` object from Kubernetes, as well as deleting the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their `StorageClass`](#reclaim-policy-1), which defaults to Delete. The administrator should configure the `StorageClass` according to users' expectations, otherwise the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/).

## Types of Persistent Volumes

Expand Down Expand Up @@ -378,9 +378,9 @@ spec:

## StorageClasses

Each `StorageClass` contains the fields `provisioner` and `parameters`, which
are used when a `PersistentVolume` belonging to the class needs to be
dynamically provisioned.
Each `StorageClass` contains the fields `provisioner`, `parameters`, and
`reclaimPolicy`, which are used when a `PersistentVolume` belonging to the
class needs to be dynamically provisioned.

The name of a `StorageClass` object is significant, and is how users can
request a particular class. Administrators set the name and other parameters
Expand All @@ -400,6 +400,7 @@ metadata:
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
reclaimPolicy: Retain
mountOptions:
- debug
```
Expand Down Expand Up @@ -445,9 +446,10 @@ There are also cases when 3rd party storage vendors provide their own external
provisioner.

### Reclaim Policy
Persistent Volumes that are dynamically created by a storage class will have a reclaim
policy of `delete`. If that is not desired, the only current option is to edit the
PV after it is created.
Persistent Volumes that are dynamically created by a storage class will have the
reclaim policy specified in the `reclaimPolicy` field of the class, which can be
either `Delete` or `Retain`. If no `reclaimPolicy` is specified when a
`StorageClass` object is created, it will default to `Delete`.

Persistent Volumes that are created manually and managed via a storage class will have
whatever reclaim policy they were assigned at creation.
Expand Down