kubernetes: Surface better error when user directly specifies impossible mount in pod spec
and keeps it to itself. Witness:
W0509 20:06:57.396026 994 aws_util.go:177] Retrying attach for EBS Disk "vol-XXXXXXXX" (retry count=5).
E0509 20:06:57.512043 994 aws_util.go:182] Error attaching PD "vol-XXXXXXX": Error attaching EBS volume: InvalidVolume.ZoneMismatch: The volume 'vol-XXXXXXX' is not in the same availability zone as instance 'i-ZZZZZZZZ'
This is user error, but
- there’s no point in retrying, since the EBS is not going to jump zones
- worst of all, it doesn’t show anything in events (it gets reported as “Container creating”). You need to ssh to the node and look at kubelet logs
About this issue
- Original URL
- State: open
- Created 8 years ago
- Comments: 15 (10 by maintainers)
@noose let’s keep marketing statements out of the issue tracker 😉 You can use EBS volumes with persistent volumes in multiple AZs today, and they will be scheduled correctly. With PetSets in 1.3, PetSets automatically create EBS volumes around the available zones and everything is scheduled correctly.
This issue is about better surfacing the error for a particular case: when specifying an EBS volume directly in the pod spec. The zone-aware scheduler doesn’t handle that case; we want to encourage persistent volumes instead.
For multi-AZ clusters, we recommend using persistent volumes & persistent volume claims: http://kubernetes.io/docs/admin/multiple-zones/