极客时间已完结课程限时免费阅读

35 | 解读Kubernetes三层网络方案

35 | 解读Kubernetes三层网络方案-极客时间

35 | 解读Kubernetes三层网络方案

2018-11-12 张磊 来自北京
《深入剖析Kubernetes》
课程介绍

讲述：张磊

时长19:30大小8.93M

你好，我是张磊。今天我和你分享的主题是：解读 Kubernetes 三层网络方案。
在上一篇文章中，我以网桥类型的 Flannel 插件为例，为你讲解了 Kubernetes 里容器网络和 CNI 插件的主要工作原理。不过，除了这种模式之外，还有一种纯三层（Pure Layer 3）网络方案非常值得你注意。其中的典型例子，莫过于 Flannel 的 host-gw 模式和 Calico 项目了。
我们先来看一下 Flannel 的 host-gw 模式。
它的工作原理非常简单，我用一张图就可以和你说清楚。为了方便叙述，接下来我会称这张图为“host-gw 示意图”。
图1 Flannel host-gw示意图
假设现在，Node 1 上的 Infra-container-1，要访问 Node 2 上的 Infra-container-2。
当你设置 Flannel 使用 host-gw 模式之后，flanneld 会在宿主机上创建这样一条规则，以 Node 1 为例：
$ ip route
...
10.244.1.0/24 via 10.168.0.3 dev eth0
这条路由规则的含义是：目的 IP 地址属于 10.244.1.0/24 网段的 IP 包，应该经过本机的 eth0 设备发出去（即：dev eth0）；并且，它下一跳地址（next-hop）是 10.168.0.3（即：via 10.168.0.3）。
所谓下一跳地址就是：如果 IP 包从主机 A 发到主机 B，需要经过路由设备 X 的中转。那么 X 的 IP 地址就应该配置为主机 A 的下一跳地址。
而从 host-gw 示意图中我们可以看到，这个下一跳地址对应的，正是我们的目的宿主机 Node 2。
一旦配置了下一跳地址，那么接下来，当 IP 包从网络层进入链路层封装成帧的时候，eth0 设备就会使用下一跳地址对应的 MAC 地址，作为该数据帧的目的 MAC 地址。显然，这个 MAC 地址，正是 Node 2 的 MAC 地址。
这样，这个数据帧就会从 Node 1 通过宿主机的二层网络顺利到达 Node 2 上。
而 Node 2 的内核网络栈从二层数据帧里拿到 IP 包后，会“看到”这个 IP 包的目的 IP 地址是 10.244.1.3，即 Infra-container-2 的 IP 地址。这时候，根据 Node 2 上的路由表，该目的地址会匹配到第二条路由规则（也就是 10.244.1.0 对应的路由规则），从而进入 cni0 网桥，进而进入到 Infra-container-2 当中。
可以看到，host-gw 模式的工作原理，其实就是将每个 Flannel 子网（Flannel Subnet，比如：10.244.1.0/24）的“下一跳”，设置成了该子网对应的宿主机的 IP 地址。
也就是说，这台“主机”（Host）会充当这条容器通信路径里的“网关”（Gateway）。这也正是“host-gw”的含义。
当然，Flannel 子网和主机的信息，都是保存在 Etcd 当中的。flanneld 只需要 WACTH 这些数据的变化，然后实时更新路由表即可。
注意：在 Kubernetes v1.7 之后，类似 Flannel、Calico 的 CNI 网络插件都是可以直接连接 Kubernetes 的 APIServer 来访问 Etcd 的，无需额外部署 Etcd 给它们使用。
而在这种模式下，容器通信的过程就免除了额外的封包和解包带来的性能损耗。根据实际的测试，host-gw 的性能损失大约在 10% 左右，而其他所有基于 VXLAN“隧道”机制的网络方案，性能损失都在 20%~30% 左右。
当然，通过上面的叙述，你也应该看到，host-gw 模式能够正常工作的核心，就在于 IP 包在封装成帧发送出去的时候，会使用路由表里的“下一跳”来设置目的 MAC 地址。这样，它就会经过二层网络到达目的宿主机。
所以说，Flannel host-gw 模式必须要求集群宿主机之间是二层连通的。
需要注意的是，宿主机之间二层不连通的情况也是广泛存在的。比如，宿主机分布在了不同的子网（VLAN）里。但是，在一个 Kubernetes 集群里，宿主机之间必须可以通过 IP 地址进行通信，也就是说至少是三层可达的。否则的话，你的集群将不满足上一篇文章中提到的宿主机之间 IP 互通的假设（Kubernetes 网络模型）。当然，“三层可达”也可以通过为几个子网设置三层转发来实现。
而在容器生态中，要说到像 Flannel host-gw 这样的三层网络方案，我们就不得不提到这个领域里的“龙头老大”Calico 项目了。
实际上，Calico 项目提供的网络解决方案，与 Flannel 的 host-gw 模式，几乎是完全一样的。也就是说，Calico 也会在每台宿主机上，添加一个格式如下所示的路由规则：
<目的容器IP地址段> via <网关的IP地址> dev eth0
其中，网关的 IP 地址，正是目的容器所在宿主机的 IP 地址。
而正如前所述，这个三层网络方案得以正常工作的核心，是为每个容器的 IP 地址，找到它所对应的、“下一跳”的网关。
不过，不同于 Flannel 通过 Etcd 和宿主机上的 flanneld 来维护路由信息的做法，Calico 项目使用了一个“重型武器”来自动地在整个集群中分发路由信息。
这个“重型武器”，就是 BGP。
BGP 的全称是 Border Gateway Protocol，即：边界网关协议。它是一个 Linux 内核原生就支持的、专门用在大规模数据中心里维护不同的“自治系统”之间路由信息的、无中心的路由协议。
这个概念可能听起来有点儿“吓人”，但实际上，我可以用一个非常简单的例子来为你讲清楚。
图2 自治系统
在这个图中，我们有两个自治系统（Autonomous System，简称为 AS）：AS 1 和 AS 2。而所谓的一个自治系统，指的是一个组织管辖下的所有 IP 网络和路由器的全体。你可以把它想象成一个小公司里的所有主机和路由器。在正常情况下，自治系统之间不会有任何“来往”。
但是，如果这样两个自治系统里的主机，要通过 IP 地址直接进行通信，我们就必须使用路由器把这两个自治系统连接起来。
比如，AS 1 里面的主机 10.10.0.2，要访问 AS 2 里面的主机 172.17.0.3 的话。它发出的 IP 包，就会先到达自治系统 AS 1 上的路由器 Router 1。
而在此时，Router 1 的路由表里，有这样一条规则，即：目的地址是 172.17.0.2 包，应该经过 Router 1 的 C 接口，发往网关 Router 2（即：自治系统 AS 2 上的路由器）。
所以 IP 包就会到达 Router 2 上，然后经过 Router 2 的路由表，从 B 接口出来到达目的主机 172.17.0.3。
但是反过来，如果主机 172.17.0.3 要访问 10.10.0.2，那么这个 IP 包，在到达 Router 2 之后，就不知道该去哪儿了。因为在 Router 2 的路由表里，并没有关于 AS 1 自治系统的任何路由规则。
所以这时候，网络管理员就应该给 Router 2 也添加一条路由规则，比如：目标地址是 10.10.0.2 的 IP 包，应该经过 Router 2 的 C 接口，发往网关 Router 1。
像上面这样负责把自治系统连接在一起的路由器，我们就把它形象地称为：边界网关。它跟普通路由器的不同之处在于，它的路由表里拥有其他自治系统里的主机路由信息。
上面的这部分原理，相信你理解起来应该很容易。毕竟，路由器这个设备本身的主要作用，就是连通不同的网络。
但是，你可以想象一下，假设我们现在的网络拓扑结构非常复杂，每个自治系统都有成千上万个主机、无数个路由器，甚至是由多个公司、多个网络提供商、多个自治系统组成的复合自治系统呢？
这时候，如果还要依靠人工来对边界网关的路由表进行配置和维护，那是绝对不现实的。
而这种情况下，BGP 大显身手的时刻就到了。
在使用了 BGP 之后，你可以认为，在每个边界网关上都会运行着一个小程序，它们会将各自的路由表信息，通过 TCP 传输给其他的边界网关。而其他边界网关上的这个小程序，则会对收到的这些数据进行分析，然后将需要的信息添加到自己的路由表里。
这样，图 2 中 Router 2 的路由表里，就会自动出现 10.10.0.2 和 10.10.0.3 对应的路由规则了。
所以说，所谓 BGP，就是在大规模网络中实现节点路由信息共享的一种协议。
而 BGP 的这个能力，正好可以取代 Flannel 维护主机上路由表的功能。而且，BGP 这种原生就是为大规模网络环境而实现的协议，其可靠性和可扩展性，远非 Flannel 自己的方案可比。
需要注意的是，BGP 协议实际上是最复杂的一种路由协议。我在这里的讲述和所举的例子，仅是为了能够帮助你建立对 BGP 的感性认识，并不代表 BGP 真正的实现方式。
接下来，我们还是回到 Calico 项目上来。
在了解了 BGP 之后，Calico 项目的架构就非常容易理解了。它由三个部分组成：
Calico 的 CNI 插件。这是 Calico 与 Kubernetes 对接的部分。我已经在上一篇文章中，和你详细分享了 CNI 插件的工作原理，这里就不再赘述了。
Felix。它是一个 DaemonSet，负责在宿主机上插入路由规则（即：写入 Linux 内核的 FIB 转发信息库），以及维护 Calico 所需的网络设备等工作。
BIRD。它就是 BGP 的客户端，专门负责在集群里分发路由规则信息。
除了对路由信息的维护方式之外，Calico 项目与 Flannel 的 host-gw 模式的另一个不同之处，就是它不会在宿主机上创建任何网桥设备。这时候，Calico 的工作方式，可以用一幅示意图来描述，如下所示（在接下来的讲述中，我会统一用“BGP 示意图”来指代它）：
图3 Calico工作原理
其中的绿色实线标出的路径，就是一个 IP 包从 Node 1 上的 Container 1，到达 Node 2 上的 Container 4 的完整路径。
可以看到，Calico 的 CNI 插件会为每个容器设置一个 Veth Pair 设备，然后把其中的一端放置在宿主机上（它的名字以 cali 前缀开头）。
此外，由于 Calico 没有使用 CNI 的网桥模式，Calico 的 CNI 插件还需要在宿主机上为每个容器的 Veth Pair 设备配置一条路由规则，用于接收传入的 IP 包。比如，宿主机 Node 2 上的 Container 4 对应的路由规则，如下所示：
10.233.2.3 dev cali5863f3 scope link
即：发往 10.233.2.3 的 IP 包，应该进入 cali5863f3 设备。
基于上述原因，Calico 项目在宿主机上设置的路由规则，肯定要比 Flannel 项目多得多。不过，Flannel host-gw 模式使用 CNI 网桥的主要原因，其实是为了跟 VXLAN 模式保持一致。否则的话，Flannel 就需要维护两套 CNI 插件了。
有了这样的 Veth Pair 设备之后，容器发出的 IP 包就会经过 Veth Pair 设备出现在宿主机上。然后，宿主机网络栈就会根据路由规则的下一跳 IP 地址，把它们转发给正确的网关。接下来的流程就跟 Flannel host-gw 模式完全一致了。
其中，这里最核心的“下一跳”路由规则，就是由 Calico 的 Felix 进程负责维护的。这些路由规则信息，则是通过 BGP Client 也就是 BIRD 组件，使用 BGP 协议传输而来的。
而这些通过 BGP 协议传输的消息，你可以简单地理解为如下格式：
[BGP消息]
我是宿主机192.168.1.3
10.233.2.0/24网段的容器都在我这里
这些容器的下一跳地址是我
不难发现，Calico 项目实际上将集群里的所有节点，都当作是边界路由器来处理，它们一起组成了一个全连通的网络，互相之间通过 BGP 协议交换路由规则。这些节点，我们称为 BGP Peer。
需要注意的是，Calico 维护的网络在默认配置下，是一个被称为“Node-to-Node Mesh”的模式。这时候，每台宿主机上的 BGP Client 都需要跟其他所有节点的 BGP Client 进行通信以便交换路由信息。但是，随着节点数量 N 的增加，这些连接的数量就会以 N²的规模快速增长，从而给集群本身的网络带来巨大的压力。
所以，Node-to-Node Mesh 模式一般推荐用在少于 100 个节点的集群里。而在更大规模的集群中，你需要用到的是一个叫作 Route Reflector 的模式。
在这种模式下，Calico 会指定一个或者几个专门的节点，来负责跟所有节点建立 BGP 连接从而学习到全局的路由规则。而其他节点，只需要跟这几个专门的节点交换路由信息，就可以获得整个集群的路由规则信息了。
这些专门的节点，就是所谓的 Route Reflector 节点，它们实际上扮演了“中间代理”的角色，从而把 BGP 连接的规模控制在 N 的数量级上。
此外，我在前面提到过，Flannel host-gw 模式最主要的限制，就是要求集群宿主机之间是二层连通的。而这个限制对于 Calico 来说，也同样存在。
举个例子，假如我们有两台处于不同子网的宿主机 Node 1 和 Node 2，对应的 IP 地址分别是 192.168.1.2 和 192.168.2.2。需要注意的是，这两台机器通过路由器实现了三层转发，所以这两个 IP 地址之间是可以相互通信的。
而我们现在的需求，还是 Container 1 要访问 Container 4。
按照我们前面的讲述，Calico 会尝试在 Node 1 上添加如下所示的一条路由规则：
10.233.2.0/16 via 192.168.2.2 eth0
但是，这时候问题就来了。
上面这条规则里的下一跳地址是 192.168.2.2，可是它对应的 Node 2 跟 Node 1 却根本不在一个子网里，没办法通过二层网络把 IP 包发送到下一跳地址。
在这种情况下，你就需要为 Calico 打开 IPIP 模式。
我把这个模式下容器通信的原理，总结成了一张图片，如下所示（接下来我会称之为：IPIP 示意图）：
图4 Calico IPIP模式工作原理
在 Calico 的 IPIP 模式下，Felix 进程在 Node 1 上添加的路由规则，会稍微不同，如下所示：
10.233.2.0/24 via 192.168.2.2 tunl0
可以看到，尽管这条规则的下一跳地址仍然是 Node 2 的 IP 地址，但这一次，要负责将 IP 包发出去的设备，变成了 tunl0。注意，是 T-U-N-L-0，而不是 Flannel UDP 模式使用的 T-U-N-0（tun0），这两种设备的功能是完全不一样的。
Calico 使用的这个 tunl0 设备，是一个 IP 隧道（IP tunnel）设备。
在上面的例子中，IP 包进入 IP 隧道设备之后，就会被 Linux 内核的 IPIP 驱动接管。IPIP 驱动会将这个 IP 包直接封装在一个宿主机网络的 IP 包中，如下所示：
图 5 IPIP 封包方式
其中，经过封装后的新的 IP 包的目的地址（图 5 中的 Outer IP Header 部分），正是原 IP 包的下一跳地址，即 Node 2 的 IP 地址：192.168.2.2。
而原 IP 包本身，则会被直接封装成新 IP 包的 Payload。
这样，原先从容器到 Node 2 的 IP 包，就被伪装成了一个从 Node 1 到 Node 2 的 IP 包。
由于宿主机之间已经使用路由器配置了三层转发，也就是设置了宿主机之间的“下一跳”。所以这个 IP 包在离开 Node 1 之后，就可以经过路由器，最终“跳”到 Node 2 上。
这时，Node 2 的网络内核栈会使用 IPIP 驱动进行解包，从而拿到原始的 IP 包。然后，原始 IP 包就会经过路由规则和 Veth Pair 设备到达目的容器内部。
以上，就是 Calico 项目主要的工作原理了。
不难看到，当 Calico 使用 IPIP 模式的时候，集群的网络性能会因为额外的封包和解包工作而下降。在实际测试中，Calico IPIP 模式与 Flannel VXLAN 模式的性能大致相当。所以，在实际使用时，如非硬性需求，我建议你将所有宿主机节点放在一个子网里，避免使用 IPIP。
不过，通过上面对 Calico 工作原理的讲述，你应该能发现这样一个事实：
如果 Calico 项目能够让宿主机之间的路由设备（也就是网关），也通过 BGP 协议“学习”到 Calico 网络里的路由规则，那么从容器发出的 IP 包，不就可以通过这些设备路由到目的宿主机了么？
比如，只要在上面“IPIP 示意图”中的 Node 1 上，添加如下所示的一条路由规则：
10.233.2.0/24 via 192.168.1.1 eth0
然后，在 Router 1 上（192.168.1.1），添加如下所示的一条路由规则：
10.233.2.0/24 via 192.168.2.1 eth0
那么 Container 1 发出的 IP 包，就可以通过两次“下一跳”，到达 Router 2（192.168.2.1）了。以此类推，我们可以继续在 Router 2 上添加“下一条”路由，最终把 IP 包转发到 Node 2 上。
遗憾的是，上述流程虽然简单明了，但是在 Kubernetes 被广泛使用的公有云场景里，却完全不可行。
这里的原因在于：公有云环境下，宿主机之间的网关，肯定不会允许用户进行干预和设置。
当然，在大多数公有云环境下，宿主机（公有云提供的虚拟机）本身往往就是二层连通的，所以这个需求也不强烈。
不过，在私有部署的环境下，宿主机属于不同子网（VLAN）反而是更加常见的部署状态。这时候，想办法将宿主机网关也加入到 BGP Mesh 里从而避免使用 IPIP，就成了一个非常迫切的需求。
而在 Calico 项目中，它已经为你提供了两种将宿主机网关设置成 BGP Peer 的解决方案。
第一种方案，就是所有宿主机都跟宿主机网关建立 BGP Peer 关系。
这种方案下，Node 1 和 Node 2 就需要主动跟宿主机网关 Router 1 和 Router 2 建立 BGP 连接。从而将类似于 10.233.2.0/24 这样的路由信息同步到网关上去。
需要注意的是，这种方式下，Calico 要求宿主机网关必须支持一种叫作 Dynamic Neighbors 的 BGP 配置方式。这是因为，在常规的路由器 BGP 配置里，运维人员必须明确给出所有 BGP Peer 的 IP 地址。考虑到 Kubernetes 集群可能会有成百上千个宿主机，而且还会动态地添加和删除节点，这时候再手动管理路由器的 BGP 配置就非常麻烦了。而 Dynamic Neighbors 则允许你给路由器配置一个网段，然后路由器就会自动跟该网段里的主机建立起 BGP Peer 关系。
不过，相比之下，我更愿意推荐第二种方案。
这种方案，是使用一个或多个独立组件负责搜集整个集群里的所有路由信息，然后通过 BGP 协议同步给网关。而我们前面提到，在大规模集群中，Calico 本身就推荐使用 Route Reflector 节点的方式进行组网。所以，这里负责跟宿主机网关进行沟通的独立组件，直接由 Route Reflector 兼任即可。
更重要的是，这种情况下网关的 BGP Peer 个数是有限并且固定的。所以我们就可以直接把这些独立组件配置成路由器的 BGP Peer，而无需 Dynamic Neighbors 的支持。
当然，这些独立组件的工作原理也很简单：它们只需要 WATCH Etcd 里的宿主机和对应网段的变化信息，然后把这些信息通过 BGP 协议分发给网关即可。

总结

在本篇文章中，我为你详细讲述了 Fannel host-gw 模式和 Calico 这两种纯三层网络方案的工作原理。
需要注意的是，在大规模集群里，三层网络方案在宿主机上的路由规则可能会非常多，这会导致错误排查变得困难。此外，在系统故障的时候，路由规则出现重叠冲突的概率也会变大。
基于上述原因，如果是在公有云上，由于宿主机网络本身比较“直白”，我一般会推荐更加简单的 Flannel host-gw 模式。
但不难看到，在私有部署环境里，Calico 项目才能够覆盖更多的场景，并为你提供更加可靠的组网方案和架构思路。

思考题

你能否能总结一下三层网络方案和“隧道模式”的异同，以及各自的优缺点？
感谢你的收听，欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 56

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
34 | Kubernetes网络模型与CNI网络插件
下一篇
36 | 为什么说Kubernetes只有soft multi-tenancy？
unpreview
 写留言

精选留言(64)

  • swordholder
    2018-11-12
    写了两篇文档： Docker单机网络模型动手实验 https://github.com/mz1999/blog/blob/master/docs/docker-network-bridge.md Docker跨主机Overlay网络动手实验 https://github.com/mz1999/blog/blob/master/docs/docker-overlay-networks.md 通过动手实验加深理解容器网络。分享出来希望对小伙伴有所帮助。 看来学完了这篇，可以再写一个Docker跨主机路由方案动手实验
    展开
    共 3 条评论
    148
  • blackpiglet
    2018-11-12
    三层和隧道的异同： 相同之处是都实现了跨主机容器的三层互通，而且都是通过对目的 MAC 地址的操作来实现的；不同之处是三层通过配置下一条主机的路由规则来实现互通，隧道则是通过通过在 IP 包外再封装一层 MAC 包头来实现。 三层的优点：少了封包和解包的过程，性能肯定是更高的。 三层的缺点：需要自己想办法维护路由规则。 隧道的优点：简单，原因是大部分工作都是由 Linux 内核的模块实现了，应用层面工作量较少。 隧道的缺点：主要的问题就是性能低。
    展开
    共 2 条评论
    118
  • ch_ort
    2020-11-25
    Kubernetes通过一个叫做CNI的接口，维护了一个单独的网桥来代替docker0。这个网桥的名字就叫作：CNI网桥，它在宿主机上的设备名称默认是：cni0。 容器“跨主通信”的三种主流实现方法：UDP、host-gw、VXLAN。 之前介绍了UDP和VXLAN，它们都属于隧道模式，需要封装和解封装。接下来介绍一种纯三层网络方案，host-gw模式和Calico项目 Host-gw模式通过在宿主机上添加一个路由规则： <目的容器IP地址段> via <网关的IP地址> dev eth0 IP包在封装成帧发出去的时候，会使用路由表里的“下一跳”来设置目的MAC地址。这样，它就会通过二层网络到达目的宿主机。 这个三层网络方案得以正常工作的核心，是为每个容器的IP地址，找到它所对应的，“下一跳”的网关。所以说，Flannel host-gw模式必须要求集群宿主机之间是二层连通的，如果宿主机分布在了不同的VLAN里（三层连通），由于需要经过的中间的路由器不一定有相关的路由配置（出于安全考虑，公有云环境下，宿主机之间的网关，肯定不会允许用户进行干预和设置），部分节点就无法找到容器IP的“下一条”网关了，host-gw就无法工作了。 Calico项目提供的网络解决方案，与Flannel的host-gw模式几乎一样，也会在宿主机上添加一个路由规则： <目的容器IP地址段> via <网关的IP地址> dev eth0 其中，网关的IP地址，正是目的容器所在宿主机的IP地址，而正如前面所述，这个三层网络方案得以正常工作的核心，是为每个容器的IP地址，找到它所对应的，“下一跳”的网关。区别是如何维护路由信息： Host-gw : Flannel通过Etcd和宿主机上的flanneld来维护路由信息 Calico: 通过BGP（边界网关协议）来实现路由自治，所谓BGP，就是在大规模网络中实现节点路由信息共享的一种协议。 隧道技术（需要封装包和解包，因为需要伪装成宿主机的IP包，需要三层链通）：Flannel UDP / VXLAN / Calico IPIP 三层网络（不需要封包和解封包，需要二层链通）：Flannel host-gw / Calico 普通模式
    展开
    44
  • 米开朗基杨
    2018-11-30
    写了篇关于calico开启反射路由模式的文章，希望对大家有所帮助：https://www.yangcs.net/posts/calico-rr/
    共 3 条评论
    27
  • 勤劳的小胖子-libo
    2018-12-29
    所以三层可达，二层不可达的k8s集群不能使用Flannel host-gw模式，只能使用其他模式？
    共 2 条评论
    9
  • 虎虎❤️
    2018-11-12
    三层网络优点： 不需要封包、拆包，传输效率会更高；可以设置复杂的网络策略。 隧道模式优点： 不需要在主机间的网关中维护容器路由信息，只需要主机有三层网络的连通性即可。
    9
  • 帅
    2018-11-21
    老师你好，问个小白问题，怎么判断集群里的宿主机是否二层互通，或者说怎么实现二层互通？
    共 7 条评论
    8
  • 每日都想上班
    2018-11-12
    架设k8s集群后，对操作系统及网络知识有了一个很好的复习，感谢大神
    7
  • 小江哥哥
    2021-07-23
    对于二层联通的网络： 可以选择flannel的host-gw或者calico（非ipip模式），将宿主机当作网关，进行直接跳转，区别为calico自己封装了一个组件（BIRD）存储并维护路由关系，flannel维护并借助K8S的etcd存储路由关系。 对于多个vlan的网络： flannel的vxlan和calico的ipip模式都可以选择，它们都通过内核模块进行了一次封包和解包过程，有内核态到用户态的切换，效率损耗较大（20%-30%）。不同点在于，calico拥有‘重型武器’BGP，可以通过它与宿主机的网关交换，共同维护路由关系，实现伪二层直连，方便自定义网络架构，定制程度比flannel高。 其他区别： 1. flannel的所有模式都使用了cni的网桥模式，不用在宿主机上维护这么多设备对的映射关系，calico则相反。 2. 所有网络IP规划分配，路由规则存储维护calico都大包大揽，通过BGP，等组件维护，flannel的路由存储和维护需要依赖K8s的etcd，且会与apiserver交互。 3. 在大规模集群中。对于路由规则的跟踪维护，calico有自己的中心化方案（Route Reflector模式），避免了路由信息指数级增长。 4. 在非二层直连网络中，calico支持通过与宿主机网关的互动（BGP协议），组成三层网络，避免了使用ipip封包解包，提高网络性能，这点上比flannel定制化程度更高。
    展开
    共 1 条评论
    6
  • 拉欧
    2019-11-23
    三层网络方案简单易懂，开销小，缺点是需要物理互联，连接节点有限； 隧道协议更通用，可以打通不同网段，但是开销大，协议复杂，难排错；
    6
  • 羁绊12221
    2019-08-16
    老师好，flannel UDP 隧道封装的是IP包，vxlan封装的是 二层帧，Calico IPIP模式封装的也是IP包。。感觉上使用隧道通信封装IP报文就够了吧？封装二层帧有什么考虑吗？

    作者回复: 有些网络方案或者硬件，要求必须在二层做一些功能

    5
  • 峰哥
    2018-12-11
    老师好，有个1.4的K8S集群，sprincloud的微服务，怎么升级到1.10，是生产环境，有什么好的办法，谢谢

    作者回复: 版本差太远了，升级不了。。

    4
  • ch_ort
    2020-11-25
    有个疑问，为什么叫 “三层”网络方案呢？
    共 2 条评论
    3
  • 头发乱了
    2020-07-23
    听老师的讲解真是太过瘾了！！
    3
  • ch_ort
    2020-06-20
    有一个疑问 ，Calico IPIP模式下。IPIP封包前后，IP Header里面的目的IP都是“192.168.2.2”。那为什么封包前不能从Node1发送到Node2 ？
    共 4 条评论
    3
  • 朱升平
    2018-11-12
    网络是短板，得多学习学习！
    3
  • ch_ort
    2020-06-20
    隧道技术（需要封装包和解包，因为需要伪装成宿主机的IP包，需要三层链通）：Flannel UDP / VXLAN / Calico IPIP 三层网络（不需要封包和解封包，需要二层链通）：Flannel host-gw / Calico
    共 1 条评论
    2
  • djfhchdh
    2019-11-21
    三层网络方案和“隧道模式”的异同，以及各自的优缺点：三层网络方案要求宿主机二层连通，隧道模式不要求宿主机二层连通；三层网路方案没有封包和解包，性能上比隧道模式要好。
    共 2 条评论
    2
  • 每日都想上班
    2018-11-13
    碰到一个奇怪的问题，集群中一台master节点重启后，发现docker images 镜像都被清空了一样，然后我重新pull过来，过一会又没有了，这个是哪里问题呢？
    共 1 条评论
    2
  • freeman
    2018-11-13
    老师，能介绍一下Cilium吗
    2