diff --git a/_data/tasks.yml b/_data/tasks.yml index b32c862449..121090ea79 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -46,6 +46,7 @@ toc: - docs/tasks/administer-cluster/dns-horizontal-autoscaling.md - docs/tasks/administer-cluster/safely-drain-node.md - docs/tasks/administer-cluster/change-pv-reclaim-policy.md + - docs/tasks/administer-cluster/limit-storage-consumption.md - title: Administering Federation section: diff --git a/docs/admin/resourcequota/limitstorageconsumption.md b/docs/admin/resourcequota/limitstorageconsumption.md index 1c88088d8f..d1f3116cb0 100644 --- a/docs/admin/resourcequota/limitstorageconsumption.md +++ b/docs/admin/resourcequota/limitstorageconsumption.md @@ -4,75 +4,8 @@ assignees: - janetkuo title: Limiting Storage Consumption --- -This example demonstrates an easy way to limit the amount of storage consumed in a namespace. -The following resources are used in the demonstration: +{% include user-guide-content-moved.md %} -* [Resource Quota](/docs/admin/resourcequota/) -* [Limit Range](/docs/admin/limitrange/) -* [Persistent Volume Claim](/docs/user-guide/persistent-volumes/) +[Limiting Storage Consumption](/docs/tasks/administer-cluster/limit-storage-consumption/) -This example assumes you have a functional Kubernetes setup. - -## Limiting Storage Consumption - -The cluster-admin is operating a cluster on behalf of a user population and the admin wants to control -how much storage a single namespace can consume in order to control cost. - -The admin would like to limit: - -1. The number of persistent volume claims in a namespace -2. The amount of storage each claim can request -3. The amount of cumulative storage the namespace can have - - -## LimitRange to limit requests for storage - -Adding a `LimitRange` to a namespace enforces storage request sizes to a minimum and maximum. Storage is requested -via `PersistentVolumeClaim`. The admission controller that enforces limit ranges will reject any PVC that is above or below -the values set by the admin. - -In this example, a PVC requesting 10Gi of storage would be rejected because it exceeds the 2Gi max. - -``` -apiVersion: v1 -kind: LimitRange -metadata: - name: storagelimits -spec: - limits: - - type: PersistentVolumeClaim - max: - storage: 2Gi - min: - storage: 1Gi -``` - -Minimum storage requests are used when the underlying storage provider requires certain minimums. For example, -AWS EBS volumes have a 1Gi minimum requirement. - -## StorageQuota to limit PVC count and cumulative storage capacity - -Admins can limit the number of PVCs in a namespace as well as the cumulative capacity of those PVCs. New PVCs that exceed -either maximum value will be rejected. - -In this example, a 6th PVC in the namespace would be rejected because it exceeds the maximum count of 5. Alternatively, -a 5Gi maximum quota when combined with the 2Gi max limit above, cannot have 3 PVCs where each has 2Gi. That would be 6Gi requested - for a namespace capped at 5Gi. - -``` -apiVersion: v1 -kind: ResourceQuota -metadata: - name: storagequota -spec: - hard: - persistentvolumeclaims: "5" - requests.storage: "5Gi" -``` - -## Summary - -A limit range can put a ceiling on how much storage is requested while a resource quota can effectively cap the storage -consumed by a namespace through claim counts and cumulative storage capacity. The allows a cluster-admin to plan their -cluster's storage budget without risk of any one project going over their allotment. diff --git a/docs/tasks/administer-cluster/limit-storage-consumption.md b/docs/tasks/administer-cluster/limit-storage-consumption.md new file mode 100644 index 0000000000..bde00eb2e7 --- /dev/null +++ b/docs/tasks/administer-cluster/limit-storage-consumption.md @@ -0,0 +1,76 @@ +--- +title: Limiting Storage Consumption +--- + +This example demonstrates an easy way to limit the amount of storage consumed in a namespace. + +The following resources are used in the demonstration: + +* [Resource Quota](/docs/admin/resourcequota/) +* [Limit Range](/docs/admin/limitrange/) +* [Persistent Volume Claim](/docs/user-guide/persistent-volumes/) + +This example assumes you have a functional Kubernetes setup. + +## Limiting Storage Consumption + +The cluster-admin is operating a cluster on behalf of a user population and the admin wants to control +how much storage a single namespace can consume in order to control cost. + +The admin would like to limit: + +1. The number of persistent volume claims in a namespace +2. The amount of storage each claim can request +3. The amount of cumulative storage the namespace can have + + +## LimitRange to limit requests for storage + +Adding a `LimitRange` to a namespace enforces storage request sizes to a minimum and maximum. Storage is requested +via `PersistentVolumeClaim`. The admission controller that enforces limit ranges will reject any PVC that is above or below +the values set by the admin. + +In this example, a PVC requesting 10Gi of storage would be rejected because it exceeds the 2Gi max. + +``` +apiVersion: v1 +kind: LimitRange +metadata: + name: storagelimits +spec: + limits: + - type: PersistentVolumeClaim + max: + storage: 2Gi + min: + storage: 1Gi +``` + +Minimum storage requests are used when the underlying storage provider requires certain minimums. For example, +AWS EBS volumes have a 1Gi minimum requirement. + +## StorageQuota to limit PVC count and cumulative storage capacity + +Admins can limit the number of PVCs in a namespace as well as the cumulative capacity of those PVCs. New PVCs that exceed +either maximum value will be rejected. + +In this example, a 6th PVC in the namespace would be rejected because it exceeds the maximum count of 5. Alternatively, +a 5Gi maximum quota when combined with the 2Gi max limit above, cannot have 3 PVCs where each has 2Gi. That would be 6Gi requested + for a namespace capped at 5Gi. + +``` +apiVersion: v1 +kind: ResourceQuota +metadata: + name: storagequota +spec: + hard: + persistentvolumeclaims: "5" + requests.storage: "5Gi" +``` + +## Summary + +A limit range can put a ceiling on how much storage is requested while a resource quota can effectively cap the storage +consumed by a namespace through claim counts and cumulative storage capacity. The allows a cluster-admin to plan their +cluster's storage budget without risk of any one project going over their allotment.