「这是我参与2022首次更文挑战的第12天，活动详情查看：2022首次更文挑战」

一. k8s的网络模型

　　k8s的网络模型假定了所有的Pod都在一个可以直接连通的扁平的网络空间中, 这在GCE(Google Compute Engine)里面是线程的网络模型, Kubernetes假定这个网络已经存在. 而在私有云里搭建Kubernetes集群, 就不能假定这个网络已经存在了. 我们需要自己实现这个网络假设, 将不同节点上的Docker容器之间的互相访问先打通, 然后运行Kubernetes.

　　这段话是什么意思呢? 用大白话来翻译一下

　　k8s默认所有pod都在一个扁平化的网络中, 也就是pod之间都是可以通过localhost相互访问的. 比如,我们现在办公都提倡扁平化管理,从工位的体现就是, 领导和员工们都坐在一起, 你也分不出来谁是领导,谁是员工. 相互之间, 随时沟通, 随时交流, 无障碍. 

　　而现实网络中, 我们都是用的阿里云, 在阿里云上搭建集群, 集群之间就不是扁平化的. 需要设置实现. 所以, 运行k8s, 第一步, 我们要设置网络之间可以相互连通, "直接到达". 这里的"直接到达"加了双引号, Pod认为我是直接到达的,其实底层, 有一堆转换机制存在, 比如Flannel的转换机制

 　  如果, 我们想要在自己的集群中构建k8s, 首先要解决扁平化的网络空间, 如果现在没有开原方案的话, 这一点是比较难做到的. 原因是, 我们需要将集群中的每一个Pod容器打通. 好在现在已经有很多公司加入k8s一起研究, 比如后面我们将要学习的Flannel, 他可以帮我们实现扁平的网络空间

二. 通讯类型 

2.1. 同一个Pod内的多个容器之间: 通过IO访问 

一个Pod里面有很多容器, 容器和容器之间访问, 他们走的是谁呢?

只要是同一个Pod, 他们在容器内共享PAUSE, 因此他们用 PAUSE容器网络栈, 他们之间互相访问, 走的是网络栈的IO, 通过localhost的方式就可以直接访问.

2.2. Pod与Service之间的通讯: 各节点的Iptables规则

 pod和service之间的通讯, 通过各节点的iptables规则, 进行转化. 在最新版本中, 已经加入了LVS的机制, 为他进行转发,转发效率更高, 上限更高

2.3. 各Pod之间的通讯, 使用的是Overlay Network

 Overlay Network是全覆盖网络. 这是我们要重点研究的对象.  

Overlay 网络到底是怎样实现的呢? 以及他们之间经历了哪些转换机制? 下面研究