kube-OVN总体架构

Posted 2023-03-30 竹杖芒鞋轻胜马，谁怕？一蓑烟雨任平生。

本文档将介绍 Kube-OVN 的总体架构，和各个组件的功能以及其之间的交互。

总体来看，Kube-OVN 作为 Kubernetes 和 OVN 之间的一个桥梁，将成熟的 SDN 和云原生相结合。 这意味着 Kube-OVN 不仅通过 OVN 实现了 Kubernetes 下的网络规范，例如 CNI，Service 和 Networkpolicy，还将大量的 SDN 领域能力带入云原生，例如逻辑交换机，逻辑路由器，VPC，网关，QoS，ACL 和流量镜像。

1. 组件介绍

Kube-OVN 的组件可以大致分为三类：

• 上游 OVN/OVS 组件。
• 核心控制器和 Agent。
• 监控，运维工具和扩展组件。
  

2.上游 OVN/OVS 组件

该类型组件来自 OVN/OVS 社区，并针对 Kube-OVN 的使用场景做了特定修改。 OVN/OVS 本身是一套成熟的管理虚机和容器的 SDN 系统，我们强烈建议 对 Kube-OVN 实现感兴趣的用户先去读一下 ovn-architecture(7) 来了解什么是 OVN 以及 如何和它进行集成。Kube-OVN 使用 OVN 的北向接口创建和调整虚拟网络，并将其中的网络概念映射到 Kubernetes 之内。

所有 OVN/OVS 相关组件都已打包成对应镜像，并可在 Kubernetes 中运行。
ovn-central
ovn-central Deployment 运行 OVN 的管理平面组件，包括 ovn-nb, ovn-sb, 和 ovn-northd。

• ovn-nb： 保存虚拟网络配置，并提供 API 进行虚拟网络管理。kube-ovn-controller 将会主要和 ovn-nb 进行交互配置虚拟网络。
• ovn-sb： 保存从 ovn-nb 的逻辑网络生成的逻辑流表，以及各个节点的实际物理网络状态。
• ovn-northd：将 ovn-nb 的虚拟网络翻译成 ovn-sb 中的逻辑流表。

多个 ovn-central 实例会通过 Raft 协议同步数据保证高可用。

ovs-ovn
ovs-ovn 以 DaemonSet 形式运行在每个节点，在 Pod 内运行了 openvswitch, ovsdb, 和 ovn-controller。这些组件作为 ovn-central 的 Agent 将逻辑流表翻译成真实的网络配置。

3. 核心控制器和 Agent

该部分为 Kube-OVN 的核心组件，作为 OVN 和 Kubernetes 之间的一个桥梁，将两个系统打通并将网络概念进行相互转换。 大部分的核心功能都在该部分组件中实现。

• kube-ovn-controller
  该组件为一个 Deployment 执行所有 Kubernetes 内资源到 OVN 资源的翻译工作，其作用相当于整个 Kube-OVN 系统的控制平面。 kube-ovn-controller 监听了所有和网络功能相关资源的事件，并根据资源变化情况更新 OVN 内的逻辑网络。主要监听的资源包括： Pod，Service，Endpoint，Node，NetworkPolicy，VPC，Subnet，Vlan，ProviderNetwork。

以 Pod 事件为例， kube-ovn-controller 监听到 Pod 创建事件后，通过内置的内存 IPAM 功能分配地址，并调用 ovn-central 创建 逻辑端口，静态路由和可能的 ACL 规则。接下来 kube-ovn-controller 将分配到的地址，和子网信息例如 CIDR，网关，路由等信息写会到 Pod 的 annotation 中。该 annotation 后续会被 kube-ovn-cni 读取用来配置本地网络。

• kube-ovn-cni
  该组件为一个 DaemonSet 运行在每个节点上，实现 CNI 接口，并操作本地的 OVS 配置单机网络。

该 DaemonSet 会复制 kube-ovn 二进制文件到每台机器，作为 kubelet 和 kube-ovn-cni 之间的交互工具，将相应 CNI 请求 发送给 kube-ovn-cni 执行。该二进制文件默认会被复制到 /opt/cni/bin 目录下。

kube-ovn-cni 会配置具体的网络来执行相应流量操作，主要工作包括：

1. 配置 ovn-controller 和 vswitchd。
2. 处理 CNI add/del 请求：
3. 创建删除 veth 并和 OVS 端口绑定。
4. 配置 OVS 端口信息。
5. 更新宿主机的 iptables/ipset/route 等规则。
6. 动态更新容器 QoS.
7. 创建并配置 ovn0 网卡联通容器网络和主机网络。
8. 配置主机网卡来实现 Vlan/Underlay/EIP 等功能。
9. 动态配置集群互联网关。

4. 监控，运维工具和扩展组件¶

该部分组件主要提供监控，诊断，运维操作以及和外部进行对接，对 Kube-OVN 的核心网络能力进行扩展，并简化日常运维操作。

• kube-ovn-speaker
  该组件为一个 DaemonSet 运行在特定标签的节点上，对外发布容器网络的路由，使得外部可以直接通过 Pod IP 访问容器。

• kube-ovn-pinger
  该组件为一个 DaemonSet 运行在每个节点上收集 OVS 运行信息，节点网络质量，网络延迟等信息，收集的监控指标可参考 Kube-OVN 监控指标。

• kube-ovn-monitor
  该组件为一个 Deployment 收集 OVN 的运行信息，收集的监控指标

• kubectl-ko
  该组件为 kubectl 插件，可以快速运行常见运维操作

kube-ovn underlay vlan 模式 默认网络使用lb

参考技术A 关于lb一般要支持以下功能：

在当前服务架构中，负载均衡设备(或者代理设备)常被使用，当我们使用了负载均衡/代理设备之后，服务器端通常看到的是代理设备的IP地址。在HTTP协议下，通常在代理设备上会追加X-Forward-For头，用于存放原始客户端的IP地址，这样服务器端可以看到原始客户端IP。但是在UDP/TCP四层情况下，不存在可以追加Client IP信息的字段。Proxy Protocol是可以用来解决UDP/TCP四层情况下服务器端获取IP地址的问题。他工作在4层和7层之间，追加了一个Proxy Protocol头部，用于记录客户端地址信息。

代理协议(Proxy protocol)，是HAProxy的作者Willy Tarreau于2010年开发和设计的一个Internet协议，通过为tcp添加一个很小的头信息，来方便的传递客户端信息（协议栈、源IP、目的IP、源端口、目的端口等)，在网络情况复杂又需要获取用户真实IP时非常有用。

代理协议分为V1和V2两个版本，V1是人类易读的，V2是二进制格式的。

注意点：
Proxy protocol需要两个角色sender和receiver,
sender在与receiver之间建立连接后，会先发送一个带有客户信息的tcp header,
因为更改了tcp协议，需receiver也支持Proxy protocol，否则不能识别tcp包头，导致无法成功建立连接。

二、 kube-ovn 关于lb的使用

ovn 关于lb的设计有两种，使用方式： https://hustcat.github.io/ovn-lb-practice/
，

router-lb
switch-lb

ovn lb的初始化

如上 kube-ovn underlay vlan default网络pod访问svc直接走的是logic switch lb 走dnat 访问到 svc对应的后端 pod 的endpoint

当前基于provider ovs 网桥多加一个host ns上的网卡也可以用来中转访问svc，就像ipvlan的hostns中的子接口的作用一样。

扩展：

ovn lb 支持udp 和 tcp，ipv6应该也已经支持了，但是不支持proxy protocol

注意点：

ovn router lb 需要额外的vpc subnet ip 来构造tcp udp的健康检查包，所以会多消耗一倍的vpc 后端ip

参考：