Reputation: 639
I tried to find useful information when should i use --record
. I created 3 commands:
k set image deployment web1 nginx=lfccncf/nginx:latest --record
k rollout undo deployment/web1 --record
k -n kdpd00202 edit deployment web1 --record
Could anyone tell me if I need to use --record
in each of these 3 commands?
When is it necessary to use --record
and when is it useless?
Upvotes: 12
Views: 14585
Reputation: 6786
--record
flag also helps to see the details of the revision history, so rollback to a previous version also would be smoother.
When you don't append --record
flag Change-Cause table will be just <none>
in
kubectl rollout history
$ kubectl rollout history deployment/app
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 <none>
Upvotes: 0
Reputation: 93213
Kubernetes desired state can be updated/mutated thru two paradigms :
k set
, k create
, k run
, k rollout
,..)k apply
The declarative way is ideal for treating your k8s manifests as Code, then you can share this Code with the team, version it thru Git for example, and keep tracking its history leveraging GitOps practices ( branching models, Code Review, CI/CD ).
However, the imperative way cannot be reviewed by the team as these adhoc-commands will be run by an individual and no one else can easily find out the cause of the change after the change has been made.
To overcome the absence of an audit trail with imperative commands, the --record
option is there to bind the root cause of the change as annotation called kubernetes.io/change-cause
and the value of this annotation is the imperative command itself.
(note below is from the official doc)
Note: You can specify the --record flag to write the command executed in the resource annotation kubernetes.io/change-cause. The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision.
As conclusion :
--record
is not mandatoryUpvotes: 19
Reputation: 44579
You can specify the --record
flag to write the command executed in the resource annotation kubernetes.io/change-cause
. The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision.
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
So it's not mandatory for any of the commands and but is recommended for kubectl set image
because you will not see anything in CHANGE-CAUSE
section as above if you skip --record
Upvotes: 16