运维开发网

k8s--Flannel的

运维开发网 https://www.qedev.com 2021-03-01 09:19 出处:51CTO 作者:paniho
导言对 docker 略有所知的人应该了解,docker ip 是仅存在于宿主机的 nampaces 中,在真实的物理网络中是不配有拥有地位的, 即不存在对应的路由和 mac 地址的,因此就无法进行数据包的转发和路由, 这就造成了分属于不同宿主机上的 docker 无法通信的难题聪明如你可能想到利用 nat 端口映射的方式解决;在服务器数量不多的简单场景下,我们确实可以这样做,一顿操作,将 doc

对 docker有使用经验的人应该了解,docker的网络栈 被"困在了"本地的namspace中,从而导致了跨机器docker间网络无法通信的问题,那么k8s是如何解决这个问题的呢?

pod网络模型

k8s架构并没有亲自去实现解决方案,而是提出了解决方案必须满足的需求:

  • Pod 之间无需设置 NAT 即可实现相互的网络通讯
  • 每个 Pod 都会看到自己和其他 Pod 一样可看到自身的 IP 地址
  • 运行 Kubernetes 集群的节点,可支持物理机或者虚拟机,或任何支持运行 Kubernetes 的环境,这些节点也可无需设置 NAT,便可实现同其他 Pod 节点的相互通讯。

换言之,k8s 要实现的是扁平的网络,容器不需要借助宿主机的 ip,只需自身 ip 也能实现相互通信。

目前业界普遍使用的方案有 Flannel、Calico、Weave 和 Canal,在实现原理以及流行度上,最有代表的当属 flannel 和 calico

  • Flannel

    通过二层 overlay 实现,让 docker 数据包在 overlay 隧道中传输

  • calico

    将每台宿主机都当成一个路由器,构建一个 BGP 网络,docker 数据通过三层路由转发

以下将会尝试分析 Flannel 架构原理

Flannel 是 CoreOs 公司 为 K8s 设计的通过 Overlay Network 方式实现的架构,所谓的 overlay, 其实就是 tcp 的嵌套,在 tcp 协议中再封装一层 tcp/udp 协议,下图便是 vxlan overlay 包格式

k8s--Flannel的

依据封装协议的不同,flannel 还可以分为多种 backend

  • udp

    udp 模式的解封装是在用户态进行的,比较耗费性能

  • host-gw

    只适用于同一二层网络,无法跨越三层

  • vxlan

    vxlan 解封装在内核态进行,性能高,能跨域三层

Flannel vxlan 模式的组件主要包括 ectd、Flanneld 等

组件

ETCD

细心的你可能会发现 docker 分配到的网段是 172.17.0.0/16, 再启一台宿主机,你发现 docker 分配到的还是同样的网段,那 docker ip 岂不会存在重复的可能?这时就需要一个中心节点来保证 docker ip 的全局唯一性,etcd 担当的正是这样一个角色,它存储着所有节点分配到的网段,当然,它其实只是 Flannel 元信息的搬运工,真正负责划分网段,注册上报 subnet vtep 等信息的是 Flanneld

Flanneld

flanned 作为 ectcd 的 agent 运行在宿主机节点上,主要有以下功能:

  • 从 etcd 中获取 network 的配置信息
  • 划分 subnet,并在 etcd 中进行注册
  • 将子网信息记录到宿主机的/run/flannel/subnet.env
[email protected]:~#  cat /run/flannel/subnet.envFLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=192.168.2.1/24
FLANNEL_MTU=8951
FLANNEL_IPMASQ=true
[email protected]:~$ cat /run/flannel/subnet.envFLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=192.168.1.1/24
FLANNEL_MTU=8951
FLANNEL_IPMASQ=true

如上所示,两个节点分配到了不同的 subnet, 这些信息会上报到 ectcd, 并被注入到 docker 启动参数中,从而保证了 docker ip 的集群唯一性

vxlan 封装流程

ip 已经唯一了,那么跨节点的 docker 究竟是如何通信的?预知底层原理,还需举个栗子

便于理解, 基于 vxlan 模式分析下 跨节点 docker 192.168.1.4 —> 192.168.2.2 间的数据转发流程

k8s--Flannel的

1. 数据一开始从 ip 为 192.168.1.4 的 docker 出发,根据路由表,目的地址为 192.168.2.2 的数据包匹配到了默认路由, 于是报文从容器的 eth0 网络接口发送出去

