这里写目录标题

小结

上一节我们讲了容器网络的模型，以及如何通过 NAT 的方式与物理网络进行互通。

每一台物理机上面安装好了 Docker 以后，都会默认分配一个 172.17.0.0/16 的网段。一台机器上新创建的第一个容器，一般都会给 172.17.0.2 这个地址，当然一台机器这样玩玩倒也没啥问题。但是容器里面是要部署应用的，就像上一节讲过的一样，它既然是集装箱，里面就需要装载货物。

如果这个应用是比较传统的单体应用，自己就一个进程，所有的代码逻辑都在这个进程里面，上面的模式没有任何问题，只要通过 NAT 就能访问进来。

但是因为无法解决快速迭代和高并发的问题，单体应用越来越跟不上时代发展的需要了。

你可以回想一下，无论是各种网络直播平台，还是共享单车，是不是都是很短时间内就要积累大量用户，否则就会错过风口。所以应用需要在很短的时间内快速迭代，不断调整，满足用户体验；还要在很短的时间内，具有支撑高并发请求的能力。

单体应用作为个人英雄主义的时代已经过去了。如果所有的代码都在一个工程里面，开发的时候必然存在大量冲突，上线的时候，需要开大会进行协调，一个月上线一次就很不错了。而且所有的流量都让一个进程扛，怎么也扛不住啊！

没办法，一个字：拆！拆开了，每个子模块独自变化，减少相互影响。拆开了，原来一个进程扛流量，现在多个进程一起扛。所以，微服务就是从个人英雄主义，变成集团军作战。

容器作为集装箱，可以保证应用在不同的环境中快速迁移，提高迭代的效率。但是如果要形成容器集团军，还需要一个集团军作战的调度平台，这就是 Kubernetes。它可以灵活地将一个容器调度到任何一台机器上，并且当某个应用扛不住的时候，只要在 Kubernetes 上修改容器的副本数，一个应用马上就能变八个，而且都能提供服务。然而集团军作战有个重要的问题，就是通信。

这里面包含两个问题，第一个是集团军的 A 部队如何实时地知道 B 部队的位置变化，第二个是两个部队之间如何相互通信。

第一个问题位置变化，往往是通过一个称为注册中心的地方统一管理的，这个是应用自己做的。当一个应用启动的时候，将自己所在环境的 IP 地址和端口，注册到注册中心指挥部，这样其他的应用请求它的时候，到指挥部问一下它在哪里就好了。当某个应用发生了变化，例如一台机器挂了，容器要迁移到另一台机器，这个时候 IP 改变了，应用会重新注册，则其他的应用请求它的时候，还是能够从指挥部得到最新的位置。

接下来是如何相互通信的问题。NAT 这种模式，在多个主机的场景下，是存在很大问题的。在物理机 A 上的应用 A 看到的 IP 地址是容器 A 的，是 172.17.0.2，在物理机 B 上的应用 B 看到的 IP 地址是容器 B 的，不巧也是 172.17.0.2，当它们都注册到注册中心的时候，注册中心就是这个图里这样子。
这个时候，应用 A 要访问应用 B，当应用 A 从注册中心将应用 B 的 IP 地址读出来的时候，就彻底困惑了，这不是自己访问自己吗？怎么解决这个问题呢？

一种办法是不去注册容器内的 IP 地址，而是注册所在物理机的 IP 地址，端口也要是物理机上映射的端口。

这样存在的问题是，应用是在容器里面的，它怎么知道物理机上的 IP 地址和端口呢？这明明是运维人员配置的，除非应用配合，读取容器平台的接口获得这个 IP 和端口。一方面，大部分分布式框架都是容器诞生之前就有了，它们不会适配这种场景；另一方面，让容器内的应用意识到容器外的环境，本来就是非常不好的设计。

说好的集装箱，说好的随意迁移呢？难道要让集装箱内的货物意识到自己传的信息？而且本来 Tomcat 都是监听 8080 端口的，结果到了物理机上，就不能大家都用这个端口了，否则端口就冲突了，因而就需要随机分配端口，于是在注册中心就出现了各种各样奇怪的端口。无论是注册中心，还是调用方都会觉得很奇怪，而且不是默认的端口，很多情况下也容易出错。

Kubernetes 作为集团军作战管理平台，提出指导意见，说网络模型要变平，但是没说怎么实现。于是业界就涌现了大量的方案，Flannel 就是其中之一。

对于 IP 冲突的问题，如果每一个物理机都是网段 172.17.0.0/16，肯定会冲突啊，但是这个网段实在太大了，一台物理机上根本启动不了这么多的容器，所以能不能每台物理机在这个大网段里面，抠出一个小的网段，每个物理机网段都不同，自己看好自己的一亩三分地，谁也不和谁冲突。

例如物理机 A 是网段 172.17.8.0/24，物理机 B 是网段 172.17.9.0/24，这样两台机器上启动的容器 IP 肯定不一样，而且就看 IP 地址，我们就一下子识别出，这个容器是本机的，还是远程的，如果是远程的，也能从网段一下子就识别出它归哪台物理机管，太方便了。

接下来的问题，就是物理机 A 上的容器如何访问到物理机 B 上的容器呢？

你是不是想到了熟悉的场景？虚拟机也需要跨物理机互通，往往通过 Overlay 的方式，容器是不是也可以这样做呢？

这里我要说 Flannel 使用 UDP 实现 Overlay 网络的方案。

在物理机 A 上的容器 A 里面，能看到的容器的 IP 地址是 172.17.8.2/24，里面设置了默认的路由规则 default via 172.17.8.1 dev eth0。

如果容器 A 要访问 172.17.9.2，就会发往这个默认的网关 172.17.8.1。172.17.8.1 就是物理机上面 docker0 网桥的 IP 地址，这台物理机上的所有容器都是连接到这个网桥的。

在物理机上面，查看路由策略，会有这样一条 172.17.0.0/24 via 172.17.0.0 dev flannel.1，也就是说发往 172.17.9.2 的网络包会被转发到 flannel.1 这个网卡。

这个网卡是怎么出来的呢？在每台物理机上，都会跑一个 flanneld 进程，这个进程打开一个 /dev/net/tun 字符设备的时候，就出现了这个网卡。

你有没有想起 qemu-kvm，打开这个字符设备的时候，物理机上也会出现一个网卡，所有发到这个网卡上的网络包会被 qemu-kvm 接收进来，变成二进制串。只不过接下来 qemu-kvm 会模拟一个虚拟机里面的网卡，将二进制的串变成网络包，发给虚拟机里面的网卡。但是 flanneld 不用这样做，所有发到 flannel.1 这个网卡的包都会被 flanneld 进程读进去，接下来 flanneld 要对网络包进行处理。

物理机 A 上的 flanneld 会将网络包封装在 UDP 包里面，然后外层加上物理机 A 和物理机 B 的 IP 地址，发送给物理机 B 上的 flanneld。

为什么是 UDP 呢？因为不想在 flanneld 之间建立两两连接，而 UDP 没有连接的概念，任何一台机器都能发给另一台。物理机 B 上的 flanneld 收到包之后，解开 UDP 的包，将里面的网络包拿出来，从物理机 B 的 flannel.1 网卡发出去。

在物理机 B 上，有路由规则 172.17.9.0/24 dev docker0 proto kernel scope link src 172.17.9.1。

将包发给 docker0，docker0 将包转给容器 B。通信成功。上面的过程连通性没有问题，但是由于全部在用户态，所以性能差了一些。

跨物理机的连通性问题，在虚拟机那里有成熟的方案，就是 VXLAN，那能不能 Flannel 也用 VXLAN 呢？

当然可以了。如果使用 VXLAN，就不需要打开一个 TUN 设备了，而是要建立一个 VXLAN 的 VTEP。如何建立呢？可以通过 netlink 通知内核建立一个 VTEP 的网卡 flannel.1。在我们讲 OpenvSwitch 的时候提过，netlink 是一种用户态和内核态通信的机制。

当网络包从物理机 A 上的容器 A 发送给物理机 B 上的容器 B，在容器 A 里面通过默认路由到达物理机 A 上的 docker0 网卡，然后根据路由规则，在物理机 A 上，将包转发给 flannel.1。这个时候 flannel.1 就是一个 VXLAN 的 VTEP 了，它将网络包进行封装。

内部的 MAC 地址这样写：源为物理机 A 的 flannel.1 的 MAC 地址，目标为物理机 B 的 flannel.1 的 MAC 地址，在外面加上 VXLAN 的头。

外层的 IP 地址这样写：源为物理机 A 的 IP 地址，目标为物理机 B 的 IP 地址，外面加上物理机的 MAC 地址。

这样就能通过 VXLAN 将包转发到另一台机器，从物理机 B 的 flannel.1 上解包，变成内部的网络包，通过物理机 B 上的路由转发到 docker0，然后转发到容器 B 里面。通信成功。

小结

好了，今天的内容就到这里，我来总结一下。

基于 NAT 的容器网络模型在微服务架构下有两个问题，一个是 IP 重叠，一个是端口冲突，需要通过 Overlay 网络的机制保持跨节点的连通性。

Flannel 是跨节点容器网络方案之一，它提供的 Overlay 方案主要有两种方式，一种是 UDP 在用户态封装，一种是 VXLAN 在内核态封装，而 VXLAN 的性能更好一些。

最后，给你留两个问题：

1.通过 Flannel 的网络模型可以实现容器与容器直接跨主机的互相访问，那你知道如果容器内部访问外部的服务应该怎么融合到这个网络模型中吗？

2.基于 Overlay 的网络毕竟做了一次网络虚拟化，有没有更加高性能的方案呢？

容器网络之Flannel：每人一亩三分地相关推荐

热门技术中的应用：容器技术中的网络-第30讲-容器网络之Flannel：每人一亩三分地
上一节我们讲了容器网络的模型,以及如何通过NAT的方式与物理网络进行互通. 每一台物理机上面安装好了Docker以后,都会默认分配一个172.17.0.0/16的网段.一台机器上新创建的第一个容器,一 ...
第 8 章容器网络 - 061 - flannel 的连通与隔离
flannel 的连通与隔离测试 bbox1 和 bbxo2 的连通性: bbox1 能够 ping 到位于不同 subnet 的 bbox2,通过 traceroute 分析一下 bbox1 到 ...
数据中心网络vs云网络vs容器网络
1. 数据中心网络 1.1 接入+汇聚+核心数据中心往往有非常多的机器,当塞满一机架的时候,需要有交换机将这些服务器连接起来,可以互相通信.这些交换机往往是放在机架顶端的,所以经常称为 TOR(To ...
Kubernetes容器网络（一）：Flannel网络原理
前言本文主要分享Flannel如何解决跨主机容器之间通信问题的,如果你对主机内容器之间通信流程还不了解,建议先看下这篇文章:Docker网络原理 1.前置网络知识 1).tun/tap设备 tun/ ...
容器网络Calico进阶实践 | 褚向阳
各位晚上好,我是数人云的褚向阳,接下来要跟大家分享的主题是<容器网络Calico进阶实践>. 距离上次聊 Calico 已经过去快半年的时间了,数人云也一直在努力将容器网络方案应用到企业客 ...
python刷题一亩三分地_手把手教你用python抓网页数据【一亩三分地论坛数据科学版】...
前言:. visit 1point3acres.com for more. 数据科学越来越火了,网页是数据很大的一个来源.最近很多人问怎么抓网页数据,据我所知,常见的编程语言(C++,java,pyt ...
Kubernetes Docker 容器网络终极之战(十四)
与 Docker 默认的网络模型不同,Kubernetes 形成了一套自己的网络模型,该网络模型更加适应传统的网络模式,应用能够平滑的从非容器环境迁移到 Kubernetes 环境中. 自从 Dock ...
Kubernetes容器网络及网络模型
1.Docker 网络模型在讨论Kubernetes网络之前,让我们先来看一下Docker网络.Docker采用插件化的网络模式,默认提供bridge.host.none.overlay.macla ...
在生产环境中，阿里云如何构建高性能云原生容器网络？（含 PPT 下载）
作者 | 溪恒阿里云技术专家直播完整视频回顾:https://www.bilibili.com/video/BV1nC4y1x7mt/ 关注"阿里巴巴云原生"公众号,后台回复 ...

容器网络之Flannel：每人一亩三分地

这里写目录标题

小结

容器网络之Flannel：每人一亩三分地相关推荐

最新文章

热门文章