专注于大数据及容器云核心技术解密,可提供全栈的大数据+云原生平台咨询方案,请持续关注本套博客。如有任何学术交流,可随时联系。更多内容请关注《数据云技术社区》公众号,或请转发邮件至1120746959@qq.com。
1 Docker通信模型
1.1 Docker Host 网络模型
1.2 Docker Briage 网络模型
2 Kubernetes通信模型
- 在每个Kubernetes节点(本场景指的是Linux机器)上,都有一个根(root)命名空间(root是作为基准,而不是超级用户)--root netns,最主要的网络接口 eth0 就是在这个root netns下。
- 类似的,每个Pod都有其自身的netns,通过一个虚拟的以太网对连接到root netns。这基本上就是一个管道对,一端在root netns内,另一端在Pod的nens内。
- 节点上的所有Pod都会完成这个过程。这些Pod要相互通信,就要用到linux的以太网桥 cbr0 了。Docker使用了类似的网桥,称为docker0。
2.1 节点内通信原理
假设一个网络数据包要由pod1到pod2。- 它由pod1中netns的eth0网口离开,通过vethxxx进入root netns。
- 然后被传到cbr0,cbr0使用ARP请求,说“谁拥有这个IP”,从而发现目标地址。
- vethyyy说它有这个IP,因此网桥就知道了往哪里转发这个包。
- 数据包到达vethyyy,跨过管道对,到达pod2的netns。
2.2 节点间通信原理
- Pod也需要跨节点可达。Kubernetes不关心如何实现。我们可以使用L2(ARP跨节点),L3(IP路由跨节点,就像云提供商的路由表),Overlay网络,或者甚至信鸽。无所谓,只要流量能到达另一个节点的期望Pod就好。每个节点都为Pod IPs分配了唯一的CIDR块(一段IP地址范围),因此每个Pod都拥有唯一的IP,不会和其它节点上的Pod冲突。 假设一个数据包要从pod1到达pod4(在不同的节点上)。
- 它由pod1中netns的eth0网口离开,通过vethxxx进入root netns。
- 然后被传到cbr0,cbr0通过发送ARP请求来找到目标地址。
- 本节点上没有Pod拥有pod4的IP地址,因此数据包由cbr0 传到主网络接口 eth0。
- 数据包的源地址为pod1,目标地址为pod4,它以这种方式离开node1进入电缆。
- 路由表有每个节点的CIDR块的路由设定,它把数据包路由到CIDR块包含pod4的IP的节点。
- 因此数据包到达了node2的主网络接口eth0。现在即使pod4不是eth0的IP,数据包也仍然能转发到cbr0,因为节点配置了IP forwarding enabled。节点的路由表寻找任意能匹配pod4 IP的路由。它发现了 cbr0 是这个节点的CIDR块的目标地址。你可以用route -n命令列出该节点的路由表,它会显示cbr0的路由,类型如下:
- 网桥接收了数据包,发送ARP请求,发现目标IP属于vethyyy。
- 数据包跨过管道对到达pod4。
2.3 Overlay 网络-VXLAN端口(通常是8472)
- Overlay网络不是默认必须的,但是它们在特定场景下非常有用。比如当我们没有足够的IP空间,或者网络无法处理额外路由,抑或当我们需要Overlay提供的某些额外管理特性。一个常见的场景是当云提供商的路由表能处理的路由数是有限制时。例如,AWS路由表最多支持50条路由才不至于影响网络性能。因此如果我们有超过50个Kubernetes节点,AWS路由表将不够。这种情况下,使用Overlay网络将帮到我们。
- 尽管这个映射发生在用户空间,真实的封装以及数据的流动发生在内核空间,因此仍然是很快的。 从pod1到pod4(在不同节点)的数据包的流向类似如下:
- 1、它由pod1中netns的eth0网口离开,通过vethxxx进入root netns。
- 2、然后被传到cbr0,cbr0通过发送ARP请求来找到目标地址。
- 3a、由于本节点上没有Pod拥有pod4的IP地址,因此网桥把数据包发送给了flannel0,因为节点的路由表上flannel0被配成了Pod网段的目标地址。
- 3b、flanneld daemon和Kubernetes apiserver或者底层的etcd通信,它知道所有的Pod IP,并且知道它们在哪个节点上。因此Flannel创建了Pod IP和Node IP之间的映射(在用户空间)。 flannel0取到这个包,并在其上再用一个UDP包封装起来,该UDP包头部的源和目的IP分别被改成了对应节点的IP,然后发送这个新包到特定的VXLAN端口(通常是8472)。
- 3c、封装后的包通过eth0发送出去,因为它涉及了节点间的路由流量。
- 4、包带着节点IP信息作为源和目的地址离开本节点。
- 5、云提供商的路由表已经知道了如何在节点间发送报文,因此该报文被发送到目标地址node2。
- 6a、包到达node2的eth0网卡,由于目标端口是特定的VXLAN端口,内核将报文发送给了 flannel0。
- 6b、flannel0解封报文,并将其发送到 root 命名空间下。 从这里开始,报文的路径和我们之前在Part 1 中看到的非Overlay网络就是一致的了。
- 6c、由于IP forwarding开启着,内核按照路由表将报文转发给了cbr0。
- 7、网桥获取到了包,发送ARP请求,发现目标IP属于vethyyy。
- 8、包跨过管道对到达pod4。
3 网络模型架构图
3.1 Flannel UDP 模式
3.2 Flannel VXLAN 模式
3.3 Flannel Host-gw 模式
3.4 Calico模式
3.4.1 Calico基础理论
Calico是一个简单、可扩展和安全的三层数据中心网络架构,无需依托overlay网络。 Calico在每个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发,而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息向整个Calico网络内传播,小规模部署可以直接互联,大规模部署可通过指定的BGP route reflector来完成。Calico基于iptables还提供了丰富而灵活的网络Policy,保证通过各个节点上的ACLs来提供workload的多租户隔离、安全组以及其他可达性限制等功能。
集群规模小于50节点,无需开启typha模式 大于50节点需要开启typha模式(修改typha_service_name “none”改为“calico-typha”) calico-typha副本数规划,集群每添加200节点新增3个副本(3 < 副本数<20)3.4.2 Calico BGP 模式
3.4.3 Calico IPIP 模式
4 Kubernetes网络模式抓包分析
4.1 基本配置查看
- 4种通信
- 查看Kube-Pxoxy 配置
- 查看CNI配置
- 查看宿主机网络配置
4.2 网络抓包
4.2.1 Flannel默认VXLAN网络抓取
- 3个pod应用
- 进行测试
- 抓取cni0及flannel.1的流量
- 抓取宿主机ens32的流量
- 查看ip路由
4.2.2 Flannel Direct roting 模式网络抓取
- 热更新生效较慢,需要等待,不确定
- 上述没生效,换种网络切换方式
- 查看ip路由
5 总结
专注于大数据及容器云核心技术解密,可提供全栈的大数据+云原生平台咨询方案,请持续关注本套博客。如有任何学术交流,可随时联系。更多内容请关注《数据云技术社区》公众号,或请转发邮件至1120746959@qq.com。