容器网络OVN-（CNI、Flannel、Overlay）原理学习

ovn是什么

OVN(Open Virtual Network)是一个基于 Open vSwitch(OVS)的网络虚拟化解决方案，用于构建软件定义网络(SDN)。OVN 提供了一套分布式的机制来管理和控制虚拟网络，使得虚拟网络拓扑可以分离配置和物理网络基础设施。

OVN 网络架构

OVN 的架构包括多个组件，每个组件都有特定的功能。以下是 OVN 网络架构的主要组件及其工作原理：

1. OVN Central (OVN 中央管理节点)

• Northbound 数据库(NBDB)：存储高层次的逻辑网络配置，包括逻辑交换机、路由器、安全组等。由 OVN 南北向 API 接口提供给控制平面的配置。
• Southbound 数据库(SBDB)：存储低层次的逻辑状态和数据通道的配置，供 OVN 控制平面使用。北向数据库的状态会同步到南向数据库。

2. OVN Controller (OVN 控制器)

• OVN 北向控制器：写入 high-level 逻辑配置到北向数据库(NBDB)。
• OVN 南向控制器：读取南向数据库(SBDB)内容，并根据南向数据库内容配置本地 hypervisor 的 Open vSwitch。

3. OVS (Open vSwitch)

• 数据平面：具体处理数据包的转发。OVS 充当虚拟交换机或虚拟路由器，执行流规则来转发数据包。

核心工作流

北向数据库(NBDB)和南向数据库(SBDB)的同步

1. 逻辑配置：用户通过云管理平台或另一种高级接口配置逻辑网络，如逻辑交换机和逻辑路由器，这些配置信息被写入北向数据库(NBDB)。
2. 状态同步：中央管理节点将 NBDB 中的逻辑网络配置同步到南向数据库(SBDB)。
3. 控制器作用：运行在每个计算节点(Hypervisor)上的 OVN 控制器读取南向数据库(SBDB)，并自动生成 OpenFlow 规则，这些规则应被安装到 OVS 数据平面中。

数据路径

1. 数据包处理：OVS 数据平面处理数据包，根据安装的流规则进行转发。
2. 逻辑网络连接：OVN 通过封装(如 Geneve)方法，实现跨主机的数据包传输，使多个计算节点上的虚拟机能够在逻辑网络中互相通信。

核心组件详细介绍

1. OVN Central

• OVN Northd：将北向数据库中的高层次配置转化为南向数据库中的底层配置。它是一种逻辑网络编译器。

2. OVN Controller

• ovn-controller：运行在 Hypervisor 中，读取南向数据库并配置 OVS。

3. OVS (Open vSwitch)

• ovs-vswitchd：处理 OpenFlow 规则并进行数据包转发。
• ovsdb-server：提供 OVS 数据库的管理服务。

逻辑拓扑示例

假设有两个主机，Host A 和 Host B，各自运行一个虚拟机 VM1 和 VM2。通过 OVN 管理逻辑网络，实现 VM1 和 VM2 在不同主机之间通信：

1. 配置：

• 在 OVN 中创建一个逻辑交换机。
• 将 VM1 和 VM2 附加到该逻辑交换机。

2. 同步：

• 逻辑交换机和端口配置信息写入 NBDB。
• NBDB 中的配置信息由 OVN 北向控制器同步到 SBDB。

3. 数据包转发：

• ovn-controller 读取 SBDB 配置，生成相应的 OpenFlow 规则，并在 Host A 和 Host B 上配置 OVS。
• VM1 向 VM2 发送数据包，OVS 数据平面根据 OpenFlow 规则进行封装(如使用 Geneve 封装)，数据包通过物理网络传输到 Host B。
• Host B 的 OVS 解封装数据包并交付给 VM2。

特性和优点

• 可扩展性：支持大规模数据中心网络的快速部署和管理。
• 灵活的封装技术：如 Geneve，可以跨越复杂的物理网络拓扑实现虚拟主机间通信。
• 分布式控制平面：保证网络配置和数据包转发的高效和可靠性。
• 安全性：支持 ACL 和安全组管理，实现精细粒度的流量控制。

OVN 提供了一种有效和高效的方法以构建大规模虚拟网络，同时保持良好的性能和管理便捷性。通过其模块化的架构和丰富的功能集，OVN 成为管理和控制虚拟网络的重要工具。

什么是CNI

