Home Explore Blog CI



kubernetes

10th chunk of `content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md`
e6caccc36d9d83aea58dc84a4310d3fcde3d9174bbeb005c0000000100000bd3
# Or use --to-revision to roll back to a specific revision

$ kubectl rollout undo ds node-exporter --to-revision=2  
daemonset "node-exporter" rolled back
 ```




A DaemonSet rollback is done by rolling forward. Therefore, after the rollback, DaemonSet revision 2 becomes revision 4 (current revision):



```  
$ kubectl rollout history ds node-exporter   
daemonsets "node-exporter"  
REVISION               CHANGE-CAUSE  

1                             kubectl apply --filename=node-exporter-v0.13.yaml --record=true  

3                             kubectl apply --filename=node-exporter-bad.yaml --record=true  

4                             kubectl apply --filename=node-exporter-v0.14.yaml --record=true

 ```




The node exporter DaemonSet is now healthy again:



```  
$ kubectl rollout status ds node-exporter  
daemon set "node-exporter" successfully rolled out


# N = number of nodes

$ kubectl get ds node-exporter

NAME                       DESIRED     CURRENT     READY         UP-TO-DATE     AVAILABLE     NODE SELECTOR     AGE  

node-exporter     N                 N                 N                 N                       N                     \<none\>                   46m

 ```




If current DaemonSet revision is specified while performing a rollback, the rollback is skipped:



```  
$ kubectl rollout undo ds node-exporter --to-revision=4  
daemonset "node-exporter" skipped rollback (current template already matches revision 4)
 ```




You will see this complaint from kubectl if the DaemonSet revision is not found:



```  
$ kubectl rollout undo ds node-exporter --to-revision=10  
error: unable to find specified revision 10 in history
 ```




Note that kubectl rollout history and kubectl rollout status support StatefulSets, too!

## Cleaning up

```  
$ kubectl delete ds node-exporter
 ```




# What’s next for DaemonSet and StatefulSet

Rolling updates and roll backs close an important feature gap for DaemonSets and StatefulSets. As we plan for Kubernetes 1.8, we want to continue to focus on advancing the core controllers to GA. This likely means that some advanced feature requests (e.g. automatic roll back, infant mortality detection) will be deferred in favor of ensuring the consistency, usability, and stability of the core controllers. We welcome feedback and contributions, so please feel free to reach out on [Slack](http://slack.k8s.io/), to ask questions on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes), or open issues or pull requests on [GitHub](https://github.com/kubernetes/kubernetes).



- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
- Join the community portal for advocates on [K8sPort](http://k8sport.org/)
- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
- Connect with the community on [Slack](http://slack.k8s.io/)
- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)

Title: DaemonSet Rollback Completion and Future Plans
Summary
This section details the outcome of a successful DaemonSet rollback, verifying its health through `kubectl rollout status` and `kubectl get ds`. It also demonstrates scenarios where a rollback is skipped (when the target revision is the current one) or fails (when the revision is not found). Finally, it outlines future development plans for DaemonSets and StatefulSets, focusing on core controller stability, and encourages community engagement through various channels.