首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

携程 Cilium+BGP 云原生网络实践

Cilium 是近两年最火的云原生网络方案之一。Cilium 的核心基于 eBPF,有两大亮点:基于 eBPF 的灵活、高性能网络,以及基于 eBPF 的 L3-L7 安全策略实现。

携程 2019 年开始在生产环境使用 Cilium,本文将介绍 Cilium 在携程的落地情况,以及我们基于 Cilium 的、覆盖虚拟机、物理机和容器的云原生安全的一些探索。

一、网络演进简要回顾

从 2013 年到 2018 年,我们经历了物理机到虚拟机再到容器的基础设施演进,但网络技术栈基本都是沿用 Neutron+OVS —— 即使对我们(前期)的 Kubernetes 集群也是如此。但业务开始往 Kubernetes 迁移之后,这套 Neutron+OVS 的网络方案越来越捉襟见肘,尤其是在部署密度更高、规模更大的容器面前,这种大二层网络模型的软件和硬件瓶颈暴露无遗 [1]。

为了解决这些问题,更重要的,为了满足云原生业务的各种需求(例如,支持 Kubernetes 的 Service 模型),我们调研了很多较新的网络方案,综合评估之后,选择了 Cilium+BGP 的组合 [3]。

Fig 1-1. Networking solutions over the past years [2]

Cilium+BGP 方案 2019 年底正式在生产环境落地,我们打通了 Cilium 网络和现有网络,因此能灰度将容器从 Neutron 迁移到 Cilium。

二、云原生网络实践

作为 Cilium 的早期用户之一,我们对 Cilium 的实现和部署做了一些修改或定制化,以使这套方案能平滑地落地到现有的基础设施之中,例如 [2],

1)用 docker-compsoe + salt 来部署,而不是采用默认的 daemonset+configmap 方式。

这样每台 node 上的 cilium-agent 都有独立配置,我们能完全控制发布灰度,将 变更风险降到最低。

2)用 BIRD 作为 BGP agent,而不是采用默认的 kube-router。

kube-router 开箱即用,但缺少对 ECMP、BFD 等高级功能的支持,不符合我们生产环境的要求。

3)为了保证某些业务的平滑迁移,我们开发了 StatefulSet/AdvancedStatefulSet 固定 IP 的支持(需要 sticky 调度配合)。

4)定制化了监控和告警。

5)其他一些自定义配置。

我们之前的一篇文章 [2] 对此有较详细的介绍,有兴趣可以移步。下面讨论几个之前介绍较少或者没有覆盖到的主题。

2.1 BGP 建连模型

Cilium+BIRD 方案中,以宿主机为界,网络可以大致分为两部分,如图 2-1 所示。

Fig 2-1. High level topology of the Cilium+BGP solution [2]

1)宿主机内部网络:由 Cilium(及内核协议栈)负责,职责包括:

  • 为容器创建和删除虚拟网络。
  • 为容器生成、编译和加载 eBPF。
  • 处理同宿主机内容器之间的网络通信。

2)跨宿主机网络:由 BGP(及内核路由模块)负责,职责包括:

  • 与数据中心网络交换路由(PodCIDRs)。
  • 对出宿主机的流量进行路由。

对于跨宿主机部分,需要确定要采用哪种 BGP peering 模型,这个模型解决的问题包括 :

1)BGP agent 的职责,是作为一个全功能路由控制服务,还是仅用作 BGP speaker?

2)宿主机和数据中心的哪些设备建立 BGP 邻居?

3)使用哪种 BGP 协议,iBGP 还是 eBGP?

4)如何划分自治域(AS),使用哪种 ASN(自治域系统编号)方案?

取决于具体的网络需求,这套 BGP 方案可能很复杂。基于数据中心网络能提供的能力及实际的需求,我们采用的是一种相对比较简单的模型:

1)每台 node 运行 BIRD,仅作为 BGP speaker。

  • Node 在上线时会自动分配一个 /25 或 /24 的 PodCIDR。
  • BIRD 和数据中心网络中的两个邻居建立 BGP 连接。
  • BIRD 将 PodCIDR 通告给邻居,但不从邻居接受任何路由。

2)数据中心网络只从 node 接受 /25 或 /24 路由宣告,但不向 node 宣告任何路由。

3)整张网络是一张三层纯路由网络(pure L3 routing network)。

这种模型的简单之处在于:

1)数据中心网络从各 node 学习到 PodCIDR 路由,了解整张网络的拓扑,因此 Pod 流量在数据中心可路由。

2)Node 不从数据中心学习任何路由,所有出宿主机的流量直接走宿主机默认路由(到数据中心网络),因此宿主机内部的路由表不随 node 规模膨胀,没有路由条目数量导致的性能瓶颈。

Fig 2-2. BGP peering model in 3-tier network topology

在路由协议方面:

  • 老数据中心基于“接入-汇聚-核心”三级网络架构,如图 2-2 所示,
  • 节点和核心交换机建立 BGP 连接。
  • 使用 iBGP 协议交换路由。
  • 新数据中心基于 Spine-Leaf 架构,
  • 节点和直连的 Leaf 交换机(置顶交换机)建立 BGP 连接。
  • 使用 eBGP 协议交换路由。