[email protected]:/etc/cni/net.d# docker exec bd69 ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever3: [email protected]: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 8951 qdisc noqueue state UP
    link/ether 96:53:14:4a:4e:bd brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.4/24 scope global eth0
       valid_lft forever preferred_lft forever
[email protected]:/etc/cni/net.d# docker exec bd69 ip route
default via 192.168.1.1 dev eth01
0.244.0.0/16 via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.4

2. 从 docker 出来的数据会发送到哪里? 理论上,docker 和宿主机位于两个不同的网络 namespace 中,网络是不通的,但是,vethpair 的出现,让情况不一样了,vethpari 是连接两个 namespaces 的”网线”,串联起 docker eth0 接口和宿主机的 cni0 接口,于是数据包会被再次转发到宿主机的 cni0

3. 宿主机上的路由表,有一条目的地址为 192.168.2.0/24 的路由,于是颠沛流离的目标数据包又再次被转发到 flannel.1 端口

[email protected]:/etc/cni/net.d# ip route
default via 172.25.32.1 dev eth0
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown
172.25.32.0/20 dev eth0  proto kernel  scope link  src 172.25.33.13
192.168.0.0/24 via 192.168.0.0 dev flannel.1 onlink
192.168.1.0/24 dev cni0  proto kernel  scope link  src 192.168.1.1
192.168.2.0/24 via 192.168.2.0 dev flannel.1 onlink

4.flannel.1 是一个虚拟 VTEP(Vxlan tunnel endpoint) 设备,负责 vxlan 协议报文的封解包,一旦数据包发送到 flannel.1,就会进入 vxlan 协议的套路

当数据报文来到 flannel.1 时,需要根据 vxlan 协议封装数据包,此时的 dst ip 为 192.168.2.2,flannel.1 需要知道 192.168.2.2 对应的 mac 地址, 不同于传统的二层寻址,flannel.1 不会发送 arp 请求去获得 192.168.2.2 的 mac 地址,而是由 Linux kernel 将一个“L3 Miss”事件请求发送的用户空间的 flanned 程序。Flanned 程序收到内核的请求事件之后,从 etcd 查找能够匹配目标地址的子网的 flannel.1 设备的 mac 地址,即发往的 pod 所在 host 中 flannel.1 设备的 mac 地址, 这样,就形成了如下完整的 vxlan 内层数据封包格式

k8s--Flannel的

5. 按照 TCP 协议栈从上向下的封装工序,要形成完整的能够传输的数据帧,还需要目标 ip 和目标 mac 地址,那么这两者如何找寻呢?

对于目标 ip,flannel.1 根据对端 vtep 的 mac 地址,从 fdb(forwarding database) 中查找 mac 地址 26:1c:b0:2b:17:31 对应的 ip 地址,如下所示,该 mac 地址对应的 ip 为 172.25.34.198

[email protected]:~# bridge fdb show dev flannel.1
22:5b:16:5a:1b:fc dst 172.25.42.118 self permanent
26:1c:b0:2b:17:31 dst 172.25.34.198 self permanent

再通过 arp 协议即可找到 172.25.34.198 对应的 mac 地址,于是,一个完整的数据帧便呈现如下:

k8s--Flannel的

最终,目标 ip 为 172.25.34.198 目标端口为 8472 的数据帧便从宿主机的 eth0 端口发送出去

6. 数据帧通过二层网络顺利转发到达对端 172.25.34.198 宿主机的 8472 端口,此端口正是 Flanneld 的监听端口,Flanneld 解封 vxlan 数据包, 发现数据包目标 ip 为 192.168.2.2, 匹配系统明细路由,将数据包转发给了 cni0 端口

[email protected]:~# ip route
default via 172.25.32.1 dev eth0172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown
172.25.32.0/20 dev eth0  proto kernel  scope link  src 172.25.34.198
192.168.0.0/24 via 192.168.0.0 dev flannel.1 onlink
192.168.1.0/24 via 192.168.1.0 dev flannel.1 onlink
192.168.2.0/24 dev cni0  proto kernel  scope link  src 192.168.2.1

7. 前文提及,cni0 端口是与 docker namespace 直连的,于是通过 vethpair 将数据转发到了 docker192.168.2.1 中

历经千辛万苦,尝尽无数套路,数据包最终实现了跨主机 docke 间的通信

总结

Flanneld 和 ETCD 共同构筑了覆盖所有集群节点的 overlay 网络,使得 docker 之间能够在这层 "隧道" 中使用自己的 ip 相互通信。

扫码领视频副本.gif

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号