Way to record during upgrading to new image

Varma 1,620 Reputation points
2026-07-25T05:53:39.9433333+00:00

I am tryign to execute below command but it is failing, what is wrong here? 

kubectl --record deployment/nginx-deployment set image deployment/nginx-deployment

nginx=nginx:1.17.0

what is wrong ?

how to use record?

why we use record?

and please see below commands: i execued: i should see 1.17 detail in the roll out history right? why i am not seeing ?

PS I:\AKSSelfhostedAgent_new\kubernetes> kubectl set image deployment/nginx-deployment nginx=nginx:1.17.0
deployment.apps/nginx-deployment image updated
PS I:\AKSSelfhostedAgent_new\kubernetes> kubectl describe deployment nginx
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Sat, 25 Jul 2026 11:11:18 +0530
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 2
Selector:               app=nginx
Replicas:               5 desired | 5 updated | 5 total | 5 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:         nginx:1.17.0
    Port:          80/TCP
    Host Port:     0/TCP
    Environment:   <none>
    Mounts:        <none>
  Volumes:         <none>
  Node-Selectors:  <none>
  Tolerations:     <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  nginx-deployment-6c768f97c8 (0/0 replicas created)
NewReplicaSet:   nginx-deployment-94f99c5 (5/5 replicas created)
Events:
  Type    Reason             Age                From                   Message
  ----    ------             ----               ----                   -------
  Normal  ScalingReplicaSet  6m27s              deployment-controller  Scaled up replica set nginx-deployment-6c768f97c8 from 0 to 2
  Normal  ScalingReplicaSet  4m44s              deployment-controller  Scaled up replica set nginx-deployment-6c768f97c8 from 2 to 5
  Normal  ScalingReplicaSet  18s                deployment-controller  Scaled up replica set nginx-deployment-94f99c5 from 0 to 2
  Normal  ScalingReplicaSet  18s                deployment-controller  Scaled down replica set nginx-deployment-6c768f97c8 from 5 to 4
  Normal  ScalingReplicaSet  18s                deployment-controller  Scaled up replica set nginx-deployment-94f99c5 from 2 to 3
  Normal  ScalingReplicaSet  14s                deployment-controller  Scaled down replica set nginx-deployment-6c768f97c8 from 4 to 3
  Normal  ScalingReplicaSet  14s                deployment-controller  Scaled up replica set nginx-deployment-94f99c5 from 3 to 4
  Normal  ScalingReplicaSet  14s                deployment-controller  Scaled down replica set nginx-deployment-6c768f97c8 from 3 to 2
  Normal  ScalingReplicaSet  14s                deployment-controller  Scaled up replica set nginx-deployment-94f99c5 from 4 to 5
  Normal  ScalingReplicaSet  13s (x2 over 14s)  deployment-controller  (combined from similar events): Scaled down replica set nginx-deployment-6c768f97c8 from 1 to 0

PS I:\AKSSelfhostedAgent_new\kubernetes> kubectl get all
NAME                                 READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-94f99c5-4k6xs   1/1     Running   0          56s
pod/nginx-deployment-94f99c5-7sgdn   1/1     Running   0          60s
pod/nginx-deployment-94f99c5-hnrjz   1/1     Running   0          60s
pod/nginx-deployment-94f99c5-jw4w6   1/1     Running   0          60s
pod/nginx-deployment-94f99c5-r2zv6   1/1     Running   0          56s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP   13m

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   5/5     5            5           7m10s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-6c768f97c8   0         0         0       7m10s
replicaset.apps/nginx-deployment-94f99c5      5         5         5       61s
PS I:\AKSSelfhostedAgent_new\kubernetes> kubectl rollout history deployment/nginx-deployment 
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

PS I:\AKSSelfhostedAgent_new\kubernetes>

and why it is showing as below ? for longer time

PS I:\AKSSelfhostedAgent_new\kubernetes> kubectl rollout status deployment/nginx-deployment

