.jpg)
首先，OpenStack是用来管理大量虚拟机的“上帝”。他的目标是在控制物理世界的同时管理大量虚拟机。也就是说，虚拟机可以分组，同一组中的虚拟机可以在同一网络中相互通信。不同组的虚拟机相当于处于不同的网络中，无法相互通信。2.是的，我可以把不同组的VM卖给不同的“用户”，让1组的VM属于张三，2组的VM属于李四，让他们彼此隔离，互不知晓。所以我可以成为云厂商，提供云平台服务。
当然你作为云厂商，也肯定要允许一个用户，可以拥有2个网络嘛。万一该客户人傻钱多，就是买了一堆VM，分着玩呢，是吧。逻辑视图
现实中，如果两个机房的服务器和网络想要连接起来，就需要路由器的帮助。在虚拟世界里也是类似的。
因此，从逻辑上讲，虚拟机世界中的网络看起来是这样的。
张三的VM的网络需要和李四的VM的网络通信，或者张三自己的两个独立的网络。你得通过一个叫路由器的“虚拟路由器”来做。
从物理上看，上面的逻辑视图如下所示:
至于如何在一根网线上同时运行多条虚拟网络消息。这是一条网络线上的留言，有不同门派的意思。你可以回到VLAN/VxLAN一章了解详情。
另外，这里可以看到，虚拟网络中的一个“路由器”实际上并不是一个具体的虚拟路由器设备，而只是一个“网络命名空间+转发规则”，下面会详细讨论。
从我们之前学习的OVS章节可以知道，为了实现上面提到的OpenStack的网络虚拟化目标。最简单的实现是为每个物理服务器添加一个OVS虚拟交换机；然后，每个虚拟机都连接到OVS端口，每个端口都被分组并标有相应的VLAN。你能满足基本要求。
但是这个初始版本1.0的实现有一点是不被认可的，就是不能为VM设置安全组。作为一个成为云平台的大目标，平台怎么可能没有安全组的能力(虽然在VM中，firewell或者iptables规则可以设置，但是在VM中，已经卖给用户了，你在人家房间里设置规则不合适，可能会和用户自己的业务规则冲突)。
因此，我们在每个虚拟机的入口添加了一个网桥，任何虚拟机流量都将通过这个网桥。这样，通过在桥上添加iptables规则，就可以达到为VM设置安全组的目的。(注意，此时VM的消息还没有到达OVS，所以该消息仍然没有带有VLAN标签的原始消息，所以iptables规则很容易实现)。
这是我们的OpenStack网络版本2.0。
下半部分。即：通过物理网线，怎么给报文打“门派”标记。
这部分变化很大。物理网有时候要考GRE，有时候要考VLAN，有时候要考VxLAN。有时候，你不得不带上特殊的网络设备。平台必须根据机房部署的网线定制不同的规则。
这样这两类OVS的规则都不好管理(都放在openflow的转发表里)。基于程序员“把库分成表”的思路(或者说我们写代码时“提取函数”的逻辑)，我们把一个独生子女OVS分成多个VOS。分开做不同的事情。
于是，我们来到了3.0版本，这个版本比较常见。基本接近实际的OpenStack网络。但在网络节点部分，还需要再次增强。就是我们的VM，除了相互访问(流量还在几个物理服务器之间徘徊)，还要访问外网(流量去机房外)。因此，我们必须继续增强虚拟机访问外部网络的能力:
这样，差不多就是4.0版本了。我们后面要介绍的OpenStack网络就是基于这个版本。在OpenStack网络中，有一组用于命名各种ovs、网桥和接口的规范。不像上面那么随便命名。
使用上述为虚拟机设置虚拟网络的模型，它应该是自动化的(即，每次创建虚拟机时，都应该使用匹配的虚拟网络电缆连接进行设置)。你必须编写一个主程序来控制这些计算节点上的行为。如下所示:
所以按照OpenStack的官方架构，它需要有三种节点:管理节点、计算节点、网络节点。
在每个节点上，部署了一组代理来接收boss的控制命令。老板是主管理节点
注:如前几章所述，分布式系统和可靠控制都需要一个“代理”，如RabbitMQ(OpenStack选择了这个)、ETCD(Kubernetes选择了这个)和ZooKeeper(Hadoop选择了这个)。
(2)然后中间是绿线，就是VM在这条网络线上发送大量的“自己门派”的消息，也就是VM之间相互通信，不得不去的网络，数据量很大。简称数据平面。
为了保证管理平面和数据平面隔离，互不影响(即VM疯狂发出契约，不要刷新管理命令的消息)。在每个物理服务器上，必须有两个网卡，一个用于管理网络电缆，另一个用于数据网络电缆。
(3)然后是左下角的深绿色线，是虚拟机用来接入机房外网的。只需要一个网络节点和一个额外的网卡。
(4)最后，紫线。你的主控逻辑是否应该打包成API接口，对外公开访问通道？想加就加吧。如果不想要，可以每次登录主控节点，手动轻敲命令控件。
这里，我们打开一个OpenStack计算节点，看看它的网络结构。记得2013年我在学习OS网络(OpenStack版本Hana)的时候，看到一个资料，对我帮助很大。我直接贴在这里了:
根据上面提到的“设计思路”，你应该能理解上图中的网络逻辑。命名上，一般内部ovs叫br-int。隧道的名字叫br-tun。如果有环境，在节点上查询并使用各种网络命令(ip、ovs-vsctl、brctl等。).你可以确认一下。
其中，顶部的红色虚线代表一个网络命名空间。Dnasq是一个DHCP服务器(一个自动为虚拟机分配IP地址的程序)。
该节点还使用各种网络命令来查询和检查确认。
Ps，因为这个网络节点上有很多网络命名空间，所以记得使用ip netns exec命令输入对应的ns来查询这个虚拟空房间的详细情况。
除了在虚拟网络中拥有自己的IP之外，一个VM还可以拥有一个浮动IP(注:对应于云厂商，这一般称为EIP)。我们来看看这个“浮动IP”是什么实现逻辑。
首先，浮动IP属于物理网络世界，也就是OpenStack的外网。它是一个真实的IP地址(不像VM，它是你的虚拟IP)。
如上图所示，对于浮动IP，我总结了一句话:VM的外部名称。
当你从外网访问这个“浮动IP”时，就相当于访问了这个VM。至于为什么叫“漂”字，是因为这个名字会漂。
比如《护驱魔人》这个名字就很响亮。当你报出你要找的人是“保护驱魔人”的时候，所有人都知道你要找的人是谁。但“保护驱魔人”的头衔可以从一个人转移到另一个人身上。
很容易理解，它直接对应云厂商的EIP。
我们的重点直接放在网络节点的名称空间上。(本例中的浮动IP是192.168.101.3)。如下图所示:
root @ net node:/# IP netns exec qrouter-4c db 0354-7732-4d 8f-a3d 0-9 FBC 4b 93 a62d IP地址11:qg-1423 ba 35-7c:& lt；广播、多播、PROMISC、UP、LOWER _ UP & gtmtu 1500 qdisc noqueue状态未知inet 192 . 168 . 101 . 2/24 brd 192 . 168 . 101 . 255作用域全局qg-1423 ba 35-7c inet 192 . 168 . 101 . 3/32 brd 192 . 168 . 101 . 3作用域全局qg-1423 ba 35-7c 12:QR-9 f1 fa 61 e-1e:& lt；广播、多播、PROMISC、UP、LOWER _ UP & gtMTU1500QDISC无队列状态未知iNet 172 . 17 . 17 . 1/24 brd 172 . 17 . 17 . 255 Scope全局QR-9F1Fa61e-1e大家可以看到，有一个名为qg-xx的网卡使用了这个浮动IP地址。
第二个规则是DNAT，即改变目的IP地址。具体内容是:如果目的IP是192.168.101.3(floatingIP)，将目的IP改为172.17.17.2 (VM)。
因此，一旦虚拟机有了浮动IP(也称为EIP)，就可以通过外部网络或直接访问它。
然而，真正的外部IP，可能是有限的，必须节省使用，这导致以下SNAT和DNAT功能。
如果虚拟机想要访问外部网络，但没有为其分配浮动IP。这个时候可以用SNAT。
还是上一节的ns。如果查询这个ns中的网卡信息，可以看到也有一个101.2的IP。
root @ net node:/# IP netns exec qrouter-4c db 0354-7732-4d 8f-a3d 0-9 FBC 4b 93 a62d IP地址11:qg-1423 ba 35-7c:& lt；广播、多播、PROMISC、UP、LOWER _ UP & gtmtu 1500 qdisc noqueue状态未知inet 192 . 168 . 101 . 2/24 brd 192 . 168 . 101 . 255作用域全局qg-1423 ba 35-7c inet 192 . 168 . 101 . 3/32 brd 192 . 168 . 101 . 3作用域全局qg-1423 ba 35-7c 12:QR-9 f1 fa 61 e-1e:& lt；广播、多播、PROMISC、UP、LOWER _ UP & gtMTU1500QDISC无队列状态未知iNet 172 . 17 . 17 . 1/24 brd 172 . 17 . 17 . 255范围全局QR-9F1Fa61e-1e或检查此ns中的iptables规则:
-A quantum-L3-Agent-Snat-s 172.17.17.0/24-J Snat-To-Source 192 . 168 . 101 . 2规则是所有源IP都是172 . 17 . 17 . 0/24的消息(即网络中的所有虚拟机
因此，一旦为虚拟网络设置了SNAT功能，该网络中的所有虚拟机都可以访问外部网络。只是大家共用一个对外出口IP地址(本质上是EIP)，意思是省点用。
缺点是:只能从内部(虚拟网络)访问外部(外网)，外部无法访问内部(毕竟这个IP是大家共享的，不是一个VM)。
在节约使用的原则下(即多个虚拟机共享一个外部IP)。如果您希望从外部访问内部虚拟机，也可以使用DNAT函数。
原则上你应该想到给ns增加一个DNAT规则，根据不同端口转发不同的目的IP地址。
这种省钱方法的缺点是只能指定对应的目的端口。例如，分配给VM1的外部端口80被占用。那么VM2就不能用80，只能委屈的用外接端口号81(或者其他)。
为了省钱，你必须放弃一些东西，否则，为每个虚拟机购买一个EIP就完了。
OpenStack中的路由器用于连接“一个网络”和“另一个网络”。可以是2个虚拟网络，也可以是1个虚拟网络+1个实际外部网络。
路由器的本质是一个网络名称空间。和上一章描述的浮动ip一样，这个ns是一个虚拟的“中转站”。所有的网络连接都需要到这个中转站“休息打扮”后才能去目的地网络。
注意，同一个用户的两个网络互联和不同用户的两个网络互联在底层技术上是一样的。如果区别是用户不同，就需要控制权限，否则张三可以随意上李四的网。
路由器的概念，对应云厂商，一般称为“VPC互联”。有各种各样的产品，以前的vpc对等，现在的云企业网，企业路由，云连接。
元数据服务就是让每一个VM都可以问上帝(OpenStack平台):“你在我的文件上写了什么？”。这是一个非常有趣的特性。
如果你(VM)问上帝，你必须知道上帝在哪里。所以在OpenStack上，神的地址是用专门的IP写的:169.254.169.254，很好记。
比如VM问:我出生后的启动脚本是什么？
$ curl http://169 . 254 . 169 . 254/open stack/latest/user _ data #！/bin/bash echo & # 39；额外的用户数据在这里& # 39；这个功能还是挺有用的，尤其是在做VM自动化的时候(ps，可以查一下叫cloud-init的东西)。
元数据功能应来自AWS。OpenStack兼容AWS的这个“问神”功能(当然当然也肯定承认这个功能还是有用的)。也支持此元数据服务。
我们知道创建和管理VM的组件叫做Nova。也就是元数据特性，要从虚拟世界(VM内部)访问物理世界(Nova的API)，经过上面的介绍，在这种情况下，必须经过一个“中转站”。
让我们先看看虚拟机的内部。当我们访问169.254.169.254时，消息去了哪里？
IP路由默认经由172.17.17.1 Deveth0172 . 17 . 0/24 deveth 0 src 172 . 17 . 17 . 5169 . 254经由172 . 17 . 17 . 1 deveth 0，可以看到当你访问“上帝”时，消息是这样的。
那么网关IP在哪里呢？在网络节点的命名空间中:
12:QR-9 f1 fa 61 e-1e:& lt；广播、多播、PROMISC、UP、LOWER _ UP & gtMTU1500QDISC无队列状态未知iNet 172 . 17 . 17 . 1/24 brd 172 . 17 . 17 . 255 Scope全局QR-9F1Fa61e-1e我们来看看访问169.254的消息到达这个“中转站”后是如何被“持有”的。
root @ net node:/# IP netnsexec q router-7a 44 de 32-3ac 0-4f3e-92cc-1a 37d 8211 db 8 iptables-s可以看出，目的地址为169.254的报文会被转发到本地的9697端口。
-A quantum-L3-agent-pre routing-d 169 . 254 . 169 . 254/32-p TCP-m TCP-dport 80-j REDIRECT-to-ports 9697-A quantum-L3-agent-INPUT-d 127 . 0 . 0 . 1/32-p TCP-m TCP-dport 9697-j accept So，谁在本地监听端口9697(在这个命名空间中)？答案是上帝的代理人，一个代理人在这里偷听。
从上面的介绍可以看出，所有的VM虚拟机都要经过网络节点才能访问外部网络。这也有一些缺点。第一，网络节点的网络流量压力很大；2.一旦网络节点出现异常，就会有大量虚拟机受到影响。那么，能否将网络节点的“中继站”功能复制到每个计算节点上呢？然后，在计算节点上，添加判断逻辑:
如果(当地有“中转站”)&&(符合使用条件){使用当地“中转站”}；否则{继续使用原网络节点的“中转站}。答案是DVR。为了降低网络节点的负载，提高可扩展性，OpenStack在Juno版本中引入了DVR功能，DVR部署在计算节点上。计算节点上的VM使用floatingIP访问互联网，可以直接从计算节点的DVR访问互联网，而不经过网络节点。
这样，网络节点只需要处理SNAT(没有浮动IP的vm与外界的通信)流量，大大降低了负载和整个系统对网络节点的依赖。
特定计算节点的if条件判断由openflow规则控制。这个有点太细了，无法详细研究。你可以阅读相应的文章:
所以你可以看到原来网络节点的路由器现在分散到所有计算节点。一个人(网络节点的路由器)必须做的工作现在被分配给许多人(每个计算节点的路由器)。它确实是一个分布式路由器。
基本上OpenStack的网络实现集成了目前所有的“网络虚拟化部分”，包括ovs交换机、桥接网桥、veth线缆、tap线缆、patch线缆、namespace空room、iptables规则等等。也是唐老师，我接触过最复杂的网络实现(所以这篇文章一直拖到最后)。如果你能了解OpenStack的网络，那么通过分析，你应该能了解和掌握其他云平台的网络。
最后，基本的云网相关课程，汤灿先生只教这个。毕竟可以做入门导师，不具体负责网络开发。所以入门之后，如果想继续深入研究云网络，甚至开始设计网络虚拟化方案，还得靠自己继续实践。骚年加油~
注:由于作者现阶段主要关注云相关业务(Kubernetes集群)，因此OpenStack网络信息并不是最新的。不过这个应该没多大关系，因为它的网络设计原理是继承的。此外，我们课程的主要目的是理解。想做设计，就得自己深入研究。所以，基于理解OpenStack网络的原理，这篇文章还是足够的。