# Safety of kubelet downgrade/rollback across minor versions

**URL:** https://discuss.kubernetes.io/t/safety-of-kubelet-downgrade-rollback-across-minor-versions/17193
**Category:** General Discussions
**Created:** [August 24, 2021, 4:24pm UTC](https://discuss.kubernetes.io/t/safety-of-kubelet-downgrade-rollback-across-minor-versions/17193 "2021-08-24T16:24:45Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![dsh](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@dsh](https://discuss.kubernetes.io/u/dsh)
#### Post date: [August 24, 2021, 4:24pm UTC](https://discuss.kubernetes.io/t/safety-of-kubelet-downgrade-rollback-across-minor-versions/17193/1 "2021-08-24T16:24:45Z")

</div>

The Kubernetes documentation [notes](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/#additional-information) the necessity of draining nodes when upgrading across minor versions. I am integrating a kubernetes deployment with a preexisting rollout/workflow engine that has a notion of a fleetwide rollback, and one question that I haven’t seen covered in the documentation is whether it is contractually safe to _roll back_ a node across minor versions, presumably while drained. The scenario might involve successful upgrades of many nodes in the fleet, the subsequent detection of a problem, and then a rollback of all nodes that have been upgraded.

I have not yet encountered any reason it would be dangerous today in practice, but before allowing such rollbacks, I want to understand whether there’s a risk of its becoming unsafe in the future (e.g. durable state in etcd precluding rollback).