在 Kubernetes 中的 kubectl 命令式命令中使用 --record

Question

我试图找到有用的信息，我应该在什么时候使用--record. 我创建了 3 个命令：

• k set image deployment web1 nginx=lfccncf/nginx:latest --record
• k rollout undo deployment/web1 --record
• k -n kdpd00202 edit deployment web1 --record

谁能告诉我是否需要--record在这 3 个命令中的每一个中使用？

什么时候需要用--record，什么时候不用？

Answer 1

您可以指定--record标志来写入资源注释中执行的命令kubernetes.io/change-cause。记录的更改对于将来的自省很有用。例如，查看在每个部署修订版中执行的命令。

kubectl rollout history deployment.v1.apps/nginx-deployment
The output is similar to this:

deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true

因此，对于任何命令都不是强制性的，但建议kubectl set image您这样做，因为CHANGE-CAUSE如果跳过，您将看不到上述部分中的任何内容--record

Answer 2

Kubernetes 所需的状态可以通过两种范式更新/改变：

1. 要么强制使用 kubectl adhoc 命令 ( k set, k create, k run, k rollout,..)
2. 或者声明性地使用 YAML 清单和单个k apply

声明式方式非常适合将您的 k8s 清单视为代码，然后您可以与团队共享此代码，例如通过 Git 对其进行版本控制，并利用 GitOps 实践（分支模型、代码审查、CI/CD）继续跟踪其历史记录。

但是，团队无法审查命令式方式，因为这些临时命令将由个人运行，并且在进行更改后没有其他人可以轻松找出更改的原因。

为了克服缺少命令式命令的审计跟踪的问题，--record可以选择将更改的根本原因绑定为调用kubernetes.io/change-cause的注释，并且此注释的值是命令式命令本身。

（以下注释来自官方文档）

注意：您可以指定 --record 标志写入资源注解 kubernetes.io/change-cause 中执行的命令。记录的更改对于将来的自省很有用。例如，查看在每个部署修订版中执行的命令。

作为结论：

• 理论上，--record不是强制性的
• 实际上，为了确保更改留下基本的审计跟踪并遵守 SRE 流程和 DevOps 文化，这是强制性的。