Documentation Kubernetes Blog Training Partners Community Case Studies Versions English

Kubernetes Documentation / Concepts / Storage / Storage Capacity

 Search
Storage Capacity
Home
Storage capacity is limited and may vary depending on the node on which a pod runs: network-
Getting started attached storage might not be accessible by all nodes, or storage is local to a node to begin with.
Concepts
FEATURE STATE: Kubernetes v1.19 [alpha]
Overview
FEATURE STATE: Kubernetes v1.21 [beta]
Cluster
Architecture This page describes how Kubernetes keeps track of storage capacity and how the scheduler uses
Containers that information to schedule Pods onto nodes that have access to enough storage capacity for
Workloads the remaining missing volumes. Without storage capacity tracking, the scheduler may choose a
node that doesn't have enough capacity to provision a volume and multiple scheduling retries
Services, Load
will be needed.
Balancing, and
Networking Tracking storage capacity is supported for Container Storage Interface (CSI) drivers and needs to
Storage be enabled when installing a CSI driver.

Volumes
Persistent Volumes
Volume Snapshots API
CSI Volume Cloning There are two API extensions for this feature:

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Storage Classes CSIStorageCapacity objects: these get produced by a CSI driver in the namespace where
Volume Snapshot the driver is installed. Each object contains capacity information for one storage class and
de nes which nodes have access to that storage.
TheKubernetes
Documentation Blog Training Partners eld:
CSIDriverSpec.StorageCapacity when setCase
Community to true , the Versions
Studies Kubernetes scheduler
English
will consider storage capacity for volumes that use the CSI driver.

Scheduling
Storage capacity information is used by the Kubernetes scheduler if:

the CSIStorageCapacity feature gate is true,

a Pod uses a volume that has not been created yet,
that volume uses a StorageClass which references a CSI driver and uses
WaitForFirstConsumer volume binding mode, and

the CSIDriver object for the driver has StorageCapacity set to true.

In that case, the scheduler only considers nodes for the Pod which have enough storage
available to them. This check is very simplistic and only compares the size of the volume against
the capacity listed in CSIStorageCapacity objects with a topology that includes the node.

For volumes with Immediate volume binding mode, the storage driver decides where to create
the volume, independently of Pods that will use the volume. The scheduler then schedules Pods
onto nodes where the volume is available after the volume has been created.

For CSI ephemeral volumes, scheduling always happens without considering storage capacity.
This is based on the assumption that this volume type is only used by special CSI drivers which
are local to a node and do not need signi cant resources there.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Rescheduling
Documentation Kubernetes Blog Training Partners Community Case Studies Versions English
When a node has been selected for a Pod with WaitForFirstConsumer volumes, that decision is
still tentative. The next step is that the CSI storage driver gets asked to create the volume with a
hint that the volume is supposed to be available on the selected node.

Because Kubernetes might have chosen a node based on out-dated capacity information, it is
possible that the volume cannot really be created. The node selection is then reset and the
Kubernetes scheduler tries again to nd a node for the Pod.

Limitations
Storage capacity tracking increases the chance that scheduling works on the rst try, but cannot
guarantee this because the scheduler has to decide based on potentially out-dated information.
Usually, the same retry mechanism as for scheduling without any storage capacity information
handles scheduling failures.

One situation where scheduling can fail permanently is when a Pod uses multiple volumes: one
volume might have been created already in a topology segment which then does not have
enough capacity left for another volume. Manual intervention is necessary to recover from this,
for example by increasing capacity or deleting the volume that was already created. Further
work is needed to handle this automatically.

Enabling storage capacity tracking

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Storage capacity tracking is a beta feature and enabled by default in a Kubernetes cluster since
Kubernetes 1.21. In addition to having the feature enabled in the cluster, a CSI driver also has to
support it. Please refer to the driver's documentation for details.
Documentation Kubernetes Blog Training Partners Community Case Studies Versions English

What's next
For more information on the design, see the Storage Capacity Constraints for Pod
Scheduling KEP.
For more information on further development of this feature, see the enhancement
tracking issue #1472.
Learn about Kubernetes Scheduler

Feedback
Was this page helpful?

Yes No

Last modi ed March 02, 2021 at 1:47 PM PST: storage capacity: beta (f5aaf40e8)

Home Blog Training Partners Community Case Studies

   © 2021 The Kubernetes Authors | Documentation Distributed under CC BY 4.0   

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
      
Copyright © 2021 The Linux Foundation ®. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks.
 For a list of trademarks of The Linux Foundation, please see our Trademark Usage page

ICP license: 京ICP备17074266号-3
Documentation Kubernetes Blog Training Partners Community Case Studies Versions English

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD