kubeasz 集群中为 Calico 配置 BGP Route Reflectors 以支撑大规模节点-迪斯科星球

kubeasz 集群中为 Calico 配置 BGP Route Reflectors 以支撑大规模节点

【免费下载链接】kubeasz使用Ansible脚本安装K8S集群，介绍组件交互原理，方便直接，不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz

本指南以 kubeasz 部署的 K8S 集群为背景，系统讲解 Calico 网络插件中 BGP 路由反射器（Route Reflectors，简称 RR）的原理、适用场景与完整配置流程。读者将掌握两种启用方式：通过 kubeasz 配置项一键自动启用，以及使用 calicoctl 手工完成 RR 节点选取、BGPPeer 规则与全局 BGP 配置的完整操作，并学会用calicoctl node status验证连接收敛结果，为 50 节点以上的大规模集群提供可复制的扩展方案。

BGP Route Reflectors 解决了什么问题

Calico作为K8S的一个流行网络插件，依赖BGP路由协议实现集群节点上的POD路由互通；而路由互通的前提是节点间建立 BGP Peer 连接。在没有 RR 的默认部署中，Calico 采用 node-to-node mesh（BGP 全互联）模式，每个节点需要与集群中其他所有节点两两建立 BGP 连接。这种连接方式存在明显的扩展性问题：

没有 RR 时，所有节点之间需要两两建立连接（IBGP 全互联），节点数量增加将导致连接数剧增、资源占用剧增——n 个节点的连接数为 n×(n-1)/2，呈平方级增长；
引入 RR 后，其他 BGP 路由器只需要与 RR 建立连接并交换路由信息，节点数量增加连接数只是线性增加，大大节省系统资源。

calico-node 版本 v3.3 开始支持内建路由反射器，非常方便，因此使用 calico 作为网络插件可以支持大规模节点数的K8S集群。

建议集群节点数大于 50 时，应用 BGP Route Reflectors 特性。

RR 的引入意味着 BGP 拓扑从"全互联网状"变为"星型汇聚"：普通节点只与 RR 建立连接，RR 之间再互相建立连接交换各自客户端的路由。这样每个普通节点只需要维护 1 个（或 2～3 个，用于冗余）BGP 对等连接，BGP 会话数量大幅下降，calico-node中内建的 BIRD 进程的维护成本也随之降低。

前提条件与初始环境检查

k8s 集群使用 calico 网络插件部署成功。本文实验环境为按照 kubeasz 安装的 2 主 2 从集群，calico 版本 v3.19.4。首先确认集群节点与 calico 组件运行正常：

$ kubectl get node NAME STATUS ROLES AGE VERSION 192.168.1.1 Ready,SchedulingDisabled master 178m v1.13.1 192.168.1.2 Ready,SchedulingDisabled master 178m v1.13.1 192.168.1.3 Ready node 178m v1.13.1 192.168.1.4 Ready node 178m v1.13.1 $ kubectl get pod -n kube-system -o wide | grep calico calico-kube-controllers-77487546bd-jqrlc 1/1 Running 0 179m 192.168.1.3 192.168.1.3 <none> <none> calico-node-67t5m 2/2 Running 0 179m 192.168.1.1 192.168.1.1 <none> <none> calico-node-drmhq 2/2 Running 0 179m 192.168.1.2 192.168.1.2 <none> <none> calico-node-rjtkv 2/2 Running 0 179m 192.168.1.4 192.168.1.4 <none> <none> calico-node-xtspl 2/2 Running 0 179m 192.168.1.3 192.168.1.3 <none> <none>

可以看到每个节点上运行一个calico-nodePod（2/2 Running，包含 calico-node 主容器与 CNI 插件容器），另有全局唯一的calico-kube-controllers负责控制器逻辑。

查看当前集群中 BGP 连接情况

通过 kubeasz 提供的批量执行工具，在所有节点上运行 calicoctl 查看 BGP 状态：

