[译]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规则，将其编译并将其注入内核以弥合veth pairs 的差距。

[译者注解：pod内的eth0 设备和node 节点上的lxc-xxx，组成1对 veth pair；
pod 内的默认路由指向 cilium_host_ip; ]

如上所示，创建Pod时，在根名称空间上创建带有“ lxc-xx”的VETH接口，另一端连接到Pod名称空间。 Pod的默认网关指向“ cilium_host” IP，Cilium代理安装所需的BPF程序以回复ARP请求。 LXC接口MAC用于ARP应答。 Pod生成的流量的下一个L3跳是cilium_host，而Pod生成的流量的下一个L2跳是这台主机和veth pair 。
[译者注，即2层通信就直接通过veth pair 经过cilium agent 完成转发；]

在多主机联网中，如果使用VxLAN，则Cilium将在每个主机中创建一个cilium_vxlan设备，并通过软件进行VxLAN封装/分离.Cilium在元数据模式下使用VXLAN设备，这意味着它可以在多个地址上发送和接收.Cilium将使用它找到的第一个公用IPv4地址为VXLAN VTEP。 Cilium使用BPF进行LWT（轻型隧道）封装，并且pod发出的所有网络数据包都封装在标头中，该标头可以由VXLAN或Geneve帧组成，并通过标准UDP数据包标头进行传输。

如上所示，在多主机网络设置中，Cilim在节点之间创建隧道，而隧道端点映射由Cilium编程。

Cilium Cluster Mesh

ClusterMesh是Cilium的多集群实施。 ClusterMesh通过隧道或直接路由，以本机性能促进跨多个Kubernetes集群的Pod IP路由，而无需任何网关或代理。
使用Vultr上不同区域中的三个不同的AIO（master + worker）Kubernetes集群试用ClusterMesh：

Cilium CNI安装在每个具有唯一/不重叠Pod_CIDR的堆栈上，如下所示：

每个集群中的Cilium堆栈包含一个部署为守护程序的Cilium agent，该守护程序侦听Kubernetes集群中的事件以了解何时创建或删除容器，并创建自定义的BPF程序，Linux内核用于控制进出这些程序的所有网络访问容器。 Cilium运营商管理一次性任务，例如Kubernetes服务与Clusterd的etcd同步以及集群中的其他任务（对于整个集群而言，逻辑上应处理一次）。 Cilium可以扩展到超过500个节点。

Cilium agent 配置以ConfigMap的形式提供，并包含所需的配置以及“ cluster-id”和“ cluster-name”，以在多集群设置中唯一地标识集群。

Cluster Mesh的先决条件之一是管理Cilium的etcd，而etcd运算符用于保证仲裁，自动创建证书和管理压缩。 etcd可以通过任何其他方式进行管理，但是Cluster Mesh需要某些方面才能在集群之间进行状态传播。
cilium-etcd-operator使用并扩展etcd-operator在集群上创建和管理etcd。如果仲裁失败，操作员将始终确保维持仲裁，并重新创建etcd-cluster：

每个Kubernetes集群都维护自己的etcd集群，其中包含该集群的状态。来自多个群集的状态永远不会混入etcd中。在其他集群中运行的Cilium agent 连接到etcd代理以监视更改，并将多集群相关状态复制到自己的集群中。群集网格中的etcd应该公开为LoadBalancer或NodePort。这使Cilium可以在群集之间同步状态，并提供跨群集连接和策略实施。

Cilium agent 将使用预定义的命名模式“ {clustername} .mesh.cilium.io”连接到远程集群中的etcd。为了使DNS解析和TLS身份验证可以在这些虚拟主机名上运行，这些名称会在守护程序规范中使用“主机别名”静态映射到服务IP。对于上面的拓扑，配置如下所示：

由于跨集群etcd使用TLS，因此会在集群网格的所有集群部分上创建一个Kubernetes Secret，该集群包含多集群环境中所有其他etcd的证书和密钥。

使用上面显示的跨集群配置，Cilium代理在所有其他集群之间形成隧道。例如，上面拓扑中的cluster-atlanta创建了通往cluster-singapore和cluster-toronto的隧道，如下所示：

集群大西洋上的Cilum agent 在其他群集（新加坡和多伦多）的Public_IP的端口：4240上具有入站和出站连接（cilium-agent）。

Cilium config保留隧道模式，该模式可方便用户提供要使用的隧道方案，在上述情况下，将使用默认的VXLAN：

Cilium agent 使用从节点列表（群集网格中所有节点的列表）派生的特定群集的Pod_CIDR和群集的Public_IP（隧道端点）来制定隧道端点映射。例如，在隧道模式下，将在cluster-atlanta和cluster-singapore之间创建隧道，如下所示：

在其他受支持的直接路由模式下，数据包将直接打入网络。 Cilium具有kube-router集成，可运行BGP路由守护程序进行路由传播。在此模式下，消除了VXLAN开销（{SrcPodIP} {DstPodIP} {有效负载}）。

Cilium agent使用Public_IP和cilium_host_IP建立隧道，如下所示：


拓扑中三个集群的节点列表和端点如下所示：

Multi-node Pod-Pod Packet Flow

多节点Pod-Pod数据包流

所有Pod流量在退出和进入节点之前都要通过“ cilium_vxlan”界面。 cilium_vxlan设备执行VXLAN encap / decap。

Cilium agent 安装了BPF程序来答复ARP请求，而LXC接口MAC用于ARP答复。从cluster-atlanta（10.217.0.67）上的Pod ping到cluster-toronto（10.219.0.25）：

基础主机接口上的VXLAN数据包— ens3：

在“ cilium_vxlan”接口上对VXLAN数据包进行解析：

根名称空间上的LXC接口附加到Pod应答ARP请求：

Testing Multi-cluster Pod Interconnectivity with YugaByteDB

使用YugaByteDB测试多集群Pod互连性

YugabyteDB是一个符合ACID的分布式数据库，它将云原生微服务的三个必备需求汇集在一起​​，即SQL作为一种灵活的查询语言，低延迟的读取性能和全局分布的写入可伸缩性。

YugabyteDB使用户可以通过同步或多主复制来跨区域和云进行部署。在下面的拓扑中，来自cluster-singapore和cluster-toron的YB-Server加入运行在cluster-atlanta上的YB-Master。这只是测试Pod的互连性，而不是默认/受支持的部署模式。

YugabyteDB主服务器与同一集群中的本地服务器一起部署在集群-大西洋上：

YugabyteDB门户显示集群-大西洋上的主服务器和本地服务器：


YugabyteDB服务器部署在cluster-singapore和cluster-toronto上，这两个服务器都配置为加入Cluster-atlanta上的YugabyteDB master。如下所示，不同子网（10.218.0.0/24和10.219.0.0/24）中的两个服务器都具有到cluster-atlanta（10.217.0.30）的出站连接。

YugabyteDB门户显示了来自不同Kubernetes集群的集群中的其他两个活动服务器：

Multi-Cluster Network Policy — Limiting Pod-Pod Communication between Clusters

多群集网络策略-限制群集之间的Pod-Pod通信

在每台主机上运行的Cilium Agent无需管理IP表，而是将网络策略定义转换为BPF程序，这些程序已加载到内核中并附加到容器的虚拟以太网设备。这些程序在发送或接收的每个数据包上执行。
在具有集群网格的多集群环境中，集群名称通过标签“ io.cilium.k8s.policy.cluster”公开，可用于将策略限制为特定集群。

允许从cluster-atlanta上的YB-Master到cluster-singapore和cluster-toronto上的YB-Server的进出流量。
出口允许规则匹配的标签：app和clusters：cluster-name：

ingress 允许规则匹配的标签：app和clusters：cluster-name：


拒绝从新加坡群集上的YB服务器发出的所有出口，这将导致主服务器上的运行状况检查失败，并将服务器节点标记为已失效，如下所示：


Cilium 1.7提供了群集范围的CNP，可以在群集级别实施策略。使用最新的Hubble，用户可以使用多个过滤器可视化流上的细粒度信息，还可以通过添加注释使用户获得L7可见性，从而消除了为每个选定端点创建完整策略的负担。


Cluster Mesh可以有效地处理诸如高可用性之类的用例：通过集群级别的负载平衡，共享服务：可以在多个集群之间共享诸如监视，日志记录等服务集。整体Cilium Cluster Mesh可以大大降低运营复杂性每个租户运行单独的集群或为不同类别的服务构建集群并实现它们之间的互连。