Document the rationale for not having a master_nodeport_ingress and how to open traffic to masters manually

[jlamillan]

One consequence of running kube-proxy on the masters and making masters nodes is that masters will open up nodeports for exposed services.

We support the worker_nodeport_ingress input variable, but we don't have a master_nodeport_ingress. Masters have their own separate security list, which is more restricted.

On one hand, we'd like to avoid opening a port range on the control plane just to for the convenience of re-routing application traffic through the masters subnet to the workers. On the other hand, the user can choose to remove the NoSchedule taint, or deploy something that has a taint toleration that they want to run on the master node(s). Without a master_nodeport_ingress, they'll need to explicitly open up traffic on the masters (separate) security list on their own.

We should document this on the input-variables page. Also, feedback is welcome here.