问Kubernetes:附加呼叫失败时的行为。我们应该永远重试附加，还是应该永远挂载？

EN

我有一个关于Kubernetes在pod重新调度后在新节点上附加卷的行为的问题。

我们集群中的一个常见行为是：

1. A节点n1变得不可用
2. 具有卷v1的pod A在节点上重新调度n2
3. 卷v1正从节点n1分离，这将花费节点上的一些时间n2尝试将卷v1连接到pod A
4. 由于卷v1尚未从节点n1分离，附加调用失败，并显示以下信息：

Sep 27 11:43:24 node n2 kubelet-wrapper787: E0927 11:43:24.794713 787 nestedpendingoperations.go:263]对“\”kubernetes.io/cinder/n2_v1_id\“”的操作失败。在2018-09-27 11:43:25.294659022 +0000utc m=+1120541.835247469 (durationBeforeRetry 500ms)之前不允许重试。错误:从节点\“节点n2\”对卷\“卷v1\”(UniqueName：\“kubernetes.io/cinder/AttachVolume.Attach_2_id\”)执行以下操作失败:磁盘volume_v2_id路径/dev/vdc已附加到另一个实例(pod节点n1)“

• 在发生此附加错误后，kubelet将永远尝试装载卷v1 (由于未附加卷，此操作将失败)

Sep 27 11:43:26 node n2 kubelet-wrapper787: E0927 11:43:26.870106 787 attacher.go:240]错误:找不到连接的灰盘"volume_v1_id“(路径："")：

我的问题是:为什么k8s在尝试挂载之前不尝试再次连接？

这里的问题是，当分离完成得足够快时，我们没有任何问题，但是如果分离还没有完成，当附加被kubelet调用时，我们就卡住了。

当深入研究代码时，它的行为似乎是WaitForAttachAndMount。这将: 1/ Try attach 2/无论Attach的结果如何，在Try Mount上循环。

Try Attach上的预期行为是否应为1/ loop 2/如果某个时候Attach成功，则在Try Mount上循环？

此问题与https://github.com/kubernetes/kubernetes/issues/69158相关