Kubernetes:附加调用失败时的行为。我们应该永远重试 Attach 还是永远 Mount？

Question

我对 Kubernetes 在处理重新安排 Pod 后在新节点上附加卷时的行为有疑问。

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

1. 节点 n1 变得不可用

2. Volume v1 的 pod A 在节点 n2 上重新调度

3. 正在从节点 n1 分离卷 v1，这将需要几秒钟

4. 节点 n2 上的 kubelet 尝试将卷 v1 附加到 pod A

5. 因为卷 v1 尚未从节点 n1 分离，附加调用失败并显示:

   Sep 27 11:43:24 node n2 kubelet-wrapper[787]: E0927 11:43:24.794713     787 nestedpendingoperations.go:263] Operation for "\"kubernetes.io/cinder/volume_v1_id\"" failed. No retries permitted until 2018-09-27 11:43:25.294659022 +0000 UTC m=+1120541.835247469 (durationBeforeRetry 500ms). Error: "AttachVolume.Attach failed for volume \"volume v1\" (UniqueName: \"kubernetes.io/cinder/volume_2_id\") from node \"node n2\" : disk volume_v2_id path /dev/vdc is attached to a different instance (pod node n1)"
   

6. 发生此 Attach 错误后，kubelet 将永远尝试挂载 Volume v1(由于未附加该 Volume 而失败)

   Sep 27 11:43:26 node n2 kubelet-wrapper[787]: E0927 11:43:26.870106     787 attacher.go:240] Error: could not find attached Cinder disk "volume_v1_id" (path: ""): <nil>
   

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

这里的问题是，当分离足够快地完成时，我们没有任何问题，但如果在 kubelet 调用 Attach 时分离尚未完成，我们就会卡住。

深入研究代码时，行为似乎是 WaitForAttachAndMount。这将:1/尝试附加 2/无论附加结果如何，循环尝试装载。

预期的行为是否应该是 1/循环尝试附加 2/如果在某个时刻附加成功，循环尝试装载？

这个问题与https://github.com/kubernetes/kubernetes/issues/69158有关

Answer 1

我的看法，这取决于:

1. 如果您想让卷提供程序(可能是 EBS、Cinder、GCP、Ceph 等)负责响应一个附上API。可能是提供商正在进行一些维护并且 API 暂时失败。如果您想让您的系统更加自动化，就可以这样做。

2. 如果您出于某种原因想让用户手动附加卷并使后续装载成功，则附加 -> 失败并无限期装载是有意义的。在我看来，这应该成为一个选项，而 1. 应该是默认设置。