Waiting for deployment "nginx-deployment" rollout to finish: 3 out of 5 new replicas have been updated...

Azure Kubernetes Service
Azure Kubernetes Service

An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.

2 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Vinodh247-1375 44,556 Reputation points Volunteer Moderator
    2026-07-25T15:34:49.4433333+00:00

    Hi ,

    Thanks for reaching out to Microsoft Q&A.

    You have a couple of issues mixed together here.

    First, your command syntax is wrong. --record was a flag used in older Kubernetes versions, and it is deprecated/removed now. That is why nothing is captured in rollout history. Also your syntax is incorrect. The correct modern command is simply:

    kubectl set image deployment/nginx-deployment nginx=nginx:1.17.0

    If you want change tracking, you must manually add an annotation, for example:

    kubectl annotate deployment nginx-deployment kubernetes.io/change-cause="upgraded nginx to 1.17.0"

    Second, why you do not see 1.17.0 in rollout history: rollout history does not store image versions automatically. It only shows the CHANGE-CAUSE annotation. Since you did not set it (and --record no longer works), it shows <none>.

    Third, why --record was used: earlier it automatically stored the executed command in kubernetes.io/change-cause so you could audit changes. Now Kubernetes expects you to handle this explicitly (better for controlled deployments via CI/CD).

    Finally, the rollout status message:

    Waiting for deployment "nginx-deployment" rollout to finish: 3 out of 5 new replicas have been updated

    This simply means rolling update is in progress. Pods are being replaced gradually based on your strategy (25% max unavailable/surge). It can take time depending on pull time, node resources, or readiness probes. If it stays stuck long, check:

    kubectl get pods kubectl describe pod <pod-name>

    Most common causes are image pull delays or failing readiness probes.

    I dont see anything is broken. Your deployment updated correctly; you just expected old --record behaviour which no longer exists.

    Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

    Was this answer helpful?

    0 comments
  2. Sina Salam 31,456 Reputation points Volunteer Moderator
    2026-07-26T12:16:48.9566667+00:00

    Hello Varma,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that you would like to know how you can record during upgrading to new image.

    The behavior you observed is expected because the --record flag has been removed from modern Kubernetes releases, and kubectl rollout history only displays the kubernetes.io/change-cause annotation rather than the deployed container image version. Since no change-cause annotation was added, the rollout history correctly shows <none>, even though the image was successfully updated to nginx:1.17.0.

    The recommended and supported approach is to:

    • Update the Deployment image using kubectl set image.
    • Add a kubernetes.io/change-cause annotation if you want meaningful rollout history.
    • Verify the deployed image using kubectl describe deployment or kubectl get deployment -o=jsonpath=....
    • Use kubectl rollout history only to review deployment change descriptions, not image versions.

    Based on the deployment output you shared, the rollout completed successfully, the Deployment revision incremented correctly, and the new ReplicaSet replaced the previous one. No Azure Support or Product Group escalation is required because this is expected Kubernetes behavior. Kindly use the following resources for additional information:

    Observe the below commands for your review:

    • Use the supported command to update the container image: kubectl set image deployment/nginx-deployment nginx=nginx:1.17.0
    • If you want rollout history to show a meaningful description, add a change-cause annotation: kubectl annotate deployment nginx-deployment \ kubernetes.io/change-cause="Upgrade nginx image to 1.17.0" \ --overwrite
    • Confirm that the Deployment is running the expected image: kubectl get deployment nginx-deployment \ -o=jsonpath="{.spec.template.spec.containers[*].image}"or kubectl describe deployment nginx-deployment The output should show: nginx:1.17.0
    • Display the deployment revision history: kubectl rollout history deployment/nginx-deployment The history will display the configured CHANGE-CAUSE annotation rather than the image version.
    • Confirm that the rolling update completed successfully: kubectl rollout status deployment/nginx-deployment

    I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

    Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.