「网络拓扑」Kubernetes 网络模型来龙去脉 |设计|Mac电脑|Docker|

本文插图
容器网络发端于 Docker 的网络。 Docker 使用了一个比较简单的网络模型，即内部的网桥加内部的保留 IP 。这种设计的好处在于容器的网络和外部世界是解耦的，无需占用宿主机的 IP 或者宿主机的资源，完全是虚拟的。
它的设计初衷是：当需要访问外部世界时，会采用 SNAT 这种方法来借用 Node 的 IP 去访问外面的服务。比如容器需要对外提供服务的时候，所用的是 DNAT 技术，也就是在 Node 上开一个端口，然后通过 iptable 或者别的某些机制，把流导入到容器的进程上以达到目的。
该模型的问题在于，外部网络无法区分哪些是容器的网络与流量、哪些是宿主机的网络与流量。比如，如果要做一个高可用的时候， 172.16.1.1 和 172.16.1.2 是拥有同样功能的两个容器，此时我们需要将两者绑成一个 Group 对外提供服务，而这个时候我们发现从外部看来两者没有相同之处，它们的 IP 都是借用宿主机的端口，因此很难将两者归拢到一起。

本文插图
在此基础上， Kubernetes 提出了这样一种机制：即每一个 Pod ，也就是一个功能聚集小团伙应有自己的“身份证” ，或者说 ID 。在 TCP 协议栈上，这个 ID 就是 IP 。
这个 IP 是真正属于该 Pod 的，外部世界不管通过什么方法一定要给它。对这个 Pod IP 的访问就是真正对它的服务的访问，中间拒绝任何的变造。比如以 10.1.1.1 的 IP 去访问 10.1.2.1 的 Pod ，结果到了 10.1.2.1 上发现，它实际上借用的是宿主机的 IP ，而不是源 IP ，这样是不被允许的。 Pod 内部会要求共享这个 IP ，从而解决了一些功能内聚的容器如何变成一个部署的原子的问题。
剩下的问题是我们的部署手段。 Kubernetes 对怎么实现这个模型其实是没有什么限制的，用 underlay 网络来控制外部路由器进行导流是可以的；如果希望解耦，用 overlay 网络在底层网络之上再加一层叠加网，这样也是可以的。总之，只要达到模型所要求的目的即可。
Pod 究竟如何上网
容器网络的网络包究竟是怎么传送的？

本文插图
我们可以从以下两个维度来看：

协议层次
网络拓扑

1. 协议层次它和 TCP 协议栈的概念是相同的，需要从两层、三层、四层一层层地摞上去，发包的时候从右往左，即先有应用数据，然后发到了 TCP 或者 UDP 的四层协议，继续向下传送，加上 IP 头，再加上 MAC 头就可以送出去了。收包的时候则按照相反的顺序，首先剥离 MAC 的头，再剥离 IP 的头，最后通过协议号在端口找到需要接收的进程。
2. 网络拓扑一个容器的包所要解决的问题分为两步：第一步，如何从容器的空间 (c1) 跳到宿主机的空间 (infra)；第二步，如何从宿主机空间到达远端。
我个人的理解是，容器网络的方案可以通过接入、流控、通道这三个层面来考虑。