我正在阅读Kubernetes "Getting Started from Scratch" Guide，并且已经到达可怕的Network Section，他们声明：
Kubernetes imposes the following fundamental requirements on any networking implementation
(barring any intentional network segmentation policies):
* all containers can communicate with all other containers without NAT
* all nodes can communicate with all containers (and vice-versa) without NAT
* the IP that a container sees itself as is the same IP that others see it as
我的第一个混淆来源是：这个与<34>标准＆＃34>有什么不同？ Docker模型？ Docker如何与w.r.t不同那3个Kubernetes要求？
接着，文章总结了GCE如何实现这些要求：
对于Google Compute Engine群集配置脚本，我们使用高级路由为每个VM分配一个子网（默认为/ 24 - 254个IP）。绑定到该子网的任何流量都将由GCE网络结构直接路由到VM。这是＆＃34; main＆＃34;分配给VM的IP地址，用于出站Internet访问的NAT。 linux网桥（称为cbr0）配置为存在于该子网上，并传递给docker的--bridge标志。
我的问题是：本段所述的上述3中的哪些要求？更重要的是， 如何实现这些要求？我想我只是不了解每个VM的1个子网如何实现：容器 - 容器通信，节点 - 集装箱通信和静态IP。
而且，作为一个奖励/拉伸问题：为什么马拉松没有遭受与Kubernetes在这里讨论的相同的网络问题？
答案 0 :(得分：7)
Docker的标准networking configuration从chosen defaults中为您选择一个容器子网。只要它不与主机上的任何接口冲突，Docker就可以了。
然后，Docker插入一个iptables MASQUERADE规则，允许容器使用主机的默认界面与外部世界通信。
Kubernetes的3个要求违反了以下事实：仅根据主机上使用的地址选择子网，这迫使要求使用MASQUERADE规则对所有容器流量进行NAT。
考虑以下3主机Docker设置（稍微设计一下以突出显示内容）：
eth0 ：10.1.2.3
docker0 ：172.17.42.1/16
容器-A ：172.17.42.2
eth0 ：10.1.2.4
docker0 ：172.17.42.1/16
容器-B ：172.17.42.2
eth0 ：172.17.42.2
docker0 ：172.18.42.1
假设 container-B 想要访问 container-A 的端口80上的HTTP服务。您可以让docker在主机1 上的某处公开 container-A 的端口80。然后 container-B 可能会向10.1.2.3:43210发出请求。这将在 container-A 的端口80上收到，但看起来它来自10.1.2.4上的一些随机端口，因为NAT出了 Host 2 。这违反了所有容器在没有NAT的情况下进行通信并且容器看到的IP与其他要求相同。尝试直接从主机2 访问 container-A 的服务，您的节点可以与没有NAT 违规的容器进行通信。
现在，如果这些容器中的任何一个想要与主机3 通信，那么它们就是SOL（只是小心自动分配的docker0子网的一般参数）。
KCEnetes在GCE / AWS / Flannel / ...上的方法是assign每个主机VM由一个扁平专用网络构成的子网。没有子网与VM地址或彼此重叠。这使得容器和虚拟机可以无连接地进行通信。