$ dk ansible -i /etc/kubeasz/clusters/xxx/hosts all -m shell -a '/opt/kube/bin/calicoctl node status' 192.168.1.3 | SUCCESS | rc=0 >> Calico process is running. IPv4 BGP status +--------------+-------------------+-------+----------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+-------------------+-------+----------+-------------+ | 192.168.1.1 | node-to-node mesh | up | 03:08:20 | Established | | 192.168.1.2 | node-to-node mesh | up | 03:08:18 | Established | | 192.168.1.4 | node-to-node mesh | up | 03:08:19 | Established | +--------------+-------------------+-------+----------+-------------+ IPv6 BGP status No IPv6 peers found. 192.168.1.2 | SUCCESS | rc=0 >> Calico process is running. IPv4 BGP status +--------------+-------------------+-------+----------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+-------------------+-------+----------+-------------+ | 192.168.1.4 | node-to-node mesh | up | 03:08:17 | Established | | 192.168.1.3 | node-to-node mesh | up | 03:08:18 | Established | | 192.168.1.1 | node-to-node mesh | up | 03:08:20 | Established | +--------------+-------------------+-------+----------+-------------+ IPv6 BGP status No IPv6 peers found. 192.168.1.1 | SUCCESS | rc=0 >> Calico process is running. IPv4 BGP status +--------------+-------------------+-------+----------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+-------------------+-------+----------+-------------+ | 192.168.1.2 | node-to-node mesh | up | 03:08:21 | Established | | 192.168.1.3 | node-to-node mesh | up | 03:08:21 | Established | | 192.168.1.4 | node-to-node mesh | up | 03:08:21 | Established | +--------------+-------------------+-------+----------+-------------+ IPv6 BGP status No IPv6 peers found. 192.168.1.4 | SUCCESS | rc=0 >> Calico process is running. IPv4 BGP status +--------------+-------------------+-------+----------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+-------------------+-------+----------+-------------+ | 192.168.1.2 | node-to-node mesh | up | 03:08:17 | Established | | 192.168.1.3 | node-to-node mesh | up | 03:08:19 | Established | | 192.168.1.1 | node-to-node mesh | up | 03:08:20 | Established | +--------------+-------------------+-------+----------+-------------+ IPv6 BGP status No IPv6 peers found.

从输出可以清晰看到：集群中 4 个节点两两建立了 BGP 连接（PEER TYPE 均为node-to-node mesh），这正是默认全互联模式的典型特征。在 4 节点规模下连接数尚可接受（每节点 3 个对等体），但节点数增长到 50、100 时，这种连接模式将带来明显的资源开销，这正是需要引入 RR 的时机。

kubeasz 自动安装启用 route reflector

kubeasz 的 calico role 内置了 RR 的自动化配置逻辑，启用方式非常简单，仅需两步：

修改/etc/kubeasz/clusters/xxx/config.yml文件，设置配置项CALICO_RR_ENABLED: true；
重新执行网络安装dk ezctl setup xxx 07（对应 07.cluster-addon.yml 网络插件安装流程，具体路径按实际集群目录替换）。

执行完成，检查 bgp 连接验证即可。

配置项说明

在 example/config.yml 中可以查看与 RR 相关的完整配置项：

# [calico]设置calico 是否使用route reflectors # 如果集群规模超过50个节点，建议启用该特性 CALICO_RR_ENABLED: false # CALICO_RR_NODES 配置route reflectors的节点，如果未设置默认使用集群master节点 # CALICO_RR_NODES: ["192.168.1.1", "192.168.1.2"] CALICO_RR_NODES: []

两个配置项的含义与默认行为：

CALICO_RR_ENABLED：布尔值，是否启用 BGP Route Reflectors，默认false。集群节点数超过 50 时建议改为true；
CALICO_RR_NODES：列表，指定作为 RR 的节点 IP。留空[]时，kubeasz 默认选取所有 master 节点作为 RR；也可显式指定，如["192.168.1.1", "192.168.1.2"]。

自动化的底层实现

从源码看，kubeasz 的自动化流程位于 roles/calico/tasks/main.yml：网络插件安装的最后一步会根据CALICO_RR_ENABLED决定是否import_tasks: calico-rr.yml。而 roles/calico/tasks/calico-rr.yml 完整实现了手工配置 RR 的全部等价操作：

选择 RR 节点：若CALICO_RR_NODES为空则取所有kube_master组的主机，否则取列表指定主机，并打印确认；
配置 routeReflectorClusterID：遍历所选节点 IP，通过calicoctl get node -owide反查节点名，再执行calicoctl patch node设置routeReflectorClusterID: 244.0.0.1；
打节点标签：通过kubectl label node <node_name> route-reflector=true --overwrite为 RR 节点打上标签，作为后续 BGPPeer 选择器的匹配依据；
生成并应用 BGP 配置：将bgp-default.yaml与bgp-rr.yaml两个模板渲染到/etc/calico/下，并依次执行calicoctl apply，最后自动运行calicoctl node status输出连接结果。

