BGP 模式下 Calico 与 MetalLB 的组合

最新推荐文章于 2025-03-03 21:51:32 发布

魔哈AI仓库

最新推荐文章于 2025-03-03 21:51:32 发布

阅读量722

点赞数

分类专栏：云原生小白文章标签： kubernetes 运维网络

本文链接：https://blog.youkuaiyun.com/weixin_49366475/article/details/124729179

版权

本文详细记录了在新机房中如何选择和部署Calico CNI，以及如何配合MetalLB实现BGP网络架构，以支持Kubernetes的Pod-Pod、Node-Pod和Node-Loadbalancer间的网络互访。涉及CNI选型对比、Calico配置、MetalLB部署及BGP策略应用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

最近我司业务扩展在机房新开了一个区域，折腾了一段时间的 Calico BGP，为了能将整个过程梳理得更简单明了，我还是决定将这个过程记录下来。不管是对当下的总结还是未来重新审视方案都是值得的。大家都知道，云原生下的网络架构在 Kubernetes 里可以算是百花齐放，各有所长，这无形中也导致网络始终是横在广大 K8S 爱好者面前迈向高阶管理的几座大山之一。通常大家在公有云上使用厂家提供的 CNI 组件可能还感受不到其复杂，但一旦要在 IDC 自建集群时，就会面临 Kubernetes 网络架构选型的问题。 Calico 作为目前 Kubernetes 上用途最广的 Kubernetes CNI 之一，自然也有很多追随者。而本篇便是在自建机房内 BGP 组网下的一次总结。

关于 CNI 选型

云原生 CNI 组件这么多，诸如老牌的 Flannel、Calico、WeaveNet、Kube-Router 以及近两年兴起的 Antrea、 Kube-OVN 和 Cilium。它们都在各自的场景下各有所长，在选择前我们可以先对其做一个简单的功能性的比较:

	Flannel	Calico	Cilium	WeaveNet	Antrea	Kube-OVN
部署模式	DaemonSet	DaemonSet	DaemonSet	DaemonSet	DaemonSet	DaemonSet
包封装与路由	VxLAN	IPinIP,BGP,eBPF	VxLAN,eBPF	VxLAN	Vxlan	Vlan/Geneve/BGP
网络策略	No	Yes	Yes	Yes	Yes	Yes
存储引擎	Etcd	Etcd	Etcd	No	Etcd	Etcd
传输加密	Yes	Yes	Yes	Yes	Yes	No
运营模式	社区	Tigera	社区	WeaveWorks	VMware	灵雀云

说明：传输加密主要以支持 WireGuard 或 IPSec 来评估

此外关于CNI 性能部分，我们也可以透过一份 2020 年的 CNI 性能测试报告《Benchmark results of Kubernetes network plugins (CNI) over 10Gbit/s network》来选择。

上述性能测试原始数据：https://docs.google.com/spreadsheets/d/12dQqSGI0ZcmuEy48nA0P_bPl7Yp17fNg7De47CYWzaM/edit?ouid=118246426051561359914&usp=sheets_home&ths=true

为什么选择 Calico

在对我司机房新区域的网络选型上，我们最终选择了 Calico 作为云端网络解决方案，在这里我们简单阐述下为什么选择 Calico 的几点原因：

支持 BGP 广播，Calico 通过 BGP 协议广播路由信息，且架构非常简单。在 kubernetes 可以很容易的实现 mesh to mesh 或者 RR 模式，在后期如果要实现容器跨集群网络通信时，实现也很容易。
Calico配置简单，且配置都是通过 Kubernetes 中的 CRD 来进行集中式的管理，通过操作 CR 资源，我们可以直接对集群内的容器进行组网和配置的实时变更
丰富的功能及其兼容性，考虑到集群内需要与三方应用兼容，例如配置多租户网络、固定容器 IP 、网络策略等功能又或者与 Istio、MetalLB、Cilium 等组件的兼容，Calico 的的表现都非常不错
高性能， Calico 的数据面采用 HostGW 的方式，由于是一个纯三方的数据通信，所以在实际使用下性能和主机资源占用方面不会太差，至少也能排在第一梯队

结合我司机房新区域采购的是 H3C S9 系列的交换机，支持直接在接入层的交换机侧开启路由反射器。所以最终我们选择Calico 并以 BGP RR 的模式作为 Kubernetes 的 CNI 组件便水到渠成。

关于 MetalLB

在讲 MetalLB 之前，先回顾下应用部署在 Kubernetes 中，它的下游服务是如何访问的吧。通常有如下几种情况

集群内请求:

直接通过 Kubernetes 的 Service 访问应用。

集群外请求：

通过 NodePort 在主机上以 nat 方式将流量转发给容器，优点配置简单且能提供简单的负载均衡功能，缺点也很明显下游应用只能通过主机地址+端口来做寻址
通过 Ingress-nginx 做应用层的 7 层转发，优点是路由规则灵活，且流量只经过一层代理便直达容器，效率较高。缺点是 ingress-nginx 本身的服务还是需要通过 NodePort 或者 HostNetwork 来支持

可以看到在没有外部负载均衡器的引入之前，应用部署在 kubernetes 集群内，它对南北向流量的地址寻址仍然不太友好。也许有的同学就说了，我在公有云上使用 Kubernetes 时，将 Service