首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >Kubernetes:附加呼叫失败时的行为。我们应该永远重试附加,还是应该永远挂载?

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

Stack Overflow用户
提问于 2018-10-23 22:23:07
回答 1查看 176关注 0票数 3

我有一个关于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相关

EN

回答 1

Stack Overflow用户

发布于 2018-10-24 06:49:04

我的看法,这取决于:

  1. 如果您想让卷提供者(可能是EBS、Cinder、GCP、Ceph等)负责响应Attach
  2. ,那么继续尝试无限期连接而不是失败并尝试无限期挂载是有意义的。可能是提供程序正在进行一些维护,而API暂时出现了故障。这是如果你想让你的系统更加自动化。
  3. 如果出于某种原因,你想让用户手动连接卷,并让后续的安装成功,那么连接->失败并无限期地挂载是有意义的。在我看来,这应该是一个选项,1.应该是默认值。
票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/52951446

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档