sme*_*eeb 2 networking subnet docker kubernetes
我正在阅读Kubernetes" 从头开始入门 "指南并已到达可怕的网络部分,他们声明:
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
Run Code Online (Sandbox Code Playgroud)
我的第一个困惑来源是:这与"标准"Docker模型有何不同?Docker与3个Kubernetes的要求有何不同?
然后,本文接着总结了GCE如何实现这些要求:
对于Google Compute Engine群集配置脚本,我们使用高级路由为每个VM分配一个子网(默认为/ 24 - 254个IP).绑定到该子网的任何流量都将由GCE网络结构直接路由到VM.这是分配给VM的"主"IP地址的补充,该NAT地址用于出站互联网访问.Linux网桥(称为cbr0)配置为存在于该子网上,并传递给docker的--bridge标志.
我的问题是:本段所涉及的上述3中的哪些要求?更重要的是,它如何达到要求?我想我只是不明白每个VM的1个子网是如何完成的:容器 - 容器通信,节点 - 容器通信和静态IP.
并且,作为奖励/延伸问题:为什么马拉松不会遭遇与Kubernetes在此处讨论的相同的网络问题?
Docker的标准网络配置为您选择的容器子网超出其选择的默认值.只要它不与主机上的任何接口冲突,Docker就可以了.
然后,Docker插入一个iptables MASQUERADE规则,允许容器使用主机的默认接口与外部世界通信.
仅根据主机上使用的地址选择子网这一事实违反了Kubernetes的3个要求,这迫使要求使用MASQUERADE规则对所有容器流量进行NAT.
考虑以下3主机Docker设置(有点人为设计突出显示):
eth0:10.1.2.3
docker0:172.17.42.1/16
container-A:172.17.42.2
eth0:10.1.2.4
docker0:172.17.42.1/16
container-B:172.17.42.2
eth0:172.17.42.2
docker0:172.18.42.1
假设container-B想要访问容器-A的端口80上的HTTP服务.您可以让docker 在Host 1上的某处暴露容器A的端口80 .然后container-B可能会向10.1.2.3:43210发出请求.这将在容器A的端口80上接收,但看起来它来自10.1.2.4上的一些随机端口,因为在离开主机2的路上有NAT .这违反了所有容器在没有NAT的情况下进行通信,并且容器看到的IP与其他要求相同.尝试直接从主机2访问容器A的服务,你得到你的节点可以与容器通信而不会发生NAT违规.
现在,如果这些容器中的任何一个想与主机3通话,它们就是SOL(只是小心自动分配的docker0子网的一般参数).
GCE/AWS/Flannel/...上的Kubernetes方法是为每个主机VM 分配一个由扁平专用网络构成的子网.没有子网与VM地址或彼此重叠.这使容器和VM可以无连接地进行通信.
| 归档时间: |
|
| 查看次数: |
2261 次 |
| 最近记录: |