主机内组网

k8s主机内组网模型是veth pair+bridge的方式。
k8s使用veth pair将容器与主机的网络协议栈连接起来，从而使数据包可以进出pod。容器放在主机根network namespace中，veth pair的一端连接到linux网桥，可以让同一节点上的各pod之间相互通信。

跨节点组网

k8s跨节点组网模型有bridge、overlay等。
bridge网络本身不解决容器的跨节点通信，而是添加主机路由表，映射目标容器网段和主机IP的关系，集群内如果有N个主机，则需要N-1条路由项。
overlay网络构建在物理网络上的虚拟网络，VXLAN是主流的overlay标准。VXLAN是用UDP包头封装二层帧，即所谓的MAC in UDP。
为了让多个Pod的网络命名空间链接起来，可以让veth对的一端链接到root网络命名空间（宿主机的），另一端链接到Pod的网络命名空间。还需要Linux以太网桥，它是虚拟的二层网络设备，把多个以太网段连接起来，它维护转发表，通过查看每个设备mac地址决定转发，还是丢弃数据。

跨节点通信

隧道方案（ Overlay Networking ）

隧道方案在IaaS层的网络中应用也比较多，但随着节点规模的增长，复杂度会提升，而且跟踪网络问题比较麻烦。
Weave：UDP广播，本机建立新的BR，通过PCAP互通。
Open vSwitch（OVS）：基于VxLan和GRE协议，但是性能方面损失比较严重。
Flannel：UDP广播，VxLan。

overlay网络是指在不改变现有网络基础设施的前提下，通过额外的网络协议，把二层报文封装在IP报文之上的新的数据格式，形成逻辑上的新网络。这样不但能够充分利用成熟的ip路由协议进行数据分发，而且在overlay技术中采用扩展的隔离标识位数，能够突破vlan的4000数量限制，支持高达16M的用户，并且在必要时将广播流量转化为组播流量，避免广播数据泛滥。

flannel插件
flannel为每个主机的docker deamon分配一个ip段，通过etcd维护一个跨主机的路由表，容器之间的ip是可以互相连通的，当两个跨主机的容器要通信的时候，会在主机上修改数据包的header，修改目的地址和源地址，经过路由表发送到目标主机后解封。封包的方式，支持udp/vxlan/host-gw等，但是如果一个容器要暴露服务，还是需要映射ip到主机侧。

路由方案

一般是从3层或者2层实现隔离和跨主机容器互通的，出了问题也容易排查。
Calico：基于BGP协议的路由方案，支持细粒度的ACL控制，对混合云亲和度比较高。
Macvlan：从逻辑和Kernel层来看隔离性和性能最优的方案，基于二层隔离，所以需要二层路由器支持，大多数云服务商不支持，所以混合云上较难实现。

calico插件
Calico是基于BGP的纯三层的网络方案。Calico可以应用在虚拟机，物理机，容器环境中。在Calico运行的主机上可以看到大量由linux路由组成的路由表，这是calico通过自有组件动态生成和管理的。但BGP带给它的好处的同时也带给他的劣势，BGP协议在企业内部还很少被接受，企业网管不太愿意在跨网络的路由器上开启BGP协议。
基于BGP的纯三层的网络方案。Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通。Calico节点组网可以直接利用数据中心的网络结构（L2或L3），不需要额外的NAT、隧道或者overlay network，没有额外的封包解包，节约CPU运算且提高网络效率。容器的IP可以直接对外部访问，可以直接分配到业务IP，而且如果网络设备支持BGP的话，可以用它实现大规模的容器网络。
calico插件可提供pod固定ip的解决方案。

三层（路由）和隧道的异同

相同之处是都实现了跨主机容器的三层互通，都是通过对目的 MAC 地址的操作来实现的。
不同之处是三层通过配置下一条主机的路由规则来实现互通，隧道是通过通过在 IP 包外再封装一层 MAC 包头来实现。
三层的优点：少了封包和解包的过程，性能更高。
三层的缺点：需要自己维护路由规则。
隧道的优点：简单，原因是大部分工作都是已由 Linux 内核的模块实现，应用层工作量较少。
隧道的缺点：性能低。

CNI

在k8s平台上，通过CNI插件的方式部署容器网络。
Container Networking Interface（CNI）定义的是容器运行环境与网络插件之间的接口规范，仅关心容器创建时的网络配置和容器被销毁时网络资源的释放。容器可以通过绑定多个CNI插件加入多个网络中。
与CRI之于k8s的runtime类似。CNI是pod网络的标准接口，通过JSON描述容器网络配置，是k8s与底层网络插件之间的抽象层。
要使用CNI网络驱动则需要配置参数--network-plugin=cni。k8s从--cni-conf-dir（默认为/etc/cni/net.d）中读取文件的CNI配置来配置每个pod网络。CNI插件二进制文件的目录通过kubelet的--cni-bin-dir参数配置（默认为/otp/cni/bin）。
CNI从v1.11版本开始支持控制pod的带宽。

网络互通

• pod到pod， 三层网络的连通。 通过CNI实现。
• pod到service， 四层负载均衡器。 通过kube-proxy实现。
• pod到k8s外， 通过SNAT实现。
• 主机到pod，

IP转发

内核态设置，允许将一个接口的流量转发到另一个接口。该配置是linux内核将流量从容器路由到外部所必须的。ipv4 forwarding。

桥接

k8s通过bridge-netfilter配置使iptables规则应用到linux网桥上。该配置对linux内核进行宿主机和容器之间数据包的地址转换是必须的。否则pod进行外部服务网络请求时会出现目标主机不可达或者连接拒绝的错误。

tips

“单pod单ip”网络模型。实现k8s扁平化网络。容器之间直接通信，不需要额外NAT。node与容器网络直连，不需要额外NAT。
扁平化网络的优点：没有NAT带来的性能损耗，可以追溯源地址，为网络策略做铺垫，降低网络排错难度。

pod中docker容器和pod在同一个网络命名空间内，所以ip和端口等网络配置都和pod一样，是docker的网络模式是container，即和已经存在的容器（pause容器）共享网络。

参考

• 《Kubernetes 权威指南》
• 《Kubernetes 网络权威指南》
• k8s网络--竹径风声