OpenStack与CNCF

CNCF（Cloud Native Computing Foundation），即云原生计算基金会，于 2015 年 7 月成立，隶属于 Linux 基金会，初衷围绕“云原生”服务云计算，致力于维护和集成开源技术，支持编排容器化微服务架构应用。

而对 OpenStack 来说，许多运营商早期的时候使用 OpenStack 来实现他们的 SDN 计划，而现在供应商社区则无法提供所需的解决方案。同时，OpenStack 存在的一些问题还归咎于它无法处理一些较大成员的不同需求。

而为了规避这样的问题，CNCF 留出了在供应商之上添加更多产品的余地，让社区来决定其有用性。这样他们的生存和死亡由自身的优势决定，但 OpenStack 社区人为地支撑着将死的平台。

Kubernetes 面向应用层，变革的是业务架构（容器对应应用），而 OpenStack 面向资源层，改变的是资源供给模式（虚拟机对应计算，云盘、网络当然也是为虚拟机服务的）。

OpenStack 是兼容传统的架构，而 Kubernetes 是面向未来的架构。

kubernetes是管理container的工具，openstack是管理VM的工具。

OpenStack的历史

Rackspace和NASA联手共同成立了一个开源项目。这个项目，就是OpenStack。

OpenStack开源社区每年都会开两次设计峰会（Design Summit），发布两个正式版本。

云计算之所以成为一种普遍采用的流行技术，就是因为它有这么几方面的优点：

1 能力强

2 很可靠

3 灵活性

4 低成本

OpenStack从一开始，就是为了云计算服务的。简单来说，它就是一个操作系统，一套软件，一套IaaS软件。

伴随它一起出现的，还有很多新词，例如NFV、Nova、Neutron、Horizon等，让人云里雾里。

Nova

OpenStack云实例生命期所需的各种动作都将由Nova进行处理和支撑，它负责管理整个云的计算资源、网络、授权及测度。

Keystone

为所有的OpenStack组件提供认证和访问策略服务，主要对（但不限于）Swift、Glance、Nova等进行认证与授权。

Horizon

Horizon是一个用以管理、控制OpenStack服务的Web控制面板。

OpenStack的组件都有自己的功能定位。其实，每个组件都可以算是独立的一个程序（Software）。Open为开放之意，Stack则是堆砌，也就是许多Open的Softwares进行集合和堆砌。

OpenStack Neutron介绍

Neutron并不是最早的OpenStack项目。最早期的OpenStack里面，网络是由nova的nova-network模块实现。

首先，Neutron是OpenStack的网络服务项目。目前来看，脱离了OpenStack，它什么也不是，也貌似也没有独立使用的应用。

其次，这是一个python的软件项目。它的北向有自己的REST API，它在中间有自己的业务逻辑层，它有自己的DB，有自己的用于进程间通讯的消息机制。

OpenStack Neutron是一个多进程运行的项目。常见的进程包括了neutron-server和neutron-xxx-agent们。

OpenStack最基本和常用的操作就是启动虚机。虚机启动的过程中涉及很多内容，其中非常重要的一个环节就是创建并绑定虚机的虚拟网卡。虚机的创建和管理是Nova的任务，虚机网络的创建和管理是Neutron的任务，而虚机网卡，作为连接虚机和虚机网络的桥梁，其创建和管理则同时涉及了Nova和Neutron。

简单来说，在OpenStack中，首先需要各个服务上线；之后Nova会创建逻辑网卡，但是Nova只知道虚机所在的host；Neutron会根据所在的host，判断出相应的网络虚拟化机制，例如ovs，linuxbridge，Neutron会把这些信息回传给Nova；Nova拿到这些信息，调用相应的方法创建虚拟网卡，并接入到虚机；Neutron会监听网桥上端口的变化，发现有上线的端口，与自己本身的数据进行匹配，匹配到了之后接管这个虚拟网卡。对于Neutron来说，它不关心虚拟网卡接的是虚机还是容器还是别的什么，它只能看到虚拟网卡

OpenStack NFV介绍

在NFV之前，NF（Network Function）是一直存在的，网络中，NF可以看成一个个独立的网元，实现着各自的功能。NF以固定的方式连接起来，统一提供的网络功能和服务。

V（Virtualization）是虚拟化。NFV字面上理解就是网络功能虚拟化。

NFV和SDN彼此之间没有必然联系。NFV即使脱离SDN，也能实现，另一方面，NFV和SDN如果相互结合，又可以是互补的存在。SDN和NFV的关系可以描述为下图，图中提到开放是为了技术更好的发展，与技术本身无关。

VPC的发展

很多企业都有自己的数据中心，他们希望云上能有一个隔离的网络环境作为数据中心私有网络的延伸，VPC便应运而生了。所以，VPC设计的初衷就是建造一个隔离的私有网络环境。

在实现上，VPC基于SDN，底层通过Overlay技术完成逻辑隔离。也正因为使用了Overlay技术，云上才能支持海量的VPC。

早期AWS是怎么解决Overlay的性能问题的呢？为什么采用Overlay的方式居然可以支持万兆的EC2实例呢？

答案是，AWS“软硬兼施”的不断创新。

VPC使用规则：

第一，VPC可以覆盖一个区域（Region）里的多个可用区（AZ），但不能覆盖多个区域（Region）；

第二，一个子网只能在一个可用区（AZ）内，不能跨可用区（AZ）；

第三，VPC与用户自己的物理机房互联时，地址段不能冲突。

vxlan的优化

数量限制

公有云厂商的专有网络 VPC，可以为每个用户创建多个子网 。VPC代表了不同的租户，vpc隔离了租户，每个租户的子网之间也是隔离的。 那么如何实现2层的隔离，不同vpc之间，同一vpc不同租户之间？ vlan和vxlan都是一层的隔离。 另外vlan和vxlan都有数量限制，vpc会不是有数量限制？

使用vxlan协议对每个vpc网络进行隔离。物理主机上的虚拟机是使用vlan隔离的，并且现在的物理主机根本无法运行4096个虚拟机，所以vlan是够用的。

而vlxan一共支持一千六百七十多万个，所以数量也是够用的；通过vxlan封装物理机中的使用vlan划分的虚拟机，可以将一个vpc中的vlan信息发送到另一个vpc中，从而达到不同vpc的主机的二层通信。

交换机Mac地址限制

而交换机的内存是有限的，因而 MAC 地址表也是有限的，随着虚拟机（或容器）网卡 MAC 地址数量的空前增加，交换机表示压力山大啊！

而 VXLAN 就厉害了，它用 VTEP（后面会解释）将二层以太网帧封装在 UDP 中，一个 VTEP 可以被一个物理机上的所有 VM（或容器）共用，一个物理机对应一个 VTEP。从交换机的角度来看，只是不同的 VTEP 之间在传递 UDP 数据，只需要记录与物理机数量相当的 MAC 地址表条目就可以了。

虚拟机地址迁移

VLAN 与物理网络融合在一起，不存在 Overlay 网络，带来的问题就是虚拟网络不能打破物理网络的限制。为了解决这些问题，有很多方案被提出来，Overlay 就是其中之一，而 VXLAN 是 Overlay 的一种典型的技术方案。

而 VXLAN 将二层以太网帧封装在 UDP 中（上面说过了），相当于在三层网络上构建了二层网络。这样不管你物理网络是二层还是三层，都不影响虚拟机（或容器）的网络通信，也就无所谓部署在哪台物理设备上了，可以随意迁移。

在JDC内部名词解释：

VS(虚拟交换机)

虚拟路由器即Virtual Router（VRouter），在系统中简称为VR。VR具有路由器功能，不同VR拥有各自独立的路由表。系统中有一个默认VR，名为trust-vr，默认情况下，所有三层安全域都将会自动绑定到trust-vr上。系统支持多VR功能且不同硬件平台支持的最大VR数不同。多VR将设备划分成多个虚拟路由器，每个虚拟路由器使用和维护各自完全独立的路由表，此时一台设备可以充当多台路由器使用。多VR使设备能够实现不同路由域的地址隔离与不同VR间的地址重叠，同时能够在一定程度上避免路由泄露，增加网络的路由安全。

VR（虚拟路由器）

具有交换机功能。vSwitch工作在二层，将二层安全域绑定到vSwitch上后，绑定到安全域的接口也被绑定到该vSwitch上。一个vSwitch就是一个二层转发域，每个vSwitch都有自己独立的MAC地址表，因此设备的二层转发在vSwitch中实现。并且，流量可以通过vSwitch接口，实现二层与三层之间的转发。

DR(指定路由)

DR承载公网到VPC的流量。DS口接收来自公网的流量，通过DV口分发给VR。只有公网到VPC的流量，没有VPC到公网的流量。VPC到公网的流量直接从VR出去

DR: Designate router，指定路由器
BDR：Backup Disignate router，备用指定路由器
DROthers：其余非DR/BDR路由器
DR/BDR选举规则：先比较接口优先级，越大越优先。优先级相同，比较RID，越大越优先
VTEP（VXLAN Tunnel Endpoints，VXLAN 隧道端点）

VXLAN 网络的边缘设备，用来进行 VXLAN 报文的处理（封包和解包）。VTEP 可以是网络设备（比如交换机），也可以是一台机器（比如虚拟化集群中的宿主机）。

VNI（VXLAN Network Identifier，VXLAN 网络标识符）

VNI 是每个 VXLAN 段的标识，是个 24 位整数，一共有 $2^{24} = 16777216$（一千多万），一般每个 VNI 对应一个租户，也就是说使用 VXLAN 搭建的公有云可以理论上可以支撑千万级别的租户。

Tunnel（VXLAN 隧道）

隧道是一个逻辑上的概念，在 VXLAN 模型中并没有具体的物理实体向对应。隧道可以看做是一种虚拟通道，VXLAN 通信双方认为自己是在直接通信，并不知道底层网络的存在。从整体来说，每个 VXLAN 网络像是为通信的虚拟机搭建了一个单独的通信通道，也就是隧道。

VXLAN 的报文结构

VXLAN 报文的转发过程就是：原始报文经过 VTEP，被 Linux 内核添加上 VXLAN 头部以及外层的 UDP 头部，再发送出去，对端 VTEP 接收到 VXLAN 报文后拆除外层 UDP 头部，并根据 VXLAN 头部的 VNI 把原始报文发送到目的服务器。

VTEP 转发表的学习可以通过以下两种方式：
多播
外部控制中心（如 Flannel、Cilium 等 CNI 插件）
这里总算看到一个熟悉的名词flannel，k8s开发着泪奔~~

Linux 对 VXLAN 协议的支持时间并不久，2012 年 Stephen Hemminger 才把相关的工作合并到 kernel 中，并最终出现在 kernel 3.7.0 版本。为了稳定性和很多的功能，可能会看到某些软件推荐在 3.9.0 或者 3.10.0 以后版本的 kernel 上使用 VXLAN。

管理 VXLAN 接口

Linux VXLAN 接口的基本管理如下：

1.创建点对点的 VXLAN 接口

2.创建多播模式的 VXLAN 接口

3.查看 VXLAN 接口详细信息

FDB 表

FDB（Forwarding Database entry，即转发表）是 Linux 网桥维护的一个二层转发表，用于保存远端虚拟机/容器的 MAC地址，远端 VTEP IP，以及 VNI 的映射关系。