Kubernetes：“附加”呼叫失败时的行为。我们应该永久重试Attach，还是永久安装？

Question

我有一个关于Kubernetes在重新安排Pod后处理将卷附加到新节点上时的行为的问题。

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

1. 节点n1不可用

2. 具有卷v1的Pod A在节点n2上重新安排了

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

节点n2上的

4. kubelet尝试将卷v1附加到Pod A

5. 由于卷v1尚未从节点n1分离，因此Attach调用失败并显示：

   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. 出现此附加错误后，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 /不管附加结果如何，在Try Mount上循环。

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

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

有关

Answer 1

我认为，这取决于：

1. 如果要使卷提供程序（可以是EBS，Cinder，GCP，Ceph等）负责响应，则继续尝试无限期附加而不是失败并尝试无限期挂载是有意义的。附加API。提供程序可能正在做一些维护，而API暂时失败。这是为了使您的系统更加自动化。

2. 如果出于某种原因要让用户手动附加该卷并使后续的安装成功，则挂接->无限期挂载是有意义的。我认为应该将其设为一个选项，并且1.应该是默认选项。