【问题标题】:timebound execution of initcontainerinitcontainer 的限时执行
【发布时间】:2020-05-07 02:58:46
【问题描述】:

我遇到的情况是,initcontainer 执行到完成必须有时间限制。有人可以告诉或推荐实现相同目标的策略吗?我到目前为止所尝试的:

  1. activeDeadlineSeconds - Pod 支持此属性,但 ReplicaSet 不支持。因此,不能在部署对象内部使用。

  2. 在计时器到期时从内部杀死 initcontainer。这没有按预期工作,请参阅link

  3. progressDeadlineSeconds - 这不考虑 initcontainers。

【问题讨论】:

  • 场景是什么?是否可以避免使用initContainer
  • @Nick 我们正在将旧产品迁移到 k8s。并非所有事物都符合 k8s,因此无法避免 init 容器。问题是由于集群中的一些随机问题,有时 init 容器进入挂起状态并且部署卡住,因为无法检查 init 容器是否无限期卡住。我们可以找到其他方法来实现相同的目标,但这会使我们的解决方案更加丑陋。目前,我已经修改了入口点脚本来解决这个问题。

标签: kubernetes


【解决方案1】:

Adding lifecycle hooks 提供的解决方案之一

Pod 还允许您定义 two lifecycle hooks:

1:启动后挂钩:K8 docs

记住: 直到钩子完成,容器将保持在等待状态,原因是 ContainerCreating。因此,Pod 的状态将是 Pending 而不是 Running。如果钩子运行失败或返回非零退出码,主容器将被杀死。

2: 预停止挂钩:K8 docs 和预停止挂钩在容器终止前立即执行。

注意:

1:这些生命周期钩子是针对每个容器指定的,这与适用于整个 pod 的 init 容器不同。

2:顾名思义,它们在容器启动和停止之前执行。

我希望这可以帮助您找到一种新方法!

【讨论】:

  • 我很可能会在 github 上写一张票,看看他们是否可以将此作为一项功能引入。在当前情况下,这种特殊方法对我没有帮助。我想控制 initContainer 本身。
猜你喜欢
  • 2020-10-13
  • 2019-08-11
  • 2012-05-04
  • 1970-01-01
  • 1970-01-01
  • 2011-04-18
  • 1970-01-01
  • 2011-11-26
相关资源
最近更新 更多