If you want the master to be removed from scheduling a pod, and if you are using Kubernetes 1.7 or above you can use following command.

kubectl taint node yourMasterNode node-role.kubernetes.io/master:NoSchedule-

You can't expose a node it's a VM or bare-metal machine which already has a ip-address and exposed. what you want to do is to use a service to expose a pod to the outside the cluster. You can use Kubernets Services for that. For this testing scenario you can use a NodePort to expose your pod to outside. If you use NodePort, then you can use {your-any-node-ip}:{nodePort} to access it from outside the cluster. You may need to have a static public ip if you want to access it from internet.

But if you are concern about the availability of the pods you can use multi-node cluster and then use replicas of the pods so they can be scheduled on multiple nodes. Then whenever the a pod in the other nodes can continue servicing while a new pod is scheduled somewhere else. That's how you can have 100% availability in Kubernetes.

As you concern about the master being down. If the master is down apps will continue to serve and nodes will be rather ad-hoc nodes than a cluster. Unless a node restart or app fails it will serve okay. But the cluster will not be able to respond to node failures, create new resources, move pods to new nodes, etc. Until the master is back online. So if there a high chance of master being failed you can simply use multiple masters in your cluster.

You seem to be inclined towards NodePort Services so I guess you are not using a cloud provider (as with a cloud provider you could use LoadBalancer).

Since you have multiple Nodes you then need to choose which to expose externally and how. You could put an external Load Balancer in front of the cluster so that load is balanced between nodes. That won't be part of the cluster so would have to be configured separately to know which IPs/nodes to route to.

Or you can consider using a single node for routing. The node would only be sending on traffic using the kube-proxy without going into the app content (L4 not L7) so it can route without a lot of processing, which helps to mitigate the risk of it becoming unavailable. But it would still be only a single node and depending on its hardware there would be a risk it could go down for other reasons. So there are tradeoffs to be made when deciding what setup for exposing externally is best for your cluster - you need to choose whether you want to maintain a load balancer in addition to the cluster and whether it would be more reliable than using a node.