两个模板分别对应了 RR 方案中必须的两类资源：

roles/calico/templates/bgp-rr.yaml.j2 定义节点与 RR 的建立连接规则：

kind: BGPPeer apiVersion: projectcalico.org/v3 metadata: name: peer-with-route-reflectors spec: nodeSelector: all() peerSelector: route-reflector == 'true'

roles/calico/templates/bgp-default.yaml.j2 定义全局 BGP 配置，关闭全互联模式，并指定 AS 号（AS 号来自 roles/calico/vars/main.yml 中的CALICO_AS_NUMBER: 64512）：

apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: name: default spec: logSeverityScreen: Info nodeToNodeMeshEnabled: false asNumber: {{ CALICO_AS_NUMBER }}

附：手动安装 route reflector 过程讲解

如果希望不依赖 kubeasz 自动化，深入理解每一步的语义（例如在已部署、未使用 kubeasz 管理的集群上操作），也可以完全手工完成配置。整个手工过程分为三个阶段：选择 RR 节点、配置连接规则、关闭全互联。

第一步：选择并配置 Route Reflector 节点

首先查看当前集群中的节点及 AS 号：

$ calicoctl get node -o wide NAME ASN IPV4 IPV6 k8s401 (64512) 192.168.1.1/24 k8s402 (64512) 192.168.1.2/24 k8s403 (64512) 192.168.1.3/24 k8s404 (64512) 192.168.1.4/24

可以在集群中选择 1 个或多个节点作为 rr 节点，这里先选择节点：k8s401。然后执行两条 patch 命令，一条设置反射器簇 ID（routeReflectorClusterID），一条打上route-reflector: true标签：

# 配置 routeReflectorClusterID calicoctl patch node k8s401 -p '{"spec": {"bgp": {"routeReflectorClusterID": "244.0.0.1"}}}' # 配置 node label calicoctl patch node k8s401 -p '{"metadata": {"labels": {"route-reflector": "true"}}}'

其中routeReflectorClusterID是 BGP 协议中路由反射器必需的标识（形式上类似一个 IPv4 地址，常用保留地址如244.0.0.1表示），用于防止路由反射环路；route-reflector: true标签则是下一步 BGPPeer 选择器进行匹配的关键。

第二步：配置 BGP node 与 Route Reflector 的连接建立规则

创建一条 BGPPeer 资源，nodeSelector: all()表示所有节点都参与匹配，peerSelector: route-reflector == 'true'表示对端必须是打了 RR 标签的节点，从而让所有普通节点只与 RR 建立 BGP 连接：

$ cat << EOF | calicoctl create -f - kind: BGPPeer apiVersion: projectcalico.org/v3 metadata: name: peer-with-route-reflectors spec: nodeSelector: all() peerSelector: route-reflector == 'true' EOF

第三步：配置全局禁用全连接（BGP full mesh）

创建（或更新）名为default的 BGPConfiguration，将nodeToNodeMeshEnabled设为false以关闭默认的全互联模式，同时显式声明 AS 号：

$ cat << EOF | calicoctl create -f - apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: name: default spec: logSeverityScreen: Info nodeToNodeMeshEnabled: false asNumber: 64512 EOF

注意：上述手工操作中calicoctl create与 kubeasz 自动化使用的calicoctl apply略有差异——apply为幂等操作（资源已存在则更新），更适合脚本重复执行。另外，无论手工还是自动方式，配置的最终落点都是 Calico 的数据存储。在 kubeasz 部署中，calicoctl 通过 roles/calico/templates/calicoctl.cfg.j2 生成的/etc/calico/calicoctl.cfg以etcdv3作为数据存储后端，并使用集群 CA 签发的 TLS 证书连接 etcd。

第四步：验证增加 rr 之后的 bgp 连接情况

