/sig cli
/sig docs
/sig architecture

我原本以为会找到已弃用的注解。
这似乎是一个需要澄清的重要点。
kubernetes.io/change-cause 注解仍然作为 kubectl rollout history 命令的一部分返回。
看起来你可以通过直接设置它来查看这个注解，所以它仍然可以发挥作用：

40422 (评论)

我认为 --record 标志的一个问题是，如果你使用像 kubectl apply 这样的建议命令，它实际上并不提供任何价值。
例如，假设我这样做：

kubectl apply -f deploy.yaml --record

然后编辑 deploy.yaml 以更改图像版本，然后再次运行此操作：

kubectl apply -f deploy.yaml --record

当我查看发布历史记录时，它只会显示这个：

REVISION  CHANGE-CAUSE
1         kubectl apply --filename=deploy.yaml --record=true
2         kubectl apply --filename=deploy.yaml --record=true

如果你直接设置注解(就像我在上面链接的评论中那样),我可以看到它仍然有一些价值，比如：

$ kubectl apply -f deploy.yaml
deployment.apps/foo created
$ kubectl annotate deploy/foo kubernetes.io/change-cause="Initial Deployment"
deployment.apps/foo annotated
$ kubectl apply -f deploy.yaml
deployment.apps/foo configured
$ kubectl annotate deploy/foo kubernetes.io/change-cause="Image changed to 1.22.0"
deployment.apps/foo annotated
$ kubectl rollout history deploy/foo
deployment.apps/foo 
REVISION  CHANGE-CAUSE
1         Initial Deployment
2         Image changed to 1.22.0

尽管如此，我认为源代码控制是记录应用中清单版本之间差异的更好地方。在这种情况下，change-cause 注解可能用于存储包含已应用文件的提交的 git 提交哈希。
@soltysh 你认为呢？kubernetes.io/change-cause 注解是否仍将在 kubectl rollout history 的输出中使用，还是当你移除 --record 时，你会看到这一列消失？

如果我们真的想要改变跟踪，我认为有人应该创建(从树中！)一个ChangeHistory API类型或APIService。

我们应该完全移除该标志，因为已达到弃用期。然后，我们应该在此问题中更新相关的文档，以反映您应该手动设置注解并附上示例。

我们应该更新本期的关联文档，以反映您应该手动设置注解并附上示例。
我更倾向于弃用注解。它不适合在工具和人类都可以对一个对象进行更改的世界中使用。

我认为只要rollout命令还在使用，我们可能就需要类似的东西来管理这个领域。我们可以讨论废弃rollout,但我认为这会引起很多反对意见。这是kubectl中命令式和声明式之间的永恒斗争😞

如果你同意，也许我可以开始移除这个标志？