Should rolling deploy command leverage cluster-autoscaler?

Way it might work:
1. Taint all the nodes in the cluster with `NoSchedule` so new pods won't be scheduled on the existing nodes.
1. In a rolling fashion, evict the pods on a set of nodes so that they need to be rescheduled. This should trigger new instances to be provisioned, because there are no nodes available for the pods to be scheduled on.
1. Since the pods are being evicted on the old nodes, they should be scaled in because they will become idle.

Also from [Jim](https://github.com/gruntwork-io/package-k8s/issues/32#issuecomment-449499585)

> One more thought:
> - The deployer can schedule itself as a Job in the K8S cluster
> - The deployer can then checkpoint its progress (e.g., in a ConfigMap)
> That way, if it is paused or restarted, it can just read the state and pick up where it left off