Enhancements: CronJobs(以前的 ScheduledJobs)

创建于 2016-07-04  ·  115评论  ·  资料来源: kubernetes/enhancements

增强说明

  • 单行功能说明(可用作发行说明):
    CronJobs(以前称为 ScheduledJobs)用于执行所有与时间相关的操作,即备份、报告生成等。 应该允许这些任务中的每一个重复运行(每天/每月一次等)或在给定的时间点运行一次。
  • Kubernetes 增强提案: https :
  • 讨论链接: sig-apps议程
  • 主要联系人(受让人):@soltysh
  • 负责的 SIG:sig-apps
  • 增强目标(哪个目标等于哪个里程碑):

    • [x] Alpha 发布目标 1.4(作为 ScheduledJobs)

    • [x] Beta 发布目标 1.8(作为 CronJobs)

    • [ ] 稳定发布目标 1.21/1.22

kinfeature siapps stagbeta trackeyes

最有用的评论

所有 SJ 工作都在全速进行,唯一剩下的问题(希望如此)是让https://github.com/kubernetes/kubernetes/pull/29187进入。我希望今天或通过以下方式与@smarterclayton讨论这个问题周末并合并,所以下周我们应该会看到一个接一个合并的其他 SJ PR。

所有115条评论

@erictune仅供参考

@soltysh我可以在什么 SIG 上讨论此功能? 我想就这个功能的第三方资源进行更长时间的讨论,以及为什么我们认为需要将它内置到核心中。

现在让我们使用 SIG-Apps。 那里没有很多关于控制器的讨论,我已经看到了,但让我们尝试看看它是如何进行的。

是否考虑将其排除在核心之外? 我还以为这个提议已经被接受了。

@gtaylor还没有决定。 目前它将批量加入 alpha 组,当它迁移到更稳定时会发生什么尚不清楚。

我的理解是这被核心接受,而核心工作流程被拒绝。 事实上,我们最初计划在 1.3 中使用它。

@davidopp我的评论基于我们之前与@philips @erictune here的讨论。 虽然,我个人更喜欢 SJ 留在核心:太阳镜:

@soltysh我将评论解释为暗示它将在核心中(基于提到 alpha/beta 和声明“如果有人要在 1.4 之前生成第三方版本的 scheduleJob,并表明它是比较有用的,这将是后一种路径的有说服力的论据”,其中后一种路径是第三方)。

@davidopp当我认为 SJ 将在 1.4 中成为 Beta 时发表了该评论。 现在它将在 1.4 中进入 Alpha。 我们的理念是,无论出于何种原因,我们都可以取消 Alpha 版功能,但我们应该为取消 Beta 版功能设定一个相当高的标准。

另外,对于所有在 SJ 工作的人:尽管有上述谈话,我们应该继续全速工作。 大部分工作都适用于任何一种方式,我们需要向用户提供某种功能,以便他们可以提供反馈。

所有 SJ 工作都在全速进行,唯一剩下的问题(希望如此)是让https://github.com/kubernetes/kubernetes/pull/29187进入。我希望今天或通过以下方式与@smarterclayton讨论这个问题周末并合并,所以下周我们应该会看到一个接一个合并的其他 SJ PR。

@soltysh :看起来#29187 被合并了,这是否意味着下一个 1.4 alpha 版本会让 SJ 准备好玩?

@eghobo这就是计划。

这需要 k8s.io 中的文档,但看起来代码已在。太棒了!

+100

@soltysh文档

@janetkuo我通常在它们合并后将它们标记为完成。 考虑到这一点,我已经针对分支 1.4 检查了一个,另一个将等待合并。

由于它已重命名为 CronJobs,因此我将更新标题以反映该更改。

这会是 1.5 的测试版吗?

@ConorNevin不幸的是没有,请参阅问题描述中的测试版要求,我们需要首先解决哪些问题才能将其升级为测试版。 抱歉 :disappointed: 非常鼓励帮助修复这些问题 :smiley:

仍然有https://github.com/wercker/cronetes ,如果现在需要类似 cronjob 的功能而无法运行 alpha 功能。

在 CronJobs 中实现最多运行一次功能吗?
我看到它没有包含在 alpha 中 - https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/scheduledjob.md#decision

@vinay-g 最终,我想是的,但我不知道什么时候会。 虽然总是欢迎帮助:)

此功能仍然附加到里程碑 1.4,并且 1.6 里程碑电子表格没有提及任何有关 Cron/ScheduledJobs 的内容。

这是否仍按计划发布 1.6 测试版? 作为 GKE 客户,我会_喜欢_开始将我们所有的集群外 cron 移动到集群本身(不使用 cronetes)。

的确。 如果我没记错的话,这个非常需要的功能已经从 1.3 版本开始拖延了。 我自己处于相同的位置 - 不能等到它出现,这样我就可以开始将内部部署的工作拉到 GKE 上。

我已经将里程碑修改为下一个,CronJobs 还有很多工作要做来稳定它们,我很想更积极地推进它,但不幸的是,缺乏时间是我做不到的主要因素'自动取款机

在ChronJob模板支持imagePullSecrets?

@soltysh感谢您的更新。

ChronJob 模板中是否支持 imagePullSecrets?

@avaranovich应该是,因为我们正在从模板创建一个 Pod。 如果不是,请填写一个问题并在那里标记我。

@soltysh 。 我很想尽快看到这个测试版! 我想提供帮助,但不确定这里需要什么/下一步。 您能否稍微细化一下清单(也许创建/指向相关问题/文档)? 🙂

@ApsOps在 beta 之前我们肯定需要实现服务器端删除,支持谷歌应用引擎和 chronos 格式,并允许使用时区。 扫除我身上与 CronJobs 相关的错误可能会很好。 我怀疑它对于 1.6 是否可行,但对于下一个版本它是可行的。 最重要的是,在您针对此主题创建的每个问题/公关中标记我。

@soltysh

我认为有很多人像现在一样使用 CronJobs,而且我大多听到“什么时候会是 beta”,而 alpha 并没有那么多问题。

如果我们相信我们可以在不破坏当前 API 的情况下添加服务器端删除、app-engine 和 chronos 以及时区,那么我认为没有任何理由现在不移动测试版,并在 GA 之前添加这些东西。

+1 对于 CronJobs 测试版。 一旦它们处于测试阶段并且不需要重置集群,这将是我们这里的许多工作流程的一个终止功能。

我们期待此功能进入 Beta 版,并且我们在 alpha 版方面没有遇到任何问题。

就我个人而言,我更喜欢至少解决删除部分,有人已经在为留下多少成功和失败的作业添加可配置的限制。 我认为,移除是一个关键因素。 让我们讨论在即将到来的 sig-apps 电话会议期间将其移至 1.6 或 1.7 测试版的选项。 @michelleN介意将此作为主题添加吗?

@NiclasHedam您的问题是否已得到解决,是否有我没有看到的未解决问题,介意在这些问题中打开/ping 我吗?

它们都已在 1.4.7 中解决

是否有计划添加 GUI 支持? 例如,我目前可以看到以下内容:

[obatori<strong i="6">@obatori</strong>:~] >> kubectl get cronjobs
NAME         SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
cron-hello   */1 * * * *   False     0         Tue, 25 Jul 2017 09:11:00 -0400
hello        0 22 * * *    False     0         <none>

但是,在 GUI 中,我只能看到历史执行情况,而不能看到当前作业和与之相关的计划? 此外, kubectl get并未将cronjob / cronjobs列为有效的资源类型,尽管它们确实有效。

当然,我可能会遗漏一些东西,但是对 GUI 的各个部分进行详尽的搜索还没有向我展示我的工作!

@oscarbatori请在 kubernetes/dashboard 存储库中打开一个问题并要求增强。

@luxas会做,感谢您的及时回复。

@soltysh您能否在此处为 1.8 版本添加此功能的 k8s.io Docs PR: https ://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid =0

@soltysh此功能在功能跟踪电子表格中列出 - https://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid =0,但没有分配 1.8 里程碑。

此功能是否针对 1.8?

@idvoretskyi部分地,升级到 Beta 的目标是 1.8,并且发生在那个时间范围内。 没有为此设定里程碑,b / c 没有明确的计划将未来提升到稳定。

@soltysh明白了。 所以,我会用 1.8 里程碑来标记。

谢谢!

@idvoretskyi因为有一个功能(能够手动启动 CronJobs ),我们将尝试进入与 CronJobs 相关的 1.9 版本,我将在这里添加 1.9 milstone,可以吗? 我不想创建另一个问题只是为了跟踪该单个项目。

我可能会尝试更新初始描述,以便它反映为 CronJob 相关功能引入(也计划)的更改。

@soltysh功能描述更新有什么进展吗? :)

请使用新模板 - https://github.com/kubernetes/features/blob/master/ISSUE_TEMPLATE.md

@soltysh :wave: 请在1.9 功能跟踪板中注明
此功能是否需要文档。 如果是,请打开 PR并添加指向跟踪电子表格的链接。 提前致谢!

@idvoretskyi因为有一个功能(能够手动启动 CronJobs )我们将尝试进入与 CronJobs 相关的 1.9 版本,我将在这里添加 1.9 milstone

此特定功能不会出现在 1.9 中。 我们应该将里程碑移至 1.10 吗?

对于 1.10 里程碑,有 3 个主题:

  1. CronJob 中的 TimeZone 支持 (https://github.com/kubernetes/kubernetes/pull/47266) - @iterion请参阅此评论以了解原因
  2. CronJob 手动实例化 (https://github.com/kubernetes/kubernetes/pull/53988) - @erhudy
  3. (?) 重新编写控制器以使用共享线人 (https://github.com/kubernetes/kubernetes/issues/17130) - @soltysh

@soltysh仍然是测试版,对吧?

稳定要求:

  1. 控制器中的共享线人 (https://github.com/kubernetes/kubernetes/issues/17130)
  2. 支持不同的时间格式( ISO 8601GCE 时间格式)。

@soltysh功能跟踪电子表格表明需要更新文档。 真的是这样吗? 如果是这样,请尽快获得您的 PR(今天是文档截止日期,但我不太擅长通知人们)。 如果没有,您能否更新电子表格? 谢谢!

@soltysh docs ping -- 合并文档 PR 的截止日期是本周五,3 月 9 日。请参阅之前的评论。 谢谢! /cc @idvoretskyi

@Bradamant3抱歉延迟,此功能不需要文档更新。 我在链接的电子表格中添加了评论。

@soltysh
在 1.11 中有任何计划吗?

如果是这样,请确保该功能是最新的,并具有以下适当的功能:

  • 描述
  • 里程碑
  • 受让人
  • 标签:

    • stage/{alpha,beta,stable}

    • sig/*

    • kind/feature

抄送@idvoretskyi

在 1.11 中有任何计划吗?

控制器重写以满足https://github.com/kubernetes/kubernetes/issues/17130但我仍在努力争取时间。 所以这更像是一厢情愿而不是实际计划:wink:

好酷。 我将推动这一里程碑。

有关使此稳定的计划的任何更新? 我假设基于缺乏里程碑这不会发生在 1.12?

有关使此稳定的计划的任何更新? 我假设基于缺乏里程碑这不会发生在 1.12?

@soltysh ^^

@spiffxp——我之前和@soltysh 谈过。 1.12 没有任何计划。

你好
之前已经跟踪过此增强功能,因此我们想检查一下,看看是否有任何计划以在 Kubernetes 1.13 中进行毕业阶段。 此版本的目标是更加“稳定”,并将有一个积极的时间表。 请仅在高度确信它将满足以下截止日期的情况下包含此增强功能:

  • 文档(开放占位符 PR):11/8
  • 代码泥浆:11/9
  • 代码冻结开始:11/15
  • 文档完成和审核:11/27

如果需要将其包含在1.13 增强跟踪表中,请花点时间更新您原始帖子中的里程碑以供将来跟踪和 ping @kacole2

谢谢!

@kacole2在我们解决 cronjob 控制器的最大问题之前,它不会移动到任何地方,这是共享线人。 我们将在下一次 SIG-Apps 电话会议上讨论这个话题。

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
陈旧的问题在额外 30 天不活动后腐烂并最终关闭。

如果现在可以安全关闭此问题,请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

陈旧的问题在 30 天不活动后腐烂。
使用/remove-lifecycle rotten将问题标记为新问题。
额外的 30 天不活动后,烂问题就会关闭。

如果现在可以安全关闭此问题,请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期腐烂

20190212T2157Z等工作的前缀怎么样?

/remove-lifecycle 腐烂的

/生命周期冻结

kubernetes/enhancements打开的增强问题不应被标记为冻结。
增强所有者可以通过跨发布周期持续更新其状态来确保增强保持最新。

/remove-lifecycle 冻结

你好@soltysh ,我是 1.15 的增强负责人。 这个功能会在 1.15 中从 alpha/beta/stable 阶段毕业吗? 请让我知道,以便可以正确跟踪并添加到电子表格中。 像往常一样,需要先合并 KEP,然后才能进行。

编码开始后,请列出此问题中所有相关的 k/k PR,以便正确跟踪它们。

作为用户,我已经成功使用这种资源很长时间了。 我没有看到 api 有任何重大问题。 是时候将其作为 GA 发布了吗?

我们正在研究毕业的 KEP

好的。 感谢更新。

@kow3ns @soltysh ,我是 1.16 增强负责人。 这个功能会在 1.16 中从 alpha/beta/stable 阶段毕业吗? 请告诉我,以便将其添加到1.16 跟踪电子表格中。 如果不是即将毕业,我会将其从里程碑中删除并更改跟踪标签。

一旦编码开始或如果已经编码,请在本期列出所有相关的 k/k PR,以便正确跟踪它们。

提醒一下,每个增强都需要一个处于可实施状态的 KEP,并带有解释每个 alpha/beta/稳定阶段要求的毕业标准。

里程碑日期是 Enhancement Freeze 7/30 和 Code Freeze 8/29。

谢谢你。

@soltysh @kow3ns ,1.17 增强阴影在这里。 我想检查一下,看看您是否认为此增强功能会在 1.17 中升级为 alpha/beta/stable?

目前的发布时间表是:

  • 9 月 23 日,星期一 - 发布周期开始
  • 10 月 15 日,星期二,EOD PST - 增强功能冻结
  • 太平洋标准时间 11 月 14 日星期四,EOD - 代码冻结
  • 11 月 19 日,星期二 - 必须完成和审查文档
  • 12 月 9 日星期一 - Kubernetes 1.17.0 发布

如果您这样做,我会将其添加到 1.17 跟踪表 (https://bit.ly/k8s117-enhancement-tracking)。 编码开始后,请列出此问题中所有相关的 k/k PR,以便正确跟踪它们。 👍

谢谢!

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
陈旧的问题在额外 30 天不活动后腐烂并最终关闭。

如果现在可以安全关闭此问题,请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

/删除生命周期陈旧

@soltysh @kow3ns

1.18 增强团队成员在这里。 我想检查一下,看看您是否认为此增强功能会在 1.18 中升级为 alpha/beta/stable? 增强功能将于 1 月 28 日冻结。

如果您这样做,我会将其添加到 1.18 跟踪表 (https://bit.ly/k8s-1-18-enhancements)。 编码开始后,请列出此问题中所有相关的 k/k PR,以便正确跟踪它们。 :+1:

谢谢!

目前的发布时间表是:

  • 1 月 6 日,星期一 - 发布周期开始
  • 太平洋标准时间 1 月 28 日星期二 EOD - 增强功能冻结
  • 太平洋标准时间 3 月 5 日星期四,EOD - 代码冻结
  • 3 月 16 日,星期一 - 必须完成和审查文档
  • 3 月 24 日,星期二 - Kubernetes 1.18.0 发布

@palnabarun @barney-s 正在努力及时关闭 KEP,实施将继续进行。

谢谢, @soltysh的更新。 我猜测增强功能的目标是稳定发布。 我正在跟踪表中更新相同的内容。 如果不是这样,请告诉我。

/stage稳定

/里程碑 v1.18

@barney-s 友情提示,距离增强冻结(1 月 28 日,星期二)只有 7 天了。

你有关于 KEP 的任何更新吗?

根据Slack上的

KEP 公关: https :

/里程碑清除

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
陈旧的问题在额外 30 天不活动后腐烂并最终关闭。

如果现在可以安全关闭此问题,请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

/删除生命周期陈旧

@soltysh @kow3ns ,1.19 增强阴影在这里。 我想检查一下,看看您是否认为此增强功能会在 1.19 中毕业?

为了发布这部分内容:

  1. KEP PR 必须合并为可实施状态
  2. KEP 必须有测试计划
  3. KEP 必须有毕业标准。

目前的发布时间表是:

  • 4 月 13 日,星期一:第 1 周 - 发布周期开始
  • 5 月 19 日,星期二:第 6 周 - 增强功能冻结
  • 6 月 25 日星期四:第 11 周 - 代码冻结
  • 7 月 9 日,星期四:第 14 周 - 必须完成并审核文档
  • 8 月 4 日,星期二:第 17 周 - Kubernetes v1.19.0 发布

如果您这样做,我会将其添加到 1.19 跟踪表 (http://bit.ly/k8s-1-19-enhancements)。 编码开始后,请列出此问题中所有相关的 k/k PR,以便正确跟踪它们。 👍

谢谢!

@soltysh / @kow3ns ,我正在跟进我之前关于此增强功能的更新,这是v1.19版本的一部分。

您是否碰巧有任何关于此版本包含在v1.19可能性的更新?

再次感谢您的时间和贡献。 🖖

@soltysh / @kow3ns ,我正在跟进我之前关于此增强功能的更新,这是v1.19版本的一部分。

您是否碰巧有任何关于此版本包含在v1.19可能性的更新?

再次感谢您的时间和贡献。 🖖

@soltysh / @kow3ns ,是否有计划将增强功能包含在v1.19 ? 请让我知道,以便我可以更新跟踪表以显示包含状态。

_增强功能冻结时间为 5 月 19 日_

请注意,最近 KEP 格式已更改。 此外,#1620 最近合并,将生产准备审查问题添加到 KEP 模板。
请借此机会重新格式化您的 KEP,并回答添加到该 PR 模板中的问题。

谢谢,
🖖

@soltysh / @kow3ns ,不幸的是,1.19 增强冻结的截止日期已经过去,KEP #978 仍在飞行中。 目前,这正在从里程碑和1.19 跟踪表中删除。 如果需要加入这个,请提交一个增强例外

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
陈旧的问题在额外 30 天不活动后腐烂并最终关闭。

如果现在可以安全关闭此问题,请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

/生命周期冻结

kubernetes/enhancements打开的增强问题不应被标记为冻结。
增强所有者可以通过跨发布周期持续更新其状态来确保增强保持最新。

/remove-lifecycle 冻结

/生命周期冻结

@soltysh

增强功能在这里。 在 1.20 中有任何计划吗?

谢谢,
克尔斯滕

@kikisdeliveryservice是的,我们正计划缓慢移动,请参阅https://github.com/kubernetes/enhancements/pull/1996以获取建议,因此 1.20 是我们将新控制器作为 alpha 引入的时间。 我刚刚用所有正确的链接更新了初始描述并匹配当前模板。

/里程碑 v1.20

@kikisdeliveryservice是的,我们计划缓慢移动,请参阅#1996 的建议,因此 1.20 是我们将新控制器作为 alpha 引入的时间。 我刚刚用所有正确的链接更新了初始描述并匹配当前模板。

好吧,我通读了一堆,但我有点困惑 😄
KEP 处于测试阶段。 它会留在测试版?? 直到 1.21 GA?

# The target maturity stage in the current dev cycle for this KEP.
stage: beta

# The most recent milestone for which work toward delivery of this KEP has been
# done. This can be the current (upcoming) milestone, if it is being actively
# worked on.
latest-milestone: "v1.20"

# The milestone at which this feature was, or is targeted to be, at each stage.
milestone:
  alpha: "v1.4"
  beta: "v1.9"
  stable: "v1.21"

听起来将在 1.20(新控制器等)期间完成工作以将其传递给 GA,但该工作可能需要一个或 2 个版本才能在 GA 之前完成? 我做对了吗? 所以这不需要为 1.20 版本进行跟踪?

(如果我错了,请纠正我!!)

听起来将在 1.20(新控制器等)期间完成工作以将其传递给 GA,但该工作可能需要一个或 2 个版本才能在 GA 之前完成? 我做对了吗? 所以这不需要为 1.20 版本进行跟踪?

那是正确的。 我们的目标不是 1.20 本身,但重要的工作(新控制器)将在 1.20 中落地。 这就是为什么我认为应该在 1.20 中对其进行跟踪,不是吗?

/stage 测试版

@soltysh有道理,让我们开始吧:+1:

对于我自己的记录,我们只是在等待 PR(符合标准) https://github.com/kubernetes/enhancements/pull/199610 月 6 日之前合并

KEP合并! :party_face:

@soltysh

由于您的增强功能计划在 1.20 发布,因此请记住即将到来的重要日期:
11 月 6 日,星期五:第 8 周 - Docs Placeholder PR 截止日期
11 月 12 日星期四:第 9 周 -代码冻结

提醒一下,请将您所有的 k/k PR 以及 docs PR 链接到此问题,以便我们可以跟踪它们。

谢谢!
克尔斯滕

你好@soltysh ,1.20 Docs 在这里。
为 1.20 计划的这项增强工作是否需要任何新文档或对现有文档的修改?

如果是这样,请按照此处的步骤k/website库中针对dev-1.20分支打开 PR。 这个 PR 目前可以只是一个占位符,必须在11 月 6 日之前创建

还可以查看发布的文档,以熟悉
谢谢!

罗杰:+1:

嗨@soltysh
文档占位符截止日期快到了。 请确保在截止日期前针对k/website中的dev-1.20分支创建占位符 PR

另外,请记住即将到来的重要日期:

@soltysh

看起来 kubernetes/kubernetes#93370 仍处于开放状态,但正在积极审查中。 只是提醒一下, Code Freeze将于 11 月 12例外

最好的事物,
克尔斯滕

是的,我在做,如果我们没有在接下来的几个小时内合并 PR,我们将填写例外。

它合并了! 惊人的!!

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

sparciii picture sparciii  ·  13评论

dekkagaijin picture dekkagaijin  ·  9评论

wlan0 picture wlan0  ·  9评论

justaugustus picture justaugustus  ·  7评论

majgis picture majgis  ·  5评论