Sobes.tech
Interview Help
Resources
Interview Preparation
Resources
Job Search
Resources
Legal
Back to questions
Middle+

How is persistent volume distributed across different zones to ensure storage access for different domains and zones?

sobes.tech AI

Answer from AI

When using Kubernetes and public clouds (such as AWS, GCP, Azure), the distribution of persistent volumes (PV) across zones is managed at the cloud provider level and by binding PVs to nodes:

  1. Creating PV: A Persistent Volume (PersistentVolume) is created by an administrator or automatically via StorageClass. Storage parameters such as type (EBS, GCE Persistent Disk, Azure Disk), size, and access mode are specified during creation.
  2. Zone/Region Awareness: StorageClass for certain cloud storage types can be configured with support for availability zones. When creating a PV through such a StorageClass, the cloud provider can place the physical storage resource (e.g., disk) in a specific zone or make it zone-redundant (depending on storage type and settings). Using a StorageClass with the parameter volumeBindingMode: WaitForFirstConsumer allows delaying the binding of PV to PVR until the first pod using this PVR is scheduled on a node in a specific zone.
  3. PersistentVolumeClaim (PVC): The user creates a PersistentVolumeClaim with a request for a specific size and characteristics.
  4. Binding PV to PVC: Kubernetes binds the PVC to an appropriate PV. If WaitForFirstConsumer is used, the binding occurs when the first pod using this PVC is scheduled on a node.
  5. Pod Placement on Node: The Kubernetes scheduler determines on which node the pod will run. Various criteria are considered, including resource requirements, affinity/anti-affinity, Taints/Tolerations.
  6. Binding PV to Node: If the pod using the PVC (which is linked to the PV) is scheduled on a node in a specific zone, Kubernetes (more precisely, the Volume Controller and cloud provider) ensures that the PV will be available (mounted) to that node. Cloud disks are typically attached to virtual machines in the same zone. Kubernetes considers the zone of the PV during pod scheduling to avoid attempts to mount a PV from one zone to a node in another.

Example StorageClass with zone-aware mode:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: regional-storage
provisioner: kubernetes.io/aws-ebs # or gce-pd, microsoft.com/azure-disk etc.
parameters:
 type: gp2 # or ssd, pd-standard, etc.
 fsType: ext4
 volumeBindingMode: WaitForFirstConsumer # Important parameter for zone scheduling
reclaimPolicy: Retain
allowVolumeExpansion: true

When using volumeBindingMode: WaitForFirstConsumer, Kubernetes waits until the pod is scheduled on a node in a specific zone (e.g., us-east-1a) before binding the PersistentVolumeClaim to the PersistentVolume and creating the corresponding cloud disk in that zone.

Distribution across domains (in a broad sense, as a logical separation of applications or teams) is achieved not through the physical distribution of PVs but via mechanisms like RBAC (Role-Based Access Control), resource quotas, and namespace isolation:

  • Namespaces: Different domains/teams can use separate namespaces to isolate resources, including PVCs and pods.
  • RBAC: Defines which users or groups have permissions to create, read, update, or delete PVCs and other resources within specific namespaces.
  • Resource Quotas: Limit the total resources (including persistent storage volume) that can be used in each namespace, ensuring fair usage among "domains".
PreviousNext