3

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

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

  1. 节点 n1 变得不可用

  2. 具有卷 v1 的 pod A 在节点 n2 上重新调度

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

  4. 节点 n2 上的 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. 在这个 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/ 无论连接的结果如何，在 Try Mount 上循环。

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

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

4

1 回答 1

1

我的看法，这取决于：

  1. 如果您想让卷提供程序（可能是 EBS、Cinder、GCP、Ceph 等）负责响应附加 API，那么继续尝试无限期附加而不是失败并尝试无限期挂载是有意义的。可能是提供商正在进行一些维护，API 暂时出现故障。这是如果您想让您的系统更加自动化。

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

于 2018-10-23T22:49:04.447 回答