Kubernetes网络模型理论深入剖析(一)-Kubernetes商业环境实战

1,115 阅读7分钟

专注于大数据及容器云核心技术解密,可提供全栈的大数据+云原生平台咨询方案,请持续关注本套博客。如有任何学术交流,可随时联系。更多内容请关注《数据云技术社区》公众号,或请转发邮件至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。