CNI(Container Network Interface)是一个由 CNCF(Cloud Native Computing Foundation)维护的标准，用于为容器创建和管理网络接口。CNI 定义了一组简单的接口，为容器运行时提供网络连接和离线时清理的功能，广泛应用于容器编排系统如 Kubernetes。

CNI 的基本概念和架构

1. 插件架构

CNI 采用插件架构，允许为不同的网络实现提供可插拔的解决方案。每个 CNI 插件都负责特定的网络配置任务，例如 IP 地址分配、网络连接、接口配置等。

2. 规范

CNI 规范定义了一个容器创建时，调用插件进行网络配置的标准接口，以及容器删除时，清理网络配置的标准接口。

3. 执行流程

• ADD：容器创建时，CNI 插件会被调用以创建网络接口，分配 IP 地址等。
• DEL：容器删除时，CNI 插件会被调用以清理网络接口，释放 IP 地址等。

4. 配置文件

CNI 配置文件通常位于 /etc/cni/net.d/，描述了网络插件及其参数。例如，配置文件可以指定要使用的 CNI 插件及其具体配置选项。

CNI 的关键组件

1. 容器运行时(Container Runtime)：例如 Docker、CRI-O、containerd 等，负责容器的生命周期管理，并调用 CNI 插件进行网络配置。
2. CNI 插件：具体的网络实现插件，可以是各种类型的网络方案，例如 Flannel、Calico、Weave、Cilium 等。
3. CNI 规范：定义插件接口，确保容器运行时与插件之间的互操作性。

典型 CNI 插件

以下是一些常见的 CNI 插件及其功能特性：

1. Flannel

• 用法：Kubernetes 中非常常见的网络插件。
• 特性：提供简单的网格网络。Flannel 通过等值分段路积分配 IP 地址，使每个节点获得一个虚拟网络子网。

2. Calico

• 用法：广泛应用于需要高级网络策略的 Kubernetes 集群。
• 特性：支持 BGP(边界网关协议)，支持基于策略的网络安全模型，如 ACL、网络策略等。

3. Weave

• 用法：适用于对跨主机容器连接要求较高的应用场景。
• 特性：提供分布式 VPN 式的容器网络互联，支持网段自动配置，确保各个节点分布的 Pods 能在同一网络中通信。

4. Cilium

• 用法：适用于高级安全和监控需求的环境。
• 特性：基于 eBPF 技术，提供高性能的网络数据面，支持丰富的网络策略管理和安全控制。

CNI 工作流程

以下是 Kubernetes 中 CNI 工作流程的示例：

1. Pod 创建请求：用户通过 kube-apiserver 提交 Pod 创建请求。
2. 调度决策：kube-scheduler 根据资源情况将 Pod 调度到合适的节点上。
3. 调用 CRI：kubelet(Kubernetes 节点代理)接收到 Pod 调度请求，调用容器运行时(container runtime，例如 CRI-O、containerd)，创建容器。
4. 网络配置：

• 容器运行时调用 CNI 插件进行网络配置。
• CNI 插件执行 ADD 操作，创建 veth 接口，设置网络名称空间，分配 IP 地址等。

5. Pod 启动：网络配置完成后，Pod 正常启动。
6. Pod 删除：当 Pod 被删除时，kubelet 调用容器运行时进行清理，容器运行时调用 CNI 插件的 DEL 操作，清理网络接口和资源。

示例 CNI 配置文件

以下是一个简单的 Flannel CNI 配置文件示例：

登录后复制

{
  "name": "cni-flannel",
  "type": "flannel",
  "delegate": {
    "isDefaultGateway": true
  }
}

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.

该配置文件指示 CNI 使用 Flannel 作为网络插件，同时设置 isDefaultGateway 为 true，表示该节点将作为默认网关。

优点和特性

1. 可插拔：允许在不同容器运行时和网络实现之间进行无缝切换。
2. 灵活性：支持各种网络模型，包括桥接、覆盖、路由、主机网络等。
3. 标准化：提供统一接口，简化网络插件的开发和集成。
4. 广泛支持：被 Kubernetes 等主要容器编排系统支持，确保生态系统的一致性和兼容性。

总结来说，CNI 网络为容器网络提供了一个标准化、灵活、可扩展的解决方案，使得不同的网络实现可以无缝集成，极大地方便了容器编排系统网络配置和管理。

CNI(Container Network Interface)是一个由 CNCF(Cloud Native Computing Foundation)维护的标准，用于为容器创建和管理网络接口。CNI 定义了一组简单的接口，为容器运行时提供网络连接和离线时清理的功能，广泛应用于容器编排系统如 Kubernetes。