$ dk ansible -i /etc/kubeasz/clusters/xxx/hosts all -m shell -a '/opt/kube/bin/calicoctl node status' 192.168.1.4 | SUCCESS | rc=0 >> Calico process is running. IPv4 BGP status +--------------+-----------+-------+----------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+-----------+-------+----------+-------------+ | 192.168.1.1 | node specific | up | 11:02:55 | Established | +--------------+-----------+-------+----------+-------------+ IPv6 BGP status No IPv6 peers found. 192.168.1.3 | SUCCESS | rc=0 >> Calico process is running. IPv4 BGP status +--------------+-----------+-------+----------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+-----------+-------+----------+-------------+ | 192.168.1.1 | node specific | up | 11:02:55 | Established | +--------------+-----------+-------+----------+-------------+ IPv6 BGP status No IPv6 peers found. 192.168.1.1 | SUCCESS | rc=0 >> Calico process is running. IPv4 BGP status +--------------+---------------+-------+----------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+---------------+-------+----------+-------------+ | 192.168.1.2 | node specific | up | 11:02:55 | Established | | 192.168.1.3 | node specific | up | 11:02:55 | Established | | 192.168.1.4 | node specific | up | 11:02:55 | Established | +--------------+---------------+-------+----------+-------------+ IPv6 BGP status No IPv6 peers found. 192.168.1.2 | SUCCESS | rc=0 >> Calico process is running. IPv4 BGP status +--------------+-----------+-------+----------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+-----------+-------+----------+-------------+ | 192.168.1.1 | node specific | up | 11:02:55 | Established | +--------------+-----------+-------+----------+-------------+ IPv6 BGP status No IPv6 peers found.

可以看到所有其他节点（192.168.1.2 / 192.168.1.3 / 192.168.1.4）都只与所选 rr 节点（192.168.1.1）建立了 bgp 连接，PEER TYPE 由原来的node-to-node mesh变为node specific；而 rr 节点 192.168.1.1 保持与其余 3 个节点的连接，作为路由的汇聚与转发中心。连接数由原来的每节点 3 条、全集群 6 条，收敛为普通节点各 1 条，BGP 拓扑从网状变为星型。

再增加一个 rr 节点（略）

步骤同上，添加成功后可以看到所有其他节点都与两个 rr 节点建立 bgp 连接，两个 rr 节点之间也建立 bgp 连接（RR 之间互相作为对等体交换客户端路由，保证反射路由的完整传播）。对于节点数较多的K8S集群建议配置 2-3 个 RR 节点，既能保证冗余（单个 RR 故障不影响路由收敛），又不会显著增加连接开销。

与 kubeasz 集群配置的衔接

在 kubeasz 集群中启用 RR 特性时，建议结合实际集群拓扑选择 RR 节点：

中小规模集群（50 节点左右起步）：直接CALICO_RR_ENABLED: true，让 kubeasz 默认选择 master 节点作为 RR 即可；
大规模集群（上百节点）：建议通过CALICO_RR_NODES显式指定 2-3 个专用 RR 节点（可以是独立的、不承载业务 Pod 的节点，降低故障面），并注意 RR 节点之间的 BGP 连接与集群内网络质量；
公有云环境：需要注意 example/config.yml 中CALICO_ENABLE_OVERLAY与IP_AUTODETECTION_METHOD等参数与 RR 特性的协同——RR 解决的是 BGP 对等连接的组织方式，而 Overlay 模式（IPIP/VXLAN）解决的是跨子网封包问题，两者正交、可同时启用。

kubeasz 的 calico 网络部署由 roles/calico/tasks/main.yml 负责，包括 calico 证书签发、calico-nodeDaemonSet 下发（模板见 roles/calico/templates/calico-v3.28.yaml.j2）、calicoctl 客户端分发与等待 Pod 就绪，随后才按需进入 RR 配置流程，因此dk ezctl setup xxx 07重跑后即可完成拓扑切换，无需手工干预。

总结与建议

Calico 默认的 node-to-node mesh 全互联模式在小规模集群中简单可靠，但连接数以平方级增长，不适合大规模集群；
calico-node 自 v3.3 起内建路由反射器能力，配合 BGPPeer + BGPConfiguration 两类资源即可完成拓扑重构，普通节点只与 RR 建连、RR 之间互连，连接数变为线性增长；
kubeasz 已将上述过程封装为CALICO_RR_ENABLED/CALICO_RR_NODES两个配置项（见 example/config.yml），一行配置 + 重跑网络安装即可生效，底层实现可参考 roles/calico/tasks/calico-rr.yml；
集群节点数大于 50 时建议启用该特性，RR 节点数量建议 2-3 个以保证冗余；
验证手段统一使用calicoctl node status，重点关注 PEER TYPE 是否由node-to-node mesh变为node specific、所有普通节点是否只与 RR 节点建连、连接状态是否为Established。

【免费下载链接】kubeasz使用Ansible脚本安装K8S集群，介绍组件交互原理，方便直接，不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析