It is always a good idea to drain/cordon a node while you do operational tasks like upgrades. Once the upgrade is completed, uncordon the node, and then repeat the process for the other nodes in the cluster.

Re: skipping versions, as far as I know there are no constraints against skipping minor versions in an upgrade.

After some testing and research, I come to some conclusion:

1. Drain the node is not a must. At least, drain can't evict daemonsets. But drain a node is recommend way to upgrade kubernetes, since this can at most extent reduce the impact to applications that's deployed using deployment.

   Also, sometimes, drain a node is neccesary. For instance, from kubernetes v1.10, the log files of all pods have changed from /var/log/pods/pod-id/container_id.log to /var/log/pods/pod-id/container/id.log, so when upgrade to v1.10, all pods have to restart to use the new log file, otherwise, you can't access their logs through 'kubectl logs' command. At this time, drain a node is helpful, and to those pods that can't be evicted, like daemonsets, we have to restart them manually.

2. Skip minor version upgrading is not supported, especially in a HA setup, with multiple masters, which can be proved somehow by GKE's supported upgrades policy. Also, skip minor version upgrading implies some risk sometimes.

   Again, as an example, upgrade to v1.10. In 1.10, objects in the apps API group began persisting in etcd in apps/v1 format, which can be handled very well by v1.9, but v1.8 can't. So, when you upgrade kubernetes from v1.8 to 1.10, in a HA setup, some masters have been upgraded, some haven't, will bring some weird problems, like deployment/daemonset can't be handled properly, more info refer to my another question. So, such upgrade should be avoid as long as possible.