CNI 的基本概念和架构

1. 插件架构

CNI 采用插件架构，允许为不同的网络实现提供可插拔的解决方案。每个 CNI 插件都负责特定的网络配置任务，例如 IP 地址分配、网络连接、接口配置等。

2. 规范

CNI 规范定义了一个容器创建时，调用插件进行网络配置的标准接口，以及容器删除时，清理网络配置的标准接口。

3. 执行流程

• ADD：容器创建时，CNI 插件会被调用以创建网络接口，分配 IP 地址等。
• DEL：容器删除时，CNI 插件会被调用以清理网络接口，释放 IP 地址等。

4. 配置文件

CNI 配置文件通常位于 /etc/cni/net.d/，描述了网络插件及其参数。例如，配置文件可以指定要使用的 CNI 插件及其具体配置选项。

CNI 的关键组件

1. 容器运行时(Container Runtime)：例如 Docker、CRI-O、containerd 等，负责容器的生命周期管理，并调用 CNI 插件进行网络配置。
2. CNI 插件：具体的网络实现插件，可以是各种类型的网络方案，例如 Flannel、Calico、Weave、Cilium 等。
3. CNI 规范：定义插件接口，确保容器运行时与插件之间的互操作性。

典型 CNI 插件

以下是一些常见的 CNI 插件及其功能特性：

1. Flannel

• 用法：Kubernetes 中非常常见的网络插件。
• 特性：提供简单的网格网络。Flannel 通过等值分段路积分配 IP 地址，使每个节点获得一个虚拟网络子网。

2. Calico

• 用法：广泛应用于需要高级网络策略的 Kubernetes 集群。
• 特性：支持 BGP(边界网关协议)，支持基于策略的网络安全模型，如 ACL、网络策略等。

3. Weave

• 用法：适用于对跨主机容器连接要求较高的应用场景。
• 特性：提供分布式 VPN 式的容器网络互联，支持网段自动配置，确保各个节点分布的 Pods 能在同一网络中通信。

4. Cilium

• 用法：适用于高级安全和监控需求的环境。
• 特性：基于 eBPF 技术，提供高性能的网络数据面，支持丰富的网络策略管理和安全控制。

CNI 工作流程

以下是 Kubernetes 中 CNI 工作流程的示例：

1. Pod 创建请求：用户通过 kube-apiserver 提交 Pod 创建请求。
2. 调度决策：kube-scheduler 根据资源情况将 Pod 调度到合适的节点上。
3. 调用 CRI：kubelet(Kubernetes 节点代理)接收到 Pod 调度请求，调用容器运行时(container runtime，例如 CRI-O、containerd)，创建容器。
4. 网络配置：

• 容器运行时调用 CNI 插件进行网络配置。
• CNI 插件执行 ADD 操作，创建 veth 接口，设置网络名称空间，分配 IP 地址等。

5. Pod 启动：网络配置完成后，Pod 正常启动。
6. Pod 删除：当 Pod 被删除时，kubelet 调用容器运行时进行清理，容器运行时调用 CNI 插件的 DEL 操作，清理网络接口和资源。

示例 CNI 配置文件

以下是一个简单的 Flannel CNI 配置文件示例：

登录后复制

{
  "name": "cni-flannel",
  "type": "flannel",
  "delegate": {
    "isDefaultGateway": true
  }
}

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.

该配置文件指示 CNI 使用 Flannel 作为网络插件，同时设置 isDefaultGateway 为 true，表示该节点将作为默认网关。

优点和特性

1. 可插拔：允许在不同容器运行时和网络实现之间进行无缝切换。
2. 灵活性：支持各种网络模型，包括桥接、覆盖、路由、主机网络等。
3. 标准化：提供统一接口，简化网络插件的开发和集成。
4. 广泛支持：被 Kubernetes 等主要容器编排系统支持，确保生态系统的一致性和兼容性。

总结来说，CNI 网络为容器网络提供了一个标准化、灵活、可扩展的解决方案，使得不同的网络实现可以无缝集成，极大地方便了容器编排系统网络配置和管理。

什么是Flannel

Flannel 是一种用于 Kubernetes 和其他容器编排系统的网络插件，它为容器提供简单而有效的网络相互通信机制，通常被称为 Overlay Network。Flannel 的主要目的是为容器网络提供扁平的专用 IP 地址空间，使得容器无论部署在什么位置，都能够通过固定的 IP 地址进行通信。

