Cilium CNI 用于 VNF/CNF 的高性能网络连接¶
介绍 Cilium CNI 用于 VNF/CNF 的高性能网络连接。
https://blueprints.launchpad.net/tacker/+spec/intro-cilium
问题描述¶
Tacker 的一个痛点在于，它默认情况下没有实现任何网络优化机制，而我们针对的是需要高性能网络连接的 vRAN 用例。可以通过 neutron 或 OVN 将专用的硬件加速设备（如 virtio 或 SR-IOV）附加到 VM 或容器。
然而，这种网络加速技术不太适合在分布式节点上运行大量实体以覆盖广泛数据平面的情况。特别是对于容器用例，由于虚拟设备的实现不够成熟或路由设计不如服务网格中已知的那样完善，因此更加困难。
Cilium 用于提供、保护和观察工作负载之间的网络连接，其动力源于革命性的内核技术 eBPF [1]。虽然网络吞吐量的性能不如其他技术，但与相比仍然不错。
用例¶
Cilium 支持多种网络用例，包括高性能 CNI、L4 负载均衡器或基于 eBPF 的 BGP。有效用法之一是避免传统服务网格的复杂性，如前一节所述。
Cilium Service Mesh 用于通过直接将网格层放入内核中使用 eBPF 来取代传统的服务网格框架，而无需 sidecar 代理。它管理网络层和应用协议层的连接，以更高的效率处理 IP、TCP、UDP、HTTP、Kafka、gRPC 和 DNS 等协议。
借助 Cilium 的多集群网络集群网格，您可以连接多个集群的网络，以便每个集群中的 Pod 可以发现并访问所有其他集群中的服务，前提是所有集群都将 Cilium 作为其 CNI [2]。这可以有效地将多个集群连接到一个大型统一网络，而无需考虑每个集群运行的 Kubernetes 发行版或位置。
虽然 Tacker 的服务范围有很多有用的示例用例，但我们专注于在此规范中作为示例实现的最基本的用例。在所有用例中，Tacker 能够将 VNF/CNF 部署到激活了 Cilium CNI 的节点上。
全功能一体化 devstack 环境上的单个 Kubernetes 节点¶
第一个用例是在全功能一体化 devstack 环境上部署单个 Kubernetes 节点。这是最简单的用例之一，主要用于开发以测试 Cilium 网络。
多节点 OpenStack 上的多节点 Kubernetes 集群¶
第二个用例是在多个 OpenStack 节点上部署多节点 Kubernetes 节点，以运行 Cilium 网络的一些更复杂或更真实的场景。
在此用例中，Kubernetes master 节点与 OpenStack controller 节点分离，因为 cilium 和 OpenStack 服务存在重复的默认端口。
来自 VNF 包的多节点 Kubernetes 节点¶
此规范中的最终用例是使用 Tacker 的 VNF 包部署多节点 Kubernetes 节点，以自动修复或自动扩展 OpenStack 节点，以运行 Cilium 网络的一些更复杂或更真实的场景。所有 Kubernetes 服务都在 OpenStack worker 节点上。
提议的变更¶
本规范的目的是介绍使用 eBPF 或 XDP 的 Cilium 网络的一些简单用例。我们需要更新 devstack 脚本以安装 Cilium，不仅在 Tacker 的 repo 中，还在 devstack-plugin-container 的 repo 中 [3]。
在此更新的 devstack 脚本中，CONTAINER_ENGINE 应该设置为 CRI-O，因为 Docker 不再作为 Kubelet 中的默认运行时支持，有时会导致问题。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
升级影响¶
无
实现¶
负责人¶
主要负责人
Yasufumi Ogawa <yasufum.o@gmail.com> <yasufumi.ogawa@ntt.com>
工作项¶
将容器运行时从 docker 替换为 CRI-O。
支持 devstack 脚本以安装 Cilium CNI，而不是 flannel。
修复 Kubernetes、容器运行时和 golang 版本兼容的组合。
禁用 kuryr-kubernetes。
依赖项¶
无
测试¶
无
文档影响¶
更新设置 cilium 的 devstack 设置指南。
添加用例概述作为介绍。
为每个用例添加部署说明作为详细说明。
添加 Cilium 使用指南，供运营商考虑诸如 Cilium 故障排除或直接使用 eBPF 功能等情况。
