镜子 - 或许我们也和 Pod 一样生活在虚拟世界

前两篇文章每篇大约在 4000 字左右，有小伙伴给我提建议：内容太长，无耐时间太碎，想读完却有心无力。这绝对是我的锅。于是我将 Network Policy 这个大的主题切分成几个部分，今天这篇是第一部分，剩下的再分两次推送。

上一篇在描述 K8s 网络模型的时候，聊到一个重要的概念：宿主机网络和 K8s 网络之间的区别。限于篇幅，当时快速带过，但我觉得这个概念需要拿出来再聊聊。

聊透它们之间的关系也就能比较好地理解为什么 K8s 要用 Network Policy 来解决“隔离”这个重要的问题。

宿主机网络

宿主机网络是拓扑型的，拓扑型结构有很多种，如星型结构、环型结构、总线结构、树型结构、网状结构、蜂窝状结构以及混合型结构等。下面这张图是数据中心树型拓扑图，放在这里给你感受下。图中最下面一层是服务器，它们通过接入层（Access Layer）组成各个可用区（Available Zone）；汇聚层（Aggregation Layer）将更多的可用区互联互通，且将它们都放置于一个广播域里面，俗称大二层；多个大二层之间通过核心交换机连接。

一个 K8s 集群可能由成百上千的服务器组成，所以自然地，这些宿主服务器之间通过二层或三层网络连通。

怎么样，是不是隔着屏幕都能感受到它的张扬、疯狂与复杂？

图：数据中心树型拓扑图

南北流量和东西流量

图 2：南北流量和东西流量示意图

数据中心树型拓扑图是一个典型的包含接入层、汇聚层、核心层三层的网络结构。这种结构诞生之初就是为了将外部流量引流到内部应用。

流量从外部穿过防火墙或者数据中心其它外围网络设备进来，对应到上⾯这张图里，流动方向为从上到下，称为南向流量（和地图一样，上北下南），而与之对应的，数据中心内部产生的，离开数据中心的流量，从下到上故称为北向流量。合起来称为南北流量。

在微服务化流行之前，以巨石系统（monolithic）这种单体应用为单位部署的方式，产生的是典型的南北流量。一个单体应用配有一个专门的服务器（或虚拟机），一个外部请求通常在单体应用内独立完成，除了访问数据库等必须依赖服务之外，很少会发生横向的流量。

但云计算机、大数据、微服务、云原生等技术的发展催生了大量的从左到右以及从右到左的流量，也被称为东西流量。

数据中心内部南北流量的削弱，而东西流量的井喷在硬件上要求数据中心要横向扩展以提供更宽的大二层以及容纳更多的服务器，而在软件上则要求一种新的服务编排方式以便能充分挖掘、利用现有的计算能力，从这个角度看 K8s 的出现是一种必然。

K8s 网络

相比之下，K8s 网络就简单了许多，它是扁平的大平层，所有的 Pod 聚在一起，就跟 1-6 年级的小学生全部集中在平坦的操场上做早操一样。

Pod 所使用的的 IPv4 地址一般由 K8s 的 CNI 插件（如 Calico, Cilium）从 RFC1918 规定的私有地址块分配，因此容器的 traffic 无法在 internet 上路由。RFC 1918 定义了如下所列的私有地址块:

• 10.0.0.0/8 (10.0.0.0 - 10.255.255.255)

• 172.16.0.0/12 (172.16.0.0 - 172.31.255.255)

• 192.168.0.0/16 (192.168.0.0 - 192.168.255.255)

二哥是个严谨（且有趣）的人，这里得再强调下，虽说 K8s 的网络是扁平的，但这种扁平是虚拟出来的。从 Pod 和容器的视角看，它是一个扁平的网络，可是它们又怎么可能会晓得外面的世界却是那么的复杂、雄伟和壮观。在 K8s 的精心设计和呵护下，容器们会觉得它们彼此之间通信如此的简单，可是它们又怎么会知道每一次 say hello 都可能包装千次万遍，走过千山万水。

写到这里，突然想起来在学术界，一直有一种观点，那就是我们人类生活的这个世界，乃至整个宇宙，可能都是被某个更智慧的物体模拟出来的虚拟世界。嗯，或许我们也和这些 Pod 还有容器一样，活在虚幻的、被别人定义的世界里。想到这里，我将本文的标题取名为"镜子"，来自大刘的短篇科幻小说《镜子》。

下面这张图突出了 K8s 网络的扁平的特点，与此同时，它将宿主机的网络结构抽象成二层或三层可达的结构。而实际上节点之间的连接如图 1 所示。

云计算如火如荼，如今业界习惯将 Virtual machines, databases, containers, Hadoop nodes 以及 applications 等统称为 cloud workloads。相应地，K8s 网络里面产生的流量叫做 workload traffic。图中还特意标出了 workload traffic 离开 K8s 网络进入宿主机网络的关键点。K8s 网络和宿主机网络之间是有明显的边界存在的，在上一篇文章中，我们用德国火箭科学家桑格尔提出的再入弹跳式弹道做了比喻，以表示当容器在跨 Node 间通信时，workload traffic 其实是会在这两个环境间来回穿梭跳跃。

图 3：K8s 扁平网络模型

如果我们把出入 K8s 集群的 traffic(以太帧)看成是导弹，把 K8s 网络看成大气层，而把宿主机网络看成太空的话，那么这个以太帧的流动轨迹就和桑格尔提出的再入弹跳式弹道有点类似。

图 4：钱学森—桑格尔弹道

趣谈新问题

我们来拿现实中的例子做个类比。一家从事软件外包的公司所在 Office 是一幢四层办公楼。一层是行政和财务，二层是人事，三层是研发部门，四层是测试部门。各个楼层都装有人脸识别门禁系统。各楼层之间就像是相互隔离的二层局域网，而门禁系统是各个楼层的网关和安全防火墙，RD 要去找 QA 讨论问题，他得离开三层，并经过人脸识别后进入四层办公场所。

这样的楼层安排看起来清清楚楚，井然有序。按照职能部门分楼层办公的好处显而易见：便于管理，本部门内的讨论事项不会被其他部门的人听到。

但它有一个问题，该公司 70%的员工是研发和测试，这就导致三层和四层非常拥挤，而一、二层却空了不少工位。老板灵机一动，何不把大家打散了混坐？

于是新的工位安排方法出现了：研发、测试部门均以小的项目组为单位，分散到四个楼层，充分利用各楼层的工位。

新方法不错，工位不挤了，大家工作起来心情舒畅，效率也高了许多。

但时间长了，老板发现一个新的问题：小王隔壁的工位是人事和财务，他总是能听到一些他本不该听到的事情，比如小李今年表现不错，准备给他加薪 10%；公司账面资金又发不出工资了。

这个问题该怎么解决呢？K8s 解决这个问题的方法是 Network Policy。欲知此事，且听下回分解。

以上就是本文的全部内容。码字不易，更多内容请关注二哥的微信公众号。您的举手之劳是对二哥莫大的鼓励。感谢有你！