<p>So Kubernetes has a pretty novel network model, that I believe is based on what it perceives to be a shortcoming with default Docker networking. While I'm still struggling to understand: (1) what it perceives the actual shortcoming(s) to be, and (2) what Kubernetes' general solution is, I'm now reaching a point where I'd like to just implement the solution and perhaps that will clue me in a little better.</p>

<p>Whereas the rest of the Kubernetes documentation is very mature and well-written, the instructions for configuring the network are sparse, largely incoherent, and span many disparate articles, instead of being located in one particular place.</p>

<p>I'm hoping someone who has set up a Kubernetes cluster before (from scratch) can help walk me through the basic procedures. I'm not interested in running on GCE or AWS, and for now I'm not interested in using any kind of overlay network like <code>flannel</code>.</p>

<p>My <em>basic</em> understanding is:</p>

<ol>
<li>Carve out a <code>/16</code> subnet for all your pods. This will limit you to some 65K pods, which should be sufficient for most normal applications. All IPs in this subnet must be "public" and not inside of some traditionally-private (classful) range.</li>
<li>Create a <code>cbr0</code> bridge somewhere and make sure its persistent (<strong>but on what machine?</strong>)</li>
<li>Remove/disable the <code>MASQUERADE</code> rule installed by Docker.</li>
<li>Some how configure <code>iptables</code> routes (again, <strong>where?</strong>) so that each pod spun up by Kubernetes receives one of those public IPs.</li>
<li>Some other setup is required to make use of load balanced <code>Services</code> and dynamic DNS.</li>
<li>Provision 5 VMs: 1 master, 4 minions</li>
<li>Install/configure Docker on all 5 VMs</li>
<li>Install/configure <code>kubectl</code>, <code>controller-manager</code>, <code>apiserver</code> and <code>etcd</code> to the master, and run them as services/daemons</li>
<li>Install/configure <code>kubelet</code> and <code>kube-proxy</code> on each minion and run them as services/daemons</li>
</ol>

<p>This is the best I can collect from 2 full days of research, and they are likely wrong (or misdirected), out of order, and utterly incomplete.</p>

<p>I have unbridled access to create VMs in an on-premise vCenter cluster. If changes need to be made to VLAN/Switches/etc. I can get infrastructure involved.</p>

<p><strong>How many VMs should I set up for Kubernetes (for a small-to-medium sized cluster), and why? What exact corrections do I need to make to my vague instructions above, so as to get networking totally configured?</strong></p>

<p>I'm good with installing/configuring all the binaries. Just totally choking on the network side of the setup.</p>

<p>For a general introduction into kubernetes networking, I found <a href="http://www.slideshare.net/enakai/architecture-overview-kubernetes-with-red-hat-enterprise-linux-71" rel="nofollow noreferrer">http://www.slideshare.net/enakai/architecture-overview-kubernetes-with-red-hat-enterprise-linux-71</a> pretty helpful.</p>

<p>On your items (1) and (2): IMHO they are nicely described in <a href="https://github.com/kubernetes/kubernetes/blob/master/docs/admin/networking.md#docker-model" rel="nofollow noreferrer">https://github.com/kubernetes/kubernetes/blob/master/docs/admin/networking.md#docker-model</a> . 
From my experience: What is the Problem with the Docker NAT type of approach? Sometimes you need to configure e.g. into the software all the endpoints of all nodes (172.168.10.1:8080, 172.168.10.2:8080, etc). in kubernetes you can simply configure the IP's of the pods into each others pod, Docker complicates it using NAT indirection. 
See also <a href="https://stackoverflow.com/questions/32852216/setting-up-the-network-for-kubernetes">Setting up the network for Kubernetes</a> for a nice answer.</p>

<p>Comments on your other points:
1. </p>

<blockquote>
  <p>All IPs in this subnet must be "public" and not inside of some traditionally-private (classful) range.</p>
</blockquote>

<p>The "internal network" of kubernetes normally uses private IP's, see also slides above, which uses 10.x.x.x as example. I guess confusion comes from some kubernetes texts that refer to "public" as "visible outside of the node", but they do not mean "Internet Public IP Address Range". </p>
