[译]Kubernetes Multi-Cluster Networking -Cilium Cluster Mesh

[译]Kubernetes Multi-Cluster Networking -Cilium Cluster Mesh

前言

本文翻译至海外博客，本篇只为学习用途。原文连接：https://itnext.io/kubernetes-multi-cluster-networking-cilium-cluster-mesh-bca0f5367d84

在动态变化且非常复杂的微服务生态系统时代，传统的IP和端口管理可能会在管理和扩展角度提出问题。 Cilium使用BPF来转发Linux内核中的数据，并且可以通过代理注入将其用于服务网格，例如Kubernetes基于服务的负载平衡或istio。

BPF 即 Berkeley Packet Filter一样，最初是在1992年构思的，目的是提供一种过滤数据包的方法，并避免从内核到用户空间的无用数据包副本。Extended BPF（eBPF）是对BPF（现在称为cBPF，代表传统BPF）的增强，具有增强的资源，例如10个寄存器和1-8字节加载/存储指令。 BPF具有向前跳转，而eBPF具有向后跳转和向前跳转，因此可以有一个循环，当然，内核可以确保正确终止。

如今，诸如x86_64，arm64，ppc64和s390之类的体系结构具有从eBPF程序中编译本机操作码映像的能力，因此，生成的映像可以像其他任何程序一样本地运行，而不是通过内核内eBPF解释器执行。内核代码。然后，tc将程序安装到内核的网络数据路径中，并且借助功能强大的NIC，也可以将程序完全卸载到硬件中
。
Kubernetes使用iptables作为CNI的核心。 iptables存在许多重大问题，这些问题在各种流量情况下都会产生问题。 iptable规则是按顺序匹配的，并且iptables的更新必须通过在单个事务中重新创建和更新所有规则来完成，而这些事务可能不适合高度动态的容器空间。如果数据包经常违反表下部的规则，则性能尤其会受到影响。另一方面，BPF与“最接近”的规则匹配，而不是通过遍历整个规则集来进行匹配，这使其非常适合网络策略的实施。
Cilium提供了内置的多层（pod-ip路由，服务发现和负载平衡等）功能，用户可以选择使用所有层，也可以根据需要选择和仅使用这些层。

Cilium CNI Implementation

Cilium agent ，Cilium CLI Client 和CNI Plugin 在群集中的每个节点上运行（部署为守护程序集）。 Cilium CNI插件执行与网络管道相关的所有任务，例如创建链接设备（对），为容器分配IP，配置IP地址，路由表，sysctl参数等。Cilium代理编译BPF程序并使内核在以下位置运行这些程序网络堆栈中的关键点。

Cilium提供两种联网模式：

1.Overlay Network Mode：最常用的默认网络模式。群集中的所有节点都使用基于udp的封装协议（VXLAN（默认）或Geneve）进行隧道网格划分。在这种模式下，用户无需使用kube-controller-manager中的“ -allocate-node-cidrs”选项，Cilium即可自动形成覆盖网络，而无需用户进行任何配置。

2.Direct/Native Routing Mode 直接/本机路由模式：在这种配置中，Cilium将所有未为另一个本地端点寻址的数据包移交给linux内核的路由子系统。此设置需要一个附加的路由守护程序，例如Bird，Quagga，BGPD，Zebra等，以通过节点的IP向所有其他节点声明非本地节点分配前缀。与VxLAN覆盖相比，BGP解决方案具有更好的性能，更重要的是，它使容器IP可路由，而无需任何额外的网格配置。

考虑到默认的网络模式和Kubernetes CNI的实现，Cilium支持VETH / IPVLAN作为链接设备。

Cilium在主机网络空间上创建了三个虚拟接口：cilium_host，cilium_net和cilium_vxlan。 Cilium agent在启动时会创建一个名为“ cilium_host←cilium_net”的veth pair，并将CIDR的第一个IP地址设置为cilium_host，然后它充当CIDR的网关。 CNI plugin 将生成BPF规则，将其编译并将