Flannel 的工作原理

Flannel 的工作原理主要围绕以下几个关键点：

1. Overlay Network(覆盖网络)

Flannel 创建一个虚拟的覆盖网络，使得即使在不同的物理或虚拟节点上的容器也可以通过这个统一的网络进行通信。覆盖网络的好处是可以独立于底层的物理网络架构，让网络配置更加简单和一致。

2. Etcd 作为控制平面

Flannel 使用 etcd 作为控制平面存储网络配置和状态信息。每个节点的 Flannel 代理会将自己的配置信息(如分配的子网)存储在 etcd 中，并从 etcd 中获取其他节点的配置信息。

3. Subnet(子网)分配

当一个新节点加入集群时，Flannel 会为该节点分配一个唯一的子网。这个子网从一个全局的大网段(通常是 10.0.0.0/8)中划分出来。这确保了容器的 IP 地址在整个集群中是唯一和不冲突的。

4. 数据包封装和传输

Flannel 支持多种封装方式(如 vxlan、UDP、host-gw 等)，用于数据包的传输。以下是几种常见的封装模式：

• VXLAN：一种隧道协议，将二层以太网帧封装在四层 UDP 数据包中，适合跨 L3 路由的情况。
• UDP：将数据包封装在 UDP 数据包中进行传输，适用于简单网络环境。
• Host-gw：不进行封装，直接使用主机的路由表进行路由，适用于网络拓扑比较简单、所有节点都在同一二层网络的情况。

5. 跨节点通信

当一个容器需要和另一个节点上的容器通信时，数据包会被封装成 VXLAN(根据具体配置)数据包，通过主机的物理接口发送到目标节点。目标节点的 Flannel 组件接收封装的数据包，进行解封装，并将数据包转发到对应的容器。

Flannel 的数据流示例

以一个使用 VXLAN 模式的 Flannel 部署为例：

1. 节点 A 上的容器 A(IP 10.1.0.2)需要与节点 B 上的容器 B(IP 10.2.0.3)通信：

• 容器 A 发送一个数据包，目标地址为容器 B 的 IP 地址(10.2.0.3)。

2. 节点 A 的 Flannel 接收到数据包：

• Flannel 决定该数据包需要通过 VXLAN 隧道转发到节点 B，因此将数据包进行封装。
• 封装后的数据包目的地址是节点 B 的物理 IP 地址。

3. 通过物理网络传输：

• 封装的数据包通过节点 A 的物理网络接口发送到节点 B。

4. 节点 B 接收到封装数据包：

• 节点 B 的 Flannel 解封装数据包，并将原始数据包转发给容器 B。

5. 容器 B 接收数据包：

• 容器 B 接收到源自容器 A 的数据包，并进行处理。

Flannel 组件

1. flanneld

这是 Flannel 的核心守护进程，运行在每个节点上，主要负责：

• 从 etcd 获取网络配置和子网分配信息。
• 维护本地主机的 VXLAN 隧道接口或其他封装接口。
• 进行子网分配与管理。
• 封装和解封装跨节点的数据包。

2. etcd

Flannel 使用 etcd 作为其分布式存储系统，存储网络配置和状态信息，包括：

• 整个集群的网络配置(如网络范围、子网分配情况)。
• 每个节点的分配子网信息。

配置示例

以下是一个简单的 Flannel 配置示例(假设使用 etcd 作为存储)：

登录后复制

{
  "Network": "10.0.0.0/8",
  "SubnetLen": 24,
  "Backend": {
    "Type": "vxlan",
    "VNI": 1,
    "Port": 8472
  }
}

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.

• Network：定义整个集群的网络范围。
• SubnetLen：定义分配给每个节点的子网长度。
• Backend：定义使用的后端封装类型(例如 vxlan 或其他)。

优点和局限性

优点

1. 简单易用：配置简单，适合快速部署和使用。
2. 自动化：能够自动分配子网，无需手动配置每个节点的网络。
3. 灵活封装：支持多种封装方式，适应不同网络环境。

局限性

1. 延迟和效率：在大规模集群中，由于封装和解封装可能带来延迟和性能开销。
2. 网络包膨胀：封装会增加数据包的额外头部，可能影响网络效率。

总结来说，Flannel 是 Kubernetes 和其他容器编排系统中的常见网络实现方案，通过创建覆盖网络，使得容器能够在不同节点之间自由通信，简化了容器网络管理和配置。

什么是Overlay网络

Overlay 网络和非 Overlay 网络(也称 Underlay 网络)是容器和虚拟机环境中常见的两种网络模型。下面将详细描述两者之间的区别、工作原理及其各自的优劣：

Overlay 网络(覆盖网络)

定义

Overlay 网络是一种虚拟网络，它在现有的物理网络(Underlay 网络)上层进行运行。Overlay 网络通过在数据包中封装额外的头部信息来实现这一虚拟化。

工作原理

• 封装和解封装：Overlay 网络通过将数据包封装(Encapsulation)在另一个协议之上进行传输。常见的封装协议包括 VXLAN、GRE 和 IPsec 等。数据包在源节点被封装，通过物理网络传输，到达目标节点后进行解封装，还原成原始数据包。
• 隧道(Tunnels)：数据包通过逻辑隧道进行传输，这些隧道在不同的物理节点之间创建虚拟链路，使得 Overlay 网络能够跨越多个节点和物理网络。

优点

1. 灵活性：可以无缝地跨越不同的物理网络。
2. 隔离性：提供更好的网络隔离，适合多租户环境。
3. 易于扩展：可以动态调整 Overlay 网络而无需改变底层物理网络。

缺点

1. 性能开销：封装和解封装增加了数据包的处理时间和开销。
2. 复杂性：增加了网络结构的复杂性，有时会导致排障变得更加困难。
3. 额外头部：封装协议增加了额外的头部信息，可能导致总体可用带宽降低。

示例

• Flannel (VXLAN 模式)：在 Kubernetes 集群中，Flannel 可以使用 VXLAN 进行数据包的封装和解封装，使得跨节点的 Pod 之间能够通信。
• Open vSwitch(与 VXLAN 配合)：可以在云环境中创建虚拟机的虚拟网络。

非 Overlay 网络(Underlay 网络)

定义

非 Overlay 网络是指直接在物理或虚拟网络上运行的网络，没有额外的封装和解封装过程。这个网络是实际存在的物理或虚拟网络。

工作原理

• 直接通信：数据包在物理网络中进行直接传输，没有额外的封装或解封装层。节点和节点之间通过实际存在的网络路径进行通信。
• 路由和交换：所有的网络路由和交换都是基于传统的 IP 路由表和二层交换协议(如 VLAN 等)进行的。

优点

1. 低开销：没有额外的封装和解封装步骤，数据包直接在物理网络上传输，性能较高。
2. 简单性：相对较为简单的网络结构，容易排障和管理。
3. 效率：由于没有封装开销，传输更加高效。

缺点

1. 灵活性差：变更物理网络结构通常较为困难，不能动态调整。
2. 隔离性差：相比 Overlay 网络，隔离效果较差，尤其是在多租户环境中。
3. 扩展性：扩展物理网络可能需要进行复杂的网络升级和配置。

示例

• 本地局域网(LAN)：企业内部网通常就是典型的 Underlay 网络。
• Kubernetes Host-GW 模式：在 Kubernetes 中，Host-GW 模式不进行数据包封装，而是直接通过主机的路由表进行路由。

Overlay 网络 vs. 非 Overlay 网络

特性	Overlay 网络	非 Overlay 网络
性能	较低，有封装和解封装开销	较高，没有额外封装步骤
灵活性	高，跨越不同物理网络	低，依赖物理网络结构
隔离性	高，多租户环境下更好	低，网络隔离效果较差
复杂性	高，网络排障和管理更复杂	低，结构简单，易于管理
扩展性	高，易于动态调整和扩展	低，物理网络调整难度大
频宽利用率	较低，有封装头部带来的额外负载	较高，没有额外负载

何时使用 Overlay 网络？

• 多租户环境：需要隔离不同租户的网络。
• 跨数据中心：需要在不同数据中心或云环境之间建立虚拟网络。
• 动态环境：需要频繁调整和扩展网络配置。

何时使用非 Overlay 网络？

• 高性能需求：需要最低的网络开销和最高的传输效率。
• 简单网络结构：企业内部网或其他简单的网络环境。
• 既有基础设施：已有物理网络配置已满足需求，无需额外的虚拟网络层。

综上所述，选择 Overlay 网络还是非 Overlay 网络取决于具体的需求、环境和使用场景。了解两者的原理及优劣，能够帮助您做出更适合您需求的选择。