Q: A Kubernetes pod is stuck in the Pending state due to a storage-related issue. What possible causes would you investigate, and how would you troubleshoot the issue?

Run `kubectl describe pod `. Check the Events section at the bottom. Common storage failure messages: - `0/3 nodes are available: 3 node(s) had volume node affinity conflict` - `pod has unbound immediate PersistentVolumeClaims` - `waiting for a volume to be created, either by dynamic provisioning or manual binding`

kubectl describe pod <pod-name> -n production
# Look for Events:
# Warning  FailedScheduling  pod has unbound immediate PersistentVolumeClaims

Check whether the PVC is `Bound`, `Pending`, or `Lost`. Describe the PVC to see why dynamic volume provisioning failed.

kubectl get pvc -n production
kubectl describe pvc <pvc-name> -n production
# Typical error:
# StorageClass "gp3" not found OR VolumeBindingFailed: waiting for first consumer to be created

Investigate the top 4 storage failure modes: 1. **StorageClass Misconfiguration**: StorageClass does not exist or the underlying cloud CSI driver (e.g. `ebs.csi.aws.com`) is crashed. 2. **Availability Zone Affinity Conflict**: EBS/Azure Disks are zonal resources. If an EBS volume exists in `us-east-1a`, but worker nodes with available CPU/RAM are in `us-east-1b`, the pod cannot schedule. 3. **AccessMode Mismatch**: Claim requests `ReadWriteMany` (RWX) on an EBS or Azure Disk volume that only supports `ReadWriteOnce` (RWO). 4. **Volume Limits Exceeded**: Worker node has reached maximum EBS volume attachments per EC2 instance (e.g. 28 volumes per nitro instance).

Verify that the cloud storage CSI controller and node daemonset pods are healthy in `kube-system`.

kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver