How is High Availability Master selected?

The etcd database underneath is where most of the high availability comes from. It uses an implementation of the raft protocol for consensus. etcd requires a quorum of N/2 + 1 instances to be available for kubernetes to be able to write updates to the cluster. If you have less than 1/2 available, etcd will go into "read" only mode which means nothing new can be scheduled.

kube-apiserver will run on multiple nodes in active/active mode. All instances use the same etcd cluster so present the same data. The worker nodes will need some way to load balance / failover to the available apiservers. The failover requires a component outside of kubernetes, like HAProxy or a load balancer device (like AWS provides).

kube-scheduler will run on multiple master nodes and should access the local instance of kube-apiserver. The scheduler will elect a leader that locks the data it manages. The current leader information can be found in the endpoint:

kubectl -n kube-system get endpoints kube-scheduler \
  -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'

kube-controller-manager will run on multiple master nodes and should access the local instance of kube-apiserver. The controllers will elect a leader that locks the data it manages. Leader information can be found in the endpoint:

kubectl -n kube-system get endpoints kube-controller-manager \
 -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'

if the master goes down what happens to the worker nodes connected to it?

They continue running in their current state. No new pods will be scheduled and no changes to the existing state of the cluster will be pushed out. Your pods will continue to run until they fail in a way the local kubelet can't recover.