Container Service for Kubernetes:Storage basics

PV example

apiVersion: v1
kind: PersistentVolume
metadata:
  namespace: default
  name: pv-example
spec:
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: diskplugin.csi.alibabacloud.com
    volumeHandle: <disk ID>
  volumeMode: Filesystem

PVC example

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  volumeName: pv-example

Binding rules

PVs and PVCs have a one-to-one relationship: a PV binds to exactly one PVC. Before a PVC can be used by a Pod, Kubernetes must find a PV that satisfies all of the following:

How the `storage` field works:

• Kubernetes uses storage to match and bind PVs to PVCs.

• In dynamic provisioning, the PVC's storage value determines the capacity of the provisioned PV and the underlying storage resource (such as a cloud disk).

• For storage types that support resizing, the PVC's storage value sets the target capacity after a scale-out.

• storage is a logical capacity limit. Actual write throughput depends on the underlying storage medium, not on the storage field.

Volume access modes

Use the accessModes field to define how a volume can be mounted:

Static provisioning

In static provisioning, the cluster administrator creates PVs in advance. You can statically provision cloud disks, NAS file systems, and OSS buckets.

1. The administrator analyzes Pod storage requirements and pre-allocates storage resources (for example, cloud disks or NAS file systems).

2. The administrator creates PVs that describe those resources, including their capacity and configuration.

3. Developers create PVCs that declare what their workloads need.

4. When a Pod is created, Kubernetes binds the PVC to a matching PV, giving the Pod access to the storage.

Dynamic provisioning

In dynamic provisioning, a CSI provisioner creates PVs automatically when a PVC is submitted. You can dynamically provision cloud disks, NAS file systems, and OSS buckets.

1. The administrator creates a StorageClass that defines the storage type and provisioner. For example, diskplugin.csi.alibabacloud.com provisions cloud disks.

2. Developers create PVCs that reference a StorageClass. No manual PV creation is needed.

3. When a Pod is created, the CSI provisioner reads the StorageClass, creates a PV and the underlying storage resource, and binds the PV to the PVC.

Dynamic provisioning has three advantages over static provisioning:

• Automated lifecycle management: the provisioner handles PV creation and deletion automatically.

• Reduced operational burden: administrators manage StorageClasses rather than individual PVs.

• Capacity consistency: the PV and the underlying storage resource are always provisioned to match the PVC's requested capacity.

StorageClass example

The following StorageClass provisions Alibaba Cloud disks:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-disk-topology-alltype
provisioner: diskplugin.csi.alibabacloud.com
parameters:
  type: cloud_auto,cloud_essd,cloud_ssd,cloud_efficiency
  fstype: ext4
  diskTags/a: b
  encrypted: "false"
  performanceLevel: PL1
  provisionedIops: "40000"
  burstingEnabled: "false"
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Key parameters

Choosing a `volumeBindingMode`:

Use WaitForFirstConsumer in multi-zone clusters. Cloud disks cannot be mounted across zones. If a PV is provisioned in Zone A but a Pod is scheduled to Zone B, the Pod will fail to start. With WaitForFirstConsumer, the provisioner waits until the Pod is scheduled, then creates the disk in the zone where the Pod runs.

How `WaitForFirstConsumer` works:

When a PVC is created, the provisioner does not immediately create a PV. It waits until a Pod consumes the PVC. After the scheduler places the Pod on a node, it writes the scheduling result (region and node) to the PVC's metadata. The provisioner reads this information and creates the PV—and the underlying disk—in the correct zone.

Default StorageClass

Kubernetes supports a default StorageClass that automatically provisions a PV for any PVC that does not specify a StorageClass name.

Set a default StorageClass:

Run the following command to mark alicloud-disk-topology-alltype as the default:

kubectl annotate storageclass alicloud-disk-topology-alltype storageclass.kubernetes.io/is-default-class=true

Verify the change:

kubectl get sc

Expected output:

NAME                                        PROVISIONER                       AGE
alicloud-disk-topology-alltype (default)    diskplugin.csi.alibabacloud.com   96m

Create a PVC without specifying a StorageClass:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: disk-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

The cluster automatically creates a cloud disk PV using alicloud-disk-topology-alltype.

kubectl get pvc

Expected output:

NAME       STATUS   VOLUME                   CAPACITY   ACCESS MODES    STORAGECLASS                      AGE
disk-pvc   Bound    d-bp18pbai447qverm****   20Gi       RWO             alicloud-disk-topology-alltype    49s

Remove the default StorageClass:

kubectl annotate storageclass alicloud-disk-topology-alltype storageclass.kubernetes.io/is-default-class-

StorageClasses provided by ACK

The alicloud-disk-topology-alltype StorageClass selects the best available disk type at provisioning time:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-disk-topology-alltype
parameters:
  type: cloud_essd,cloud_ssd,cloud_efficiency
provisioner: diskplugin.csi.alibabacloud.com
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer