@derekwaynecarr @sttts @erictune没有看到这个问题，但它已经在 alpha 中。 将此作为提醒以将其推向测试版和稳定版。

@sttts您能否提供指向文档和 PR 的适当链接？ 我认为您最接近此代码。

@pweil- @sttts - 根据我们的讨论，这是我们希望在 @kubernetes/sig-node 下的 Kubernetes 1.6 中赞助的功能

@pweil- @derekwaynecarr请确认此功能必须设置为 1.6 里程碑。

@idvoretskyi我们的目标是将其移至 1.6 的测试版。

@sttts谢谢。

看起来这仍然是 alpha：

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/seccomp.md
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/annotation_key_constants.go#L35

我在 kubernetes.io/docs 上找不到任何文档。

@pweil- 1.8 有什么更新吗？ 此功能是否仍在发布中？

@idvoretskyi这不是 1.8 的优先事项。 @php-coder 你可以为我们的 PM 计划添加一张卡片吗？ 我们需要停止让它从裂缝中掉下来，并将其转移到 beta 和 GA。

@pweil-如果此功能未计划用于 1.8-请使用“下一个里程碑”或“1.9”更新里程碑

我希望看到这个进入测试版。 优先事项（或要求）包括：

1. 注释（Pod 和 PodSecurityPolicy）必须移动到容器SecurityContext上的字段（参见 https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field-现有 API 版本）
2. 确定OCI 规范 seccomp 格式，并定义 Kubernetes 默认配置文件（我们可以重用 Docker 的吗？） https://github.com/kubernetes/kubernetes/issues/39128
   一种。 弄清楚 Kubernetes 配置文件如何通过 CRI 传递到容器运行时（/cc @yujuhong @Random-Liu）
   湾如果运行时是 docker，则仍应允许docker/default （为了向后兼容）
3. Kubernetes 默认配置文件应该是新的默认配置。 为了向后兼容，这必须是可选行为（即标志控制）。 https://github.com/kubernetes/kubernetes/issues/39845

有人有兴趣为 1.9（或 1.10）里程碑推动这项工作吗？ @jessfraz @kubernetes/sig-auth-feature-requests 和 @kubernetes/sig-node-feature-requests 我在看着你 :wink:

同样相关： https :

/cc @destijl

如果有人有时间并想这样做，他们非常欢迎和我
将帮助回答任何问题

2017 年 9 月 22 日 20:54，“Tim Allclair (St. Clair)”通知@github.com
写道：

/cc @destijl https://github.com/destijl

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/kubernetes/features/issues/135#issuecomment-331593048 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/ABYNbDldlrwbOP75Y2AKM-bUFLnwrq0eks5slFbcgaJpZM4KgBy_
.

好的，如果没有其他人，我将更新提案并从明天开始；）

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

使用/lifecycle frozen注释防止问题自动关闭。

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

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

嘿@jessfraz不知道你是否有这方面的知识 - 我没有带宽来编码它，但很乐意帮助测试......

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

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

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

烂问题在 30 天不活动后关闭。
使用/reopen重新打开问题。
使用/remove-lifecycle rotten将问题标记为新问题。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/关闭

/重新打开
/生命周期冻结
/remove-lifecycle 腐烂的

@php-coder：除非您创作或分配给它，否则您无法重新打开问题/PR。

/重新打开
/生命周期冻结

2018 年 3 月 26 日星期一上午 7:07，k8s-ci-robot [email protected]
写道：

@php-coder https://github.com/php-coder ：你不能重新打开一个问题/PR
除非你创作它或你被分配给它。

对此的回应
https://github.com/kubernetes/features/issues/135#issuecomment-376129291
：

/重新打开
/生命周期冻结
/remove-lifecycle 腐烂的

此处提供了使用 PR 评论与我互动的说明
https://git.k8s.io/community/contributors/devel/pull-requests.md 。 如果
您对我的行为有任何疑问或建议，请提交
针对 kubernetes/test-infra 的问题
https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue：
存储库。

—
您收到此消息是因为您所在的团队已被提及。
直接回复本邮件，在GitHub上查看
https://github.com/kubernetes/features/issues/135#issuecomment-376129294 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/ABG_p9EwKebniej_GySRKSvzrCMITOA1ks5tiMvrgaJpZM4KgBy_
.

@smarterclayton ：除非您创作或分配给它，否则您无法重新打开问题/ PR。

/重新打开

@idvoretskyi ：除非您创作或分配给它，否则您无法重新打开问题/PR。

Ihor 1，机器人 0

@pweil- @php-coder @jessfraz
在 1.11 中有任何计划吗？

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

• 描述
• 里程碑
• 受让人
• 标签：
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

抄送@idvoretskyi

@wangzhen127正在处理中，但由于他还不是成员，因此无法分配。

https://github.com/kubernetes/kubernetes/pull/62662
https://github.com/kubernetes/kubernetes/pull/62671

感谢您的更新，蒂姆！
/remove-lifecycle 冻结

@pweil- @tallclair - 我们正在对1.11 功能跟踪电子表格进行更多扫描。
您介意为此功能的订单项填写任何不完整/空白的字段吗？

@pweil- @tallclair -- 此功能已从 1.11 里程碑中删除，因为没有更新 wrt 进度或文档。

抄送： @jberkus

@pweil- @tallclair @kubernetes/sig-auth-feature-requests @kubernetes/sig-node-feature-requests --

此功能已从之前的里程碑中删除，因此我们想查看 Kubernetes 1.12 中是否有任何计划。

如果是这样，请确保此问题与以下所有信息保持同步：

• 单行功能说明（可用作发行说明）：
• 主要联系人（受让人）：
• 负责的 SIG：
• 设计方案链接（社区回购）：
• 链接到 e2e 和/或单元测试：
• 审阅者 -（对于 LGTM）建议让 2 个以上的审阅者（至少一名来自代码区域 OWNERS 文件）同意进行审阅。 多家公司审稿人优先：
• 批准人（可能来自 SIG/特征所属的区域）：
• 功能目标（哪个目标等于哪个里程碑）：
  
  
  
  • Alpha 发布目标 (xy)
  
  
  • 测试版发布目标 (xy)
  
  
  • 稳定释放目标 (xy)
  
  

请注意，功能冻结是 7 月 31 日，之后任何未完成的功能问题都需要一个例外请求才能被接受到里程碑中。

此外，请注意以下相关截止日期：

• 文档截止日期（开放占位符 PR）：8/21
• 测试用例冻结：8/28

请确保所有功能的 PR 也包含相关的发行说明。

祝您发货愉快！

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

1.12 没有计划更改

感谢您的更新，@tallclair！

有人有兴趣为 1.9（或 1.10）里程碑推动这项工作吗？ @jessfraz @kubernetes/sig-auth-feature-requests 和 @kubernetes/sig-node-feature-requests 我看着你眨眼

@tallclair如果仍然需要，我现在可以尝试拿起它

@stlaz ：重申提及以触发通知：
@kubernetes/sig-auth-feature-requests, @kubernetes/sig-node-feature-requests

@stlaz ，仍然需要此功能。 我花了一些时间将 seccomp 配置文件添加到插件作为#39845 的第一步。 但我没有足够的时间来推动这个功能。 如果你喜欢在这方面工作，那就太好了。 欢迎任何帮助！ :)

@wangzhen127谢谢，我正在尝试完成已完成的工作以及与此功能相关的问题。 似乎https://github.com/kubernetes/features/issues/135#issuecomment -331592961 的评论仍然成立并准确总结了现在需要完成的工作。

我也注意到你试图为此添加一个 FeatureGate，但关闭了 PR，这是为什么？

PS：很抱歉回复晚了，我离开了一段时间。

似乎评论 #135（评论）仍然正确地总结了现在需要完成的工作。

没错。 我想补充的另一件事是拥有“投诉”模式。 因此，用户可以选择获取使用禁止的系统调用的警告（在日志中）而不是杀死。 记录 seccomp 操作可用于 Linux 内核 4.14+ ( seccomp doc )。 可能仍在使用较旧的内核版本。 所以我们需要处理它。 这也需要添加到 OCI 规范中。

我也注意到你试图为此添加一个 FeatureGate，但关闭了 PR，这是为什么？

该功能门的目的是将 seccomp 默认配置文件从无限制更改为“运行时/默认”。 我对向后兼容性有很多担忧，所以这似乎不太可能发生。 我们目前缺乏总体上更改安全默认值的计划，因为这些正在破坏。 我目前认为最好的方法是将 seccomp 推向稳定，它仍然必须是一个选择加入的功能，而不是选择退出。

记录 seccomp 操作可用于 Linux 内核 4.14+ ( seccomp doc )。

我想因为我们将定义一个特定于 Kubernetes 的默认 seccomp 格式作为第二步的一部分，所以我们也可以有一个代替日志的格式。 它有足够的价值吗？ 当后者失败太多时，它是否可以用于人们从“无限制”过渡到“kube/default”？ 他们会关心它切换到切换回来吗？
有使用 4.13-Linux 内核的 LTS 发行版（Debian - 8,9；RHEL - 6, 7；Ubuntu LTS - 14.04, 16.04），因此内核兼容性绝对是需要牢记的。

我对向后兼容性有很多担忧，所以这似乎不太可能发生。

过去，当容器运行时第一次启用 seccomp 时，它们也必须经历这种变化。 现在至少 docker 带有默认行为，这比“无限制”更不允许，这可能会破坏某人。 如果我们只是遵循底层组件的行为（也提供关闭此行为的选择），我认为我们没有做错任何事情。

它有足够的价值吗？

这个可以讨论。 我最初的想法是将默认值从无限制更改为日志记录。 所以我们没有向后兼容性问题。 如果我们能以某种方式收集数据并显示在 X% 的情况下，我们看不到任何记录，这意味着默认配置文件不会破坏事物。 然后我们可以建议将日志记录更改为kill。 收集数据部分很棘手，可能需要做很多工作。 即使我们实际上不走那条路，我认为当人们想尝试 seccomp 但还没有信心时，拥有日志记录配置文件也会使他们受益。

过去，当容器运行时第一次启用 seccomp 时，它们也必须经历这种变化。 现在至少 docker 带有默认行为，这比“无限制”更不允许，这可能会破坏某人。 如果我们只是遵循底层组件的行为（也提供关闭此行为的选择），我认为我们没有做错任何事情。

当 docker 更改默认值时，kubernetes 明确地将该值重置为 unconfined。 我之前联系过离线 sig-architecture 人员，他们非常担心向后兼容性问题。

如果我们能以某种方式收集数据并显示在 X% 的情况下，我们看不到任何记录，这意味着默认配置文件不会破坏事物。

我喜欢这个主意。 困难的部分当然是获取数据，我不知道如何实现这一点。 此外，我们必须首先向 OCI 规范提出这一更改，然后可能至少为一个容器运行时实现它，对吗？ 这可以在生命周期的 Beta 部分发生吗？

当 docker 更改默认值时，kubernetes 明确地将该值重置为 unconfined。 我之前联系过离线 sig-architecture 人员，他们非常担心向后兼容性问题。

我知道了。 也许我们确实可以将“无限制”配置文件作为默认配置文件（可能稍后用kube/logging类的内容替换它）。 似乎这可能更像是由 PSP 以拒绝规则的方式控制，我们首先假设一切都是默认允许的，我们只是进一步削减特权。 但是，在 PSP 关闭的情况下，对此进行标志控制可能很有用，因此也应该进入，但同时使用这两种机制可能会有点混乱。

我想这与最初考虑的方向有点不同 - 它与https://github.com/kubernetes/kubernetes/issues/39845 中所做的工作背道而驰，但如果我们同意上述观点，那么我们应该考虑 seccomp 配置文件我们最终会发货。 到目前为止，我看到runtime/default 、 kube/default 、 kube/logging ，以及将配置文件设置为unconfined 。 剩下的当然是拥有localhost/.*配置文件的能力，这是当前实现已经提供的。

这可以在生命周期的 Beta 部分发生吗？

听起来不错。 尽管我认为尽早启动 OCI 规范提案会有所帮助。

将“无限制”作为默认设置，现在对我来说听起来不错。 对于 kubernetes/kubernetes#39845，我为插件添加了注释。 我认为我们不能再进一步了。

到目前为止，我看到了 runtime/default、kube/default、kube/logging，以及将配置文件设置为 unconfined 的选项。 剩下的当然是拥有 localhost/.* 配置文件的能力，这已经由当前的实现提供了。

为我工作。 对于kube/default ，我们可以从docker/default 。

记录 seccomp 操作可用于 Linux 内核 4.14+ (seccomp doc)。

我的理解是这会用 PID 记录操作 - 不一定是与容器相关的信息。 因此，主机上的 auditd 或其他一些守护进程将需要进行查找/映射以使日志真正有用...

如果我们能以某种方式收集数据并显示在 X% 的情况下，我们看不到任何记录，这意味着默认配置文件不会破坏事物。 然后我们可以建议将日志记录更改为kill。 收集数据部分很棘手，可能需要做很多工作。

为docker启动@jessfraz不是已经这样做了吗？ 如果这不是一个足够强的信号，就很难收集到更强的信号……

@tallclair你说得对，我对所有问题的评论都https :

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

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

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

谢谢！

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

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

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

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

/remove-lifecycle 冻结

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

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

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

/remove-lifecycle 腐烂的

你好@stlaz @pweil-，我是 1.15 的增强负责人。 这个功能会在 1.15 中从 alpha/beta/stable 阶段毕业吗？ 请让我知道，以便可以正确跟踪并添加到电子表格中。 这还需要将 KEP 包含在 1.15 中

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

1.15 没有计划更改

嗨@tallclair @pweil- @stlaz ，我是 1.16 增强主管/影子。 这个功能会在 1.16 中从 alpha/beta/stable 阶段毕业吗？ 请告诉我，以便将其添加到1.16 跟踪电子表格中。 如果不是即将毕业，我会将其从里程碑中删除并更改跟踪标签。

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

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

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

谢谢你。

我已经开始计划将其引入 GA，但在 1.16 中实现它可能需要一段时间。 不过，我会尝试通过增强功能冻结来提出建议。

你好@tallclair @pweil-，1.17 增强阴影在这里！ 🙂

我想联系看看*此增强功能是否会在 1.17 中升级为 alpha/beta/stable？
请让我知道，以便可以将此增强功能添加到1.17 跟踪表中。

谢谢！

🔔友情提示

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

• Kubernetes Enhancement Proposal (KEP) 必须满足以下标准，然后 Enhancement Freeze才能被接受到发布中

  • PR 被合并到
  • 处于implementable状态
  • 包括测试计划和毕业标准

• 本期应列出所有相关的 k/k PR

是的，我计划在 v1.17 中将其升级到稳定版 - KEP 在这里： https :

嘿@tallclair ，我会将此增强功能添加到要跟踪的跟踪表中👍

请参阅上面的消息以进行友好提醒，并注意 KEP 处于临时状态。 KEP 必须处于可实施状态才能添加到 1.17 版本。

/里程碑 v1.17
/stage稳定

嘿@tallclair能否请您在 testgrid 中发布测试链接并跟踪为此增强功能添加的任何测试？

谢谢！

会做。 已经有一堆 seccomp 测试，但我在任何仪表板选项卡上都找不到它（无论如何要在所有测试网格中搜索特定测试？）
https://github.com/kubernetes/kubernetes/blob/0956acbed17fb71e76e3fbde89f2da9f8ec8b603/test/e2e/node/security_context.go#L147 -L177

@tallclair没有在所有 testgrid 中进行搜索的好方法 =/

我最好的猜测（至少对于您引用的 4 个）是它们实际上并没有被包括在内。 😬

它们看起来应该是node-kubelet-features 仪表板的一部分，但是ci-kubernetes-node-kubelet-features的作业配置有这个test_args ：

--test_args=--nodes=8 --focus="\[NodeFeature:.+\]" --skip="\[Flaky\]|\[Serial\]"

银杏测试本身被标记为[Feature:Seccomp]并且焦点标志不匹配。

我认为一旦迁移到 GA，我们就应该删除功能标签。 我认为 seccomp 在 linux 上是标准的，所以[LinuxOnly]标签应该就足够了。

对于未运行测试的一般问题，我提交了https://github.com/kubernetes/test-infra/issues/14647

嘿@tallclair ，我们距离增强功能冻结（太平洋标准时间 10 月 15 日，星期二）只有 5 天了。 另一个友好的提醒，为了能够在 1.17 版本中完成此操作，必须合并 KEP 并且必须处于可实施状态。 看起来 KEP 仍然开放并且处于临时状态。

嘿@tallclair ，不幸的是，1.17 增强冻结的截止日期已经过去，看起来 KEP 仍然开放。 我将从 1.17 里程碑中删除此增强功能。

请注意，如果您需要在 1.17 中获得此功能，您可以提交

/里程碑清除

是的，没有晋级。 希望能进
/里程碑 v1.18

听起来不错！ 我将在增强跟踪表中将此标记为延迟到 v1.18。

嘿👋，我们能做些什么来推动这一进程。 我很乐意在这里以及为 AppArmor 问题做出贡献。

嘿@tallclair

1.18 增强团队签到！ 您是否打算在 1.18 中升级到稳定版？ 看起来 KEP 仍然是开放的。

发布时间表如下：

增强冻结： 1 月 28 日
代码冻结： 3 月 5 日
文档准备就绪： 3 月 16 日
v1.18 发布： 3 月 24 日

提醒一下，KEP 需要合并，状态设置为implementable 。

谢谢！

@saschagrunert感谢您的报价！ 我需要在 KEP 再考一次，以跟进我与 @liggitt 进行的 API 审查。 一旦 KEP 获得批准，我将欢迎您帮助实施。

我认为目前 KEP 上最大的悬而未决的问题是如何处理 localhost 配置文件类型。 由于我们想要弃用该功能（理想情况下支持类似 https://github.com/kubernetes/enhancements/pull/1269, /cc @pjbgf ），我想避免在 API 中为其放置一个字段.

嘿@tallclair ，关于这是否会使其成为 1.18 的任何更新？ 它目前已标记在里程碑中，但您尚未确认我们是否应该对其进行跟踪。

谢谢！

v1.18 似乎不太可能。 我想我们可以碰上
/里程碑 v1.19

太好了，感谢更新@tallclair :)

嗨@tallclair -- 1.19 增强功能 领导这里，您是否计划将此增强功能升级到stable此版本？

没有计划在 v1.19 中毕业。 我有一个开放的 KEP，但本季度不会处理它。 @pjbgf可能会在 v1.20 中找到它

@tallclair——感谢您的更新。 :slightly_smiling_face:

/里程碑 v1.20

这个计划略有变化 - 正如昨天的签名节点会议所同意的那样。 现在计划用于：

/里程碑 v1.19

@pjbgf ：您必须是kubernetes/milestone-maintainers GitHub 团队的成员才能设置里程碑。 如果您认为您应该能够发出 /milestone 命令，请联系您并让他们建议您作为此职责的附加代表。

@palnabarun您介意将此问题设置为里程碑 v1.19 吗？

/分配 pjbgf

/里程碑 v1.19

谢谢@pjbgf @tallclair的更新。 我已根据您的计划更新了跟踪表。

你能告诉我你的目标是哪个毕业阶段以及 KEP 的链接吗？

谢谢！ 感谢所有的努力。 :slightly_smiling_face:

目前的发布时间表是：

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

定位 GA

KEP： https :
KEP 仍有未解决部分，后续 PR： https :

嗨@tallclair ，感谢您的更新。 ：+1：

我已经相应地更新了跟踪表。

PS：我已经用 KEP 的链接和最新的 KEP 更新 PR 更新了问题描述。

谢谢@palnabarun的更新。 ：+1：

嗨@tallclair 👋 1.19 文档阴影在这里！ 为 1.19 计划的这项增强工作是否需要对文档进行新增或修改？

友情提示，如果需要对文档进行新的/修改，在 6 月 12 日星期五之前需要针对 k/website（分支dev-1.19 ）的占位符 PR。

@annajung那是为了

添加@hasheddan谁正在接受这个（https://github.com/kubernetes/kubernetes/issues/58211）。

太好了，谢谢你的更新！ 我将相应地修改跟踪表。
一旦针对 k/website 的占位符 PR 完成，请告诉我们。 谢谢！

@pjbgf——您能否在此处链接到所有实施 PR 的链接

目前的发布时间表是：

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

@palnabarun这是当前的：
https://github.com/kubernetes/kubernetes/pull/91381
https://github.com/kubernetes/kubernetes/pull/91408
https://github.com/kubernetes/kubernetes/pull/91182
https://github.com/kubernetes/kubernetes/pull/91442

我还创建了一个包含所有这些的保护伞问题。

嗨@pjbgf @hasheddan只是一个友好的提醒，针对 k/website 的占位符 PR 将于 6 月 12 日星期五到期。请在完成 PR 后通知我，谢谢！

@annajung谢谢提醒！ 它很快就会开放:+1:

嗨@pjbgf - 感谢您创建保护伞问题。 ：+1：

我们正在跟踪相同的情况。 :slightly_smiling_face:

嗨@pjbgf - 只是想检查一下增强的进度。

最近修订了发布时间表，可以在此处找到更多详细信息。

请让我知道，如果你有任何问题。 :slightly_smiling_face:

修订后的发布时间表是：

• 7 月 9 日星期四：第 13 周 - 代码冻结
• 7 月 16 日星期四：第 14 周 - 必须完成和审查文档
• 8 月 25 日，星期二：第 20 周 - Kubernetes v1.19.0 发布

感谢您更新@palnabarun。 代码大部分都完成了，但我们现在正在等待后续审查。 总的来说，我们看起来还是不错的。 ：+1：

嗨@pjbgf @hasheddan ，友好提醒下一个截止日期即将到来。
请记住填写您的占位符文档 PR 并在 7 月 6 日星期一之前准备好进行审核。

嗨@pjbgf @hasheddan :wave:，我看到https://github.com/kubernetes/kubernetes/issues/91286中仍有 3 个待处理的操作项用于实现相关的更改，还有 1 个待处理的操作项用于文档。 您认为他们会在 7 月 9 日星期四度过代码冻结期吗？

谢谢你。 :slightly_smiling_face:

Code Freeze 从太平洋标准时间 7 月 9 日星期四开始

@palnabarun docs PR 大部分都准备好了，只是为 seccomp 添加了一个特定的指南。 已经有来自@saschagrunert 的关于当前变化的

嗨@hasheddan ，感谢上面的更新。 只是一个快速提醒，让 EOD 准备好您的文档 PR 以供审查（删除 WIP/rebased/all ready to go）。 谢谢！

@annajung会做的！ 谢谢！

@hasheddan——感谢您的更新。 ：微笑：

@pjbgf——我在https://github.com/kubernetes/kubernetes/issues/91286 中看到，两个核心操作项尚未合并，也不在合并池中。 你认为他们会在代码冻结之前进入吗？

谢谢你。 :slightly_smiling_face:

@palnabarun我们正试图在代码冻结之前完成它，毕竟它已经是所有 lgtm 了。 我们在一些不稳定的测试 atm 上遇到了一些问题。 😅

谢谢你的提醒。

为清楚起见，我们等待合并的 2 个 prs 是：
https://github.com/kubernetes/kubernetes/pull/91408和https://github.com/kubernetes/kubernetes/pull/92856

后者（https://github.com/kubernetes/kubernetes/pull/92856）似乎未通过验证检查。 根据https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700 这将需要 rebase/repush/rereview 才能合并..

@kikisdeliveryservice感谢您的澄清。 我们正在等待https://github.com/kubernetes/kubernetes/pull/91408上的片状测试停止失败，一旦合并，我们就可以重新建立依赖于它的第二个 PR。

嗨@pjbgf :wave:，我们现在进入代码冻结。

因为， https://github.com/kubernetes/kubernetes/pull/91408在合并池中，而https://github.com/kubernetes/kubernetes/pull/92856需要对https://github.com/进行变基https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700，我们觉得这里最好的操作是提交异常请求以获得额外的时间来完成第二个合并池清除后的 PR。

暂时从里程碑中删除增强功能。

谢谢！

最好的事物，
Kubernetes v1.19 发布增强团队

/里程碑清除

由于 kubernetes/kubernetes#91408 在合并池中，而 kubernetes/kubernetes#92856 需要根据 kubernetes/kubernetes#92856（评论）对 kubernetes/kubernetes#91408 进行变基，我们认为这里最好的操作是提交异常请求在合并池清除后获得更多时间来完成第二个 PR。

基于合并队列中已批准 PR 的变基不需要异常请求。 PR 代码完整，并在截止日期前一整天获得批准。

嗨@liggitt :wave:，感谢您的投入。 ：+1：

我们将把增强功能重新加入循环中。 我们所有的担忧都与变基有关。 既然已经排序，这很好。 :slightly_smiling_face:

/里程碑 v1.19

@pjbgf @saschagrunert @hasheddan - 感谢您的所有贡献。 :100:

感谢@palnabarun对增强功能的详细跟踪。 我们很感激！ 🙏

@saschagrunert最终 PR kubernetes/kubernetes#92856 合并。 恭喜！ 我将更新跟踪表以反映这一点。

@tallclair @pjbgf你认为我们现在可以关闭这个问题，因为 seccomp 是 GA 吗？

@saschagrunert我们通常等待发布发生，然后将相应的 KEP 标记为implemented ，然后关闭增强问题。

请随时进行更改以将https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md标记为implemented 。 :slightly_smiling_face:

@saschagrunert我们通常等待发布发生，然后将相应的 KEP 标记为implemented ，然后关闭增强问题。

请随时进行更改以将https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md标记为implemented 。

谢谢澄清，在https://github.com/kubernetes/enhancements/pull/1932开了个PR

KEP 已更新实施（PR 终于合并了！）

请随时关闭此问题@saschagrunert

谢谢大家的工作！！

/里程碑清除

/关闭
大功告成。

@saschagrunert我不记得我们之前是否讨论过这个问题，但是有没有计划最终清理注释（即删除支持）？ 这样做的主要动机是让 3rd 方工具（例如 Gatekeeper、krail）不需要知道检查注释和字段

@saschagrunert我不记得我们之前是否讨论过这个问题，但是有没有计划最终清理注释（即删除支持）？ 这样做的主要动机是让 3rd 方工具（例如 Gatekeeper、krail）不需要知道检查注释和字段

是的，这是为 v1.23 计划的。 这与警告机制（尚未完成）相结合，可以在必要的实用功能存在后完成（参考 https://github.com/kubernetes/kubernetes/issues/94626）。

来自 KEP：

为了提高对注释使用的认识（在旧的自动化的情况下），将使用警告机制来强调将在 v1.23 中删除支持。 正在考虑的机制是审计注释、对象注释、事件或 KEP #1693 中描述的警告。

…

由于我们最多支持主节点和节点之间版本偏差的 2 个次要版本，因此必须继续支持和回填至少 2 个通过初始实现的版本的注释。 但是，我们可以决定进一步扩大支持以减少破损。 如果此功能在 v1.19 中实现，我建议将 v1.23 作为删除旧行为的目标。

在这些位也实现之前，您是否更愿意重新打开这个问题？

是的，让我们保持开放，直到该功能完全结束。 您描述的工作是否存在 ak/k 问题？

是的，让我们保持开放，直到该功能完全结束。 您描述的工作是否存在 ak/k 问题？

现在我们有了一个：https://github.com/kubernetes/kubernetes/issues/95171 :)