我们已经将这方面的实践整理成文档,见 Using BIRD to run BGP [3]。

2.2 典型流量转发路径:从 Pod 访问 Service

来看一下在这套方案中,典型的流量转发路径。

假设从一个 Pod 内访问某个 Service,这个 Service 的后端位于另一台 Node,如下图所示:

Fig 2-3. Traffic path: accessing Service from a Pod [4]

主要步骤:

1)在 Node1 上的 Pod1 里面访问某个 Service (curl <ServiceIP>:<port>)。

2)eBPF 处理 Service 抽象,做客户端负载均衡:选择某个后端,然将包的目的 IP 地址从 ServiceIP 换成后端 PodIP(即执行 DNAT)。

3)内核路由决策:查询系统路由表,根据包的目的 IP 地址确定下一跳;对于这个例子匹配到的是默认路由,应该通过宿主机网卡(或 bond)发送出去。

4)包到达宿主机网卡(bond),通过默认路由发送到宿主机的默认网关(配置在数据中心网络设备上)。

5)数据中心网络对包进行路由转发。由于此前数据中心网络已经从各 Node 学习到了它们的 PodCIDR 路由,因此能根据目的 IP 地址判断应该将包送到哪个 Node。

6)包达到 Node 2 的网卡(bond):一段 eBPF 代码负责提取包头,根据 IP 信息找到 另一段和目的 Pod 一一对应的 eBPF 代码,然后将包交给它。

7)后一段 eBPF 代码对包执行 入向策略检查,如果允许通过,就将包交给 Pod4。

8)包到达 Pod4 的虚拟网卡,然后被收起。

我们有一篇专门的文章详细介绍整个过程,见 [4]。

2.3 集群边界 L4/L7 入口解决方案

在 Kubernetes 的设计中,ServiceIP 只能在集群内访问,如果要从集群外访问 Service 怎么办?例如,从 baremetal 集群、OpenStack 集群,或者其他 Kubernetes 集群访问?这属于集群边界问题。

K8s 为这些场景提供了两种模型:

1)L7 模型:称为 Ingress,支持以 7 层的方式从集群外访问 Service,例如通过 HTTP API 访问。

2)L4 模型: 包括 externalIPs Service、LoadBalancer Service,支持以 4 层的方 式访问 Service,例如通过 VIP+Port。

但是,K8s 只提供了模型,没提供实现,具体的实现是留给各厂商的。例如,假如你使用的是 AWS,它提供的 ALB 和 ELB 就分别对应上面的 L7 和 L4 模型。在私有云,就需要我们自己解决。

我们基于 Cilium+BGP+ECMP 设计了一套四层入口方案。本质上这是一套四层负载均衡器(L4LB),它提供一组 VIP,可以将这些 VIP 配置到 externalIPs 类型或 LoadBalancer 类 型的 Service,然后就可以从集群外访问了。

Fig 2-4. L4LB solution with Cilium+BGP+ECMP [5]

基于这套四层入口方案部署 istio ingress-gateway,就解决了七层入口问题。从集群外访问时,典型的数据转发路由如下:

Fig 2-5. Traffic path when accesing Service from outside the Kubernetes cluster [5]

我们之前有篇博客详细介绍这个主题,见 [5]。

三、云原生安全尝试

Cilium 提供的两大核心能力:

1)基于 eBPF 的灵活、动态、高性能网络。

2)L3-L7 安全策略:CiliumNetworkPolicy 是对 K8s 的 NetworkPolicy 的扩展。

在落地了网络功能后,针对安全需求,我们在尝试落地基于 Cilium 的安全。

3.1 Cilium 安全策略

首先来看一个简单的例子,看看 CiliumNetworkPolicy (CNP) 长什么样 [6]:

代码语言:javascript
复制
apiVersion: "cilium.io/v2"kind: CiliumNetworkPolicymetadata:  name: "clustermesh-ingress-l4-policy"  description: "demo: allow only employee to access protected-db"spec:  endpointSelector:    matchLabels:      app: protected-db  ingress:  - toPorts:    - ports:      - port: "6379"        protocol: TCP    fromEndpoints:      - matchLabels:          app: employee

复制代码

上面的 yaml:

</pre>

1)创建一个 CNP,可以指定 name 和 description 等描述字段。

2)对带 app=protected-db 标签(labels)的 endpoints(pods)执行这个 CNP。

3)在执行 CNP 的时候,只对入向(ingress)流量做控制,并且限制如下流量来源:

  • 协议是 TCP,并且端口是 6379.
  • 流量来自带 app:employee labels 的 endpoints(pods)。

可以看到,CNP 非常灵活,使用起来也很方便。但真实世界要远比想象中复杂,要真正落地 Cilium 安全策略,还存在很多挑战。

3.2 落地挑战

下面举两个例子,相信这些问题在很多公司都需要面对,并不是我们独有的。

多集群问题

如果你所有的应用都运行在 Cilium 集群中,并且客户端和服务端都收敛到一个集群(大部分公有云厂商都推荐一个 region 只部署一套 K8s 集群,所有访问都收敛到这套集群),那落地起来会简单很多。

但大部分有基础设施演进的公司恐怕都不满足这个假设,实际的情况很可能是:业务分散在多个集群。

混合基础设施

多集群还不是最大的问题,因为业界多少还有一些多集群解决方案。

更严重的一个问题是:业务不仅分散在不同集群,而且在不同平台。例如对我们来说,现在有:

1)Bare metal 集群

2)OpenStack 集群

3)基于 Neutron+OVS 的 Kubernetes 集群

4)基于 Cilium+BGP 的 Kubernetes 集群

虽然我们计划将所有容器从 Neutron 网络迁移到 Cilium 网络,但另外两种,bare metal 和 OpenStack 集群,还是会长期存在的,虽然规模可能会逐渐减小。

3.3 整体方案设计

我们目前的一个整体方案:在服务端容器做入向安全策略,客户端可以来自任何平台、任何集群:

1)这将范围框定到了已经在 Cilium 网络的服务端容器,是一个不错的起点。

2)传统网络里的服务端容器,会逐渐迁移到 Cilium 网络。

3)BM 和 VM 的服务端实例,第一阶段先不考虑安全控制。

那接下来的问题就是:服务端如何具备对所有类型、所有集群的客户端进行限制的能力?我们的解决方案是:

1)首先,用 Cilium 提供 ClusterMesh 将已有 Cilium 集群连接起来;

2)然后,“扩展” ClusterMesh,让它能感知到 mesh 之外的 endpoints,即 BM、BM 和 Neutron Pods。

下面分别解释这两点。

3.3.1 用 ClusterMesh 做 Cilium 集群互连

Fig 3-1. Vanilla Cilium ClusterMesh [6]

ClusterMesh [7] 是 Cilium 自带的一个多集群解决方案。如果所有应用都在 Cilium 集群 里,那这种方式可以解决跨集群的安全策略问题,即,application 实例可以分布在不同的集群。

这样说来,使用 ClusterMesh 似乎是理所当然的,但其实它并不是我们当初的第一选择。因为多集群还有其他方案,本质上做的事情就是如何在多个集群之间同步元数据,并且做到集群变动的实时感知。

1)出于多个内部需求,当时有考虑自己做这样一套元数据同步方案,它能解决包括 Cilium 在内的多个需求。

2)并未看到业界大规模使用 ClusterMesh 的案例,所以对它的可用性还存疑。

但后来综合对比了几种选项之后,觉得 ClusterMesh 还是值得尝试的。

关于 ClusterMesh 的实地(功能)测试,可以参考我们之前的一篇博客 [6]。

3.3.2 扩展 ClusterMesh,感知 mesh 外实例

这里的外部实例(external endpoints)包括 Neutron Pod、VM、BM。

基于对 Cilium 的理解,我们判断只要将外部实例信息以 Cilium 能感知的方式(格式)同步到 Cilium 集群,那在入向(inbound),Cilium 对这些实例的控制能力,与对原生 Cilium 实例的控制能力并无区别。换句话说,我们“骗一下” Cilium,让它认为这些实例都是 Cilium endpoints/pods。

为此我们开发了一个组件,使得 OpenStack 平台、Bare metal 平台和 Neutron-powered Kubernetes 平台能将它们的实例创建/销毁/更新信息同步更新到 Cilium 集群,如下图所示:

Fig 3-2. Proposed security solution over hybrid infrastructures

结合 3.3.1 & 3.3.2,在这套“扩展之后的” ClusterMesh 中,每个 Cilium agent 都对全局实例(container/vm/bm)有着完整的、一致的视图,因此能在 Cilium Pod 的入向对各种类型的客户端做安全控制。目前计划支持的是 L3-L4 安全策略,未来考虑支持 L7。

这套方案已经通过了功能验证,正在进行正式开发和测试,计划年底开始灰度上线。

四、总结

本文总结了我们在基于 Cilium 的云原生网络和云原生安全方面的一些探索和实践。更多技术细节,可参考下面一些链接。

参考文献

[1] Ctrip Network Architecture Evolution in the Cloud Computing Era

[2] Trip.com: First Step towards Cloud Native Networking.

[3] Cilium Doc: Using BIRD to run BGP

[4] Life of a Packet in Cilium: Discovering the Pod-to-Service Traffic Path and BPF Processing Logics

[5] L4LB for Kubernetes: Theory and Practice with Cilium+BGP+ECMP

[6] Cilium ClusterMesh: A Hands-on Guide

[7] Cilium Doc: clustermesh

作者介绍

Arthur,Stephen,Jaff,Weir,几位均来自携程云平台基础设施和网络研发团队,目前专注于网络和云原生安全相关的开发。

本文转载自公众号携程技术(ID:ctriptech)。

原文链接

携程 Cilium+BGP 云原生网络实践

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/jj6YBLwevT7jQ5ldUeZo
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券