Day 52: Undo Rolls Forward, and the Disk Already Mounted Is the One Not to Trust
Day 52 of DevOps, Day 2 of Azure. Both tasks today were about commands that do something a little different from what their names suggest.
Spots 
kubectl rollout undo sounds like a rewind. It
kubectl rollout undo sounds like a rewind. It is not one; it rolls forward to an old template. And az vm create sounds like it creates a VM. It does, along with a network, a firewall rule, a public address and one more disk than I asked for, and that extra disk is the one not to keep anything on.
One Kubernetes task, one Azure task. Roll a
One Kubernetes task, one Azure task. Roll a Deployment back to its previous version, then create an Azure VM with a specific image, size and disk type. The tasks come from the KodeKloud Engineer platform.
Yesterday's rolling update kept the old ReplicaSet on
Yesterday's rolling update kept the old ReplicaSet on purpose. Today's task is what it was kept for: a release has a bug, so go back to the previous revision.
Under the hood, kubectl's rollback code takes the
Under the hood, kubectl's rollback code takes the pod template stored in the older ReplicaSet and patches it into the Deployment's .spec.template. A changed template is exactly what starts a rollout, as yesterday's post covered, so an undo is a new rollout with the same rolling behaviour as any other update. The Kubernetes docs put it briefly: each rollback updates the revision of the Deployment. Two consequences are worth knowing.
Only the template goes back. The docs say
Only the template goes back. The docs say "only the Deployment's Pod template part is rolled back". If someone scaled the Deployment or changed its strategy since that revision, those changes stay.
And the history has a limit. Revisions are
And the history has a limit. Revisions are the old ReplicaSets, and .spec.revisionHistoryLimit keeps ten of them by default. Set it to zero, and in the docs' words, "a new Deployment rollout cannot be undone".
One habit I am adding is kubectl rollout
One habit I am adding is kubectl rollout history before the undo, to see what there is to go back to. Its CHANGE-CAUSE column shows <none> unless you set the kubernetes.io/change-cause annotation, and the old --record flag that used to fill it is deprecated. A history where every revision says <none> tells you nothing at the moment you most need it.
The point I would underline, though, is this
The point I would underline, though, is this one. Undo fixes the cluster, not the source of truth. If the buggy image is still in a manifest file, the next kubectl apply of that file rolls the bug straight back out. The rollback is only finished when the file, or the commit, goes back too. One command, a lot of resources The Azure task was a single VM: Ubuntu 24.04, Standard_B1s, a 30 GB Standard HDD disk, SSH access.
az vm create does much more than its
az vm create does much more than its name says. Alongside the VM, it created a virtual network and subnet, a network security group with an SSH rule, a public IP address, a network interface, an OS disk and a data disk. Microsoft describes this as the CLI using default values to create any required supporting resources.
News
Day 52: Undo Rolls Forward, and the Disk Already Mounted Is the One Not to Trust
Day 52 of DevOps, Day 2 of Azure.
@spots #dev
Source: Dev.to