It appears that gardener/machine-controller-manager could be taught about Spot instances fairly easily, and there is an existing issue to do just such a thing. I can't recall off-hand if that is the Node Controller Manager that I recalled seeing, or it is merely a Node Controller Manager and thus there may be other implementations of that idea which already include spot support.

That makes a presumption that you actually meant spot for the workers, and not for the whole cluster. If you mean the whole cluster, then you may be much, much happier with something like kubespray and use that to lay a functioning cluster on top of existing machines. Just bear in mind that while kubernetes certainly is resilient to "damage," including the loss of a master, an etcd member, and without question the loss of a Node, it might frown if a huge portion of its machines vanish at once. In other words: using spot could mean that you spend more programmer/devops/glucose triaging spot disappearance, or you have to so vastly overprovision replicas that it starts to eat into the savings from spot in the first place.

From the docs https://github.com/kubernetes/kops/blob/master/docs/instance_groups.md#converting-an-instance-group-to-use-spot-instances

Follow the normal procedure for reconfiguring an InstanceGroup, but set the maxPrice property to your bid. For example, "0.10" represents a spot-price bid of $0.10 (10 cents) per hour.

So after kops create cluster but before kops update cluster --yes run kops edit ig nodes --name $NAME and set maxPrice to your max bid.

metadata:
  creationTimestamp: "2016-07-10T15:47:14Z"
  name: nodes
spec:
  machineType: t2.medium
  maxPrice: "0.01"
  maxSize: 3
  minSize: 3
  role: Node