2026/9/14 19:52:26
FEATURED · 精选文章 
Cilium BGP Control Plane 故障排查指南从状态条件到日志定位的完整实战【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文是 Cilium BGP Control Plane 的故障排查实战指南聚焦于CiliumBGPClusterConfig、CiliumBGPPeerConfig、CiliumBGPNodeConfig三类 CRD 在配置与运行过程中最常见的四类问题节点未被选中、BGP 会话无法建立、多个集群配置相互冲突、PeerConfig 引用失效。读完本文你将掌握如何借助 CRD 状态条件Conditions、subsysbgp-control-plane日志过滤、cilium bgp命令与抓包工具快速定位 BGP 建连失败的根因并结合仓库源码理解 Cilium Operator 的状态上报与冲突检测机制。Cilium BGP Control Plane 资源体系速览在进入排查之前先明确 BGP Control Plane 涉及的三个核心 CRD 及其分工三者均定义于 pkg/k8s/apis/cilium.io/v2/bgp_cluster_types.go资源作用创建方CiliumBGPClusterConfig通过nodeSelector选择一组节点定义 BGP 实例与对等体peer配置用户CiliumBGPNodeConfig单个节点的 BGP 配置来源由 Operator 依据 ClusterConfig 生成并维护Cilium OperatorCiliumBGPPeerConfig一组可被多个 peer 共享复用的 BGP 会话参数认证、计时器、传输配置等用户典型的CiliumBGPClusterConfig示例如下取自 bgp-control-plane-configuration.rstapiVersion: cilium.io/v2 kind: CiliumBGPClusterConfig metadata: name: cilium-bgp spec: nodeSelector: matchLabels: rack: rack0 bgpInstances: - name: instance-65000 localASN: 65000 localPort: 179 peers: - name: peer-65000-tor1 peerASN: 65000 peerAddress: fd00:10:0:0::1 peerConfigRef: name: cilium-peer其中peerConfigRef指向一个CiliumBGPPeerConfiggroup与kind可省略默认分别为cilium.io与CiliumBGPPeerConfig。当 Operator 依据 ClusterConfig 的nodeSelector匹配到节点后会为每个匹配节点创建同名以节点名命名的CiliumBGPNodeConfig作为该节点上 BGP 守护进程的实际配置来源这一转换逻辑位于 operator/pkg/bgp/cluster.go 的upsertNodeConfigs函数。关于图片BGP Control Plane 的完整资源映射架构图见 Documentation/network/bgp-control-plane/bgp.png其中清晰展示了用户创建的 CRD黄色与 Operator 创建的 BGP Node Instance绿色之间的层级与引用关系。问题一已应用 CiliumBGP 资源但 BGP 对等关系始终未建立这是最常见的现象资源已 apply 成功节点上却看不到任何 BGP 会话。排查应按以下顺序进行。第一步确认 CiliumBGPNodeConfig 是否已生成BGP 会话由每个节点上的 Cilium agent 内嵌的 BGP speaker当前唯一实现为 GoBGP见 pkg/bgp/cell.go 中gobgp.NewRouterProvider驱动而 agent 只消费CiliumBGPNodeConfig。因此首先检查目标节点是否存在对应的 NodeConfigkubectl get ciliumbgpnodeconfigs若某个节点的CiliumBGPNodeConfig缺失说明 Operator 侧处理异常请检查 Cilium Operator 日志kubectl -n kube-system logs cilium operator pod name | grep subsysbgp-cp-operatorOperator 是 NodeConfig 的创建者operator/pkg/bgp/cluster.go 的upsertNodeConfigs负责创建/更新deleteNodeConfigs负责清理失效的 NodeConfig任何创建失败都会在此日志中留下痕迹。第二步核对 nodeSelector 与对等配置如果 NodeConfig 存在但 BGP 状态不是established则需要核对两处CiliumBGPClusterConfig的nodeSelector是否真正匹配了目标节点对等体peer配置peerASN、peerAddress等是否正确。nodeSelector为空nil时表示选择所有节点——这一点在 bgp_cluster_types.go 的注释与 cluster.go 的实现中均有明确说明nil selector means select all nodes会使用slim_labels.Everything()作为选择器。第三步识别 NoMatchingNode 状态条件若问题出在nodeSelector——要么节点上缺少匹配的标签要么选择器表达式写错——Operator 会在CiliumBGPClusterConfig的status.conditions中写入如下条件条件类型常量定义于 bgp_cluster_types.gostatus: conditions: - lastTransitionTime: 2026-06-16T12:54:24Z message: No node matches spec.nodeSelector observedGeneration: 2 reason: MatchingNodeUnavailable status: True type: cilium.io/NoMatchingNode该条件的写入逻辑在 cluster.go当matchingNodes为空时置为True并给出MatchingNodeUnavailable原因一旦有节点匹配则翻转为False原因变为MatchingNodeSelected。排查时只需确认节点标签与选择器一致即可kubectl get nodes --show-labels kubectl get ciliumbgpclusterconfigs cilium-bgp -o yaml问题二节点已被选中但 BGP peer 仍未建立会话NodeConfig 已存在、节点确实被选中但会话仍无法建立。此时应转向对端路由器日志与 Cilium 日志并结合网络抓包定位。用 subsys 标签过滤 BGP 日志BGP Control Plane 打出的日志统一带有subsysbgp-control-plane字段该日志子系统在 pkg/bgp/cell.go 中注册。在目标节点对应的 Cilium agent pod 上过滤kubectl -n your namespace cilium pod running on the target node logs | grep bgp-control-plane输出示例来自 bgp-control-plane-troubleshooting.rstlevelwarning msgsent notification Dataas number mismatch expected 65003, received 65000 Key10.0.1.1 TopicPeer asn65001 componentgobgp.BgpServerInstance subsysbgp-control-plane示例中Data字段明确指出期望的 ASN 是 65003实际收到的是 65000即配置的peerASN与对端路由器的真实 ASN 不一致导致 OPEN 报文校验失败、会话无法建立。BGP 层错误与底层错误的区别BGP 层错误如 ASN 不匹配、BGP capability 不匹配、Peer IP 错误大概率会出现在上述日志中。但以下两类低层错误往往不会反映在 BGP 日志里到 Peer IP 的网络连通性缺失路由不通、防火墙丢包等eBGP peer 距离超过 1 跳多跳场景未正确配置TTL 不足以让 BGP 报文到达对端。对这两类问题WireShark或tcpdump抓包是更有效的手段。可在 Cilium agent 所在节点上抓取与对端之间的 BGP 流量默认 TCP 179 端口或localPort指定的端口tcpdump -i any tcp port 179 -n观察是否有 TCP 握手与 BGP OPEN 报文即可判断是报文根本没到还是到了但被对端拒绝。借助 cilium bgp 命令确认会话状态除了日志还可以用cilium bgp子命令直接查看每个节点的实时 BGP 会话状态详见 bgp-control-plane-operation.rst# 查看所有节点的 BGP 对等状态 cilium bgp peers # 查看本地 BGP 路由表available / advertised 两种视角 cilium bgp routes available ipv4 unicast cilium bgp routes advertised ipv4 unicastcilium bgp peers输出中包含每个会话的established状态与持续时间cilium bgp routes则可核对期望通告/接收的路由数量辅助判断会话虽建立但路由缺失的情况。问题三新增的 CiliumBGPClusterConfig 不生效BGP Control Plane 的冲突检测规则是多个CiliumBGPClusterConfig不能通过nodeSelector选中同一个节点。若出现这种情况Operator 会拒绝为后续的 ClusterConfig 创建对应的CiliumBGPNodeConfig并在该 ClusterConfig 上写入冲突条件status: conditions: - lastTransitionTime: 2026-06-16T12:55:24Z message: Selecting the same node(s) with ClusterConfig(s): [tor-control-plane] observedGeneration: 1 reason: ClusterConfigConflict status: True type: cilium.io/ConflictingClusterConfig从源码看这一检测在 cluster.go当目标节点已存在由其他ClusterConfig 拥有的 NodeConfig 时upsertNodeConfigs会记录冲突来源conflictingClusterConfigs并跳过该节点随后由updateConflictingClusterConfigsConditioncluster.go写入条件message中会列出所有与之冲突的 ClusterConfig 名称。解决方案调整其中一个 ClusterConfig 的nodeSelector使各配置选中的节点集合互不重叠冲突消除后条件会自动翻转为False原因变为ClusterConfigValidated新增配置随即生效。问题四CiliumBGPPeerConfig 不生效CiliumBGPPeerConfig通过CiliumBGPClusterConfig中每个 peer 的peerConfigRef字段引用。如果配置看起来已经 apply但对等会话参数没有任何变化首先怀疑peerConfigRef存在拼写错误或指向了不存在的资源——这种引用是静默失败的不会报 apply 错误。此时检查 ClusterConfig 的状态条件若出现以下内容即表示引用的 PeerConfig 缺失status: conditions: - lastTransitionTime: 2026-06-16T12:57:47Z message: Referenced CiliumBGPPeerConfig(s) are missing: [peer-config-1] observedGeneration: 1 reason: PeerConfigsMissing status: True type: cilium.io/MissingPeerConfigs底层实现为missingPeerConfigs函数cluster.go它遍历所有 BGP 实例的 peers逐个按peerConfigRef.name在 PeerConfig 存储中查询收集不存在的引用排序并去重以保证输出稳定再由updateMissingPeerConfigsConditioncluster.go写入状态。引用全部可解析后该条件翻转为False原因变为PeerConfigsResolved。排查步骤# 1. 确认引用的 PeerConfig 是否存在 kubectl get ciliumbgppeerconfigs # 2. 检查 ClusterConfig 中的 peerConfigRef 拼写 kubectl get ciliumbgpclusterconfigs name -o yaml | grep -A3 peerConfigRef状态条件机制解析条件如何产生与清除综合以上四个问题可以看到 Cilium Operator 在 operator/pkg/bgp/cluster.go 的reconcileBGPClusterConfig中统一维护三类状态条件条件类型触发场景触达原因cilium.io/NoMatchingNodenodeSelector未匹配任何节点MatchingNodeUnavailablecilium.io/ConflictingClusterConfig多个 ClusterConfig 选中同一节点ClusterConfigConflictcilium.io/MissingPeerConfigspeerConfigRef引用的 PeerConfig 不存在PeerConfigsMissing三个条件类型常量集中定义于 bgp_cluster_types.go并通过AllBGPClusterConfigConditions列表统一注册。reconcile 流程cluster.go每次都会重新评估三个条件仅在条件发生变化时才调用 Kubernetes API 更新status见第 94-104 行更新前还会对条件做稳定排序。有两个细节值得注意状态上报可关闭reconcileBGPClusterConfig中通过enableStatusReporting开关控制cluster.go。当通过 Helm 值bgpControlPlane.statusReport.enabledfalse关闭时控制器会主动清除此前上报的所有条件避免遗留过期状态误导排查。该功能在大型集群中可显著降低 API Server 负载但会牺牲可观测性日常建议保持开启详见 bgp-control-plane-operation.rst 中 Disabling CRD Status Report 一节。条件带 observedGeneration每个条件都记录了触发时对应的observedGeneration可用它与资源的metadata.generation对比判断当前条件是否反映最新一次配置变更后的状态。排查工作流总结面对BGP 会话起不来的问题推荐按以下闭环流程推进看 NodeConfigkubectl get ciliumbgpnodeconfigs缺失则查 Operator 日志subsysbgp-cp-operator看状态条件kubectl get ciliumbgpclusterconfigs name -o yaml重点核对上述三类条件及其 message 中列出的具体资源名看会话状态cilium bgp peers确认是否establishedcilium bgp routes advertised/available核对路由看日志kubectl ... logs | grep bgp-control-plane过滤 BGP 层错误ASN 不匹配、capability 不匹配等看网络对日志无报错但连不上的情况用tcpdump/WireShark抓取 179 端口流量确认底层连通性与多跳问题。相关资源索引故障排查原文Documentation/network/bgp-control-plane/bgp-control-plane-troubleshooting.rst配置详解含完整 YAML 示例与自动发现Documentation/network/bgp-control-plane/bgp-control-plane-configuration.rst运维操作状态查看、日志、节点维护、Graceful RestartDocumentation/network/bgp-control-plane/bgp-control-plane-operation.rst架构图Documentation/network/bgp-control-plane/bgp.pngCRD 类型定义含nodeSelector、peerConfigRef字段校验规则与条件常量pkg/k8s/apis/cilium.io/v2/bgp_cluster_types.go冲突检测与状态条件实现operator/pkg/bgp/cluster.go状态条件单元测试operator/pkg/bgp/cluster_test.goBGP Control Plane 模块装配GoBGP 路由提供者、日志子系统pkg/bgp/cell.go【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cilium BGP Control Plane 故障排查指南：从状态条件到日志定位的完整实战
Cilium BGP Control Plane 故障排查指南从状态条件到日志定位的完整实战【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文是 Cilium BGP Control Plane 的故障排查实战指南聚焦于CiliumBGPClusterConfig、CiliumBGPPeerConfig、CiliumBGPNodeConfig三类 CRD 在配置与运行过程中最常见的四类问题节点未被选中、BGP 会话无法建立、多个集群配置相互冲突、PeerConfig 引用失效。读完本文你将掌握如何借助 CRD 状态条件Conditions、subsysbgp-control-plane日志过滤、cilium bgp命令与抓包工具快速定位 BGP 建连失败的根因并结合仓库源码理解 Cilium Operator 的状态上报与冲突检测机制。Cilium BGP Control Plane 资源体系速览在进入排查之前先明确 BGP Control Plane 涉及的三个核心 CRD 及其分工三者均定义于 pkg/k8s/apis/cilium.io/v2/bgp_cluster_types.go资源作用创建方CiliumBGPClusterConfig通过nodeSelector选择一组节点定义 BGP 实例与对等体peer配置用户CiliumBGPNodeConfig单个节点的 BGP 配置来源由 Operator 依据 ClusterConfig 生成并维护Cilium OperatorCiliumBGPPeerConfig一组可被多个 peer 共享复用的 BGP 会话参数认证、计时器、传输配置等用户典型的CiliumBGPClusterConfig示例如下取自 bgp-control-plane-configuration.rstapiVersion: cilium.io/v2 kind: CiliumBGPClusterConfig metadata: name: cilium-bgp spec: nodeSelector: matchLabels: rack: rack0 bgpInstances: - name: instance-65000 localASN: 65000 localPort: 179 peers: - name: peer-65000-tor1 peerASN: 65000 peerAddress: fd00:10:0:0::1 peerConfigRef: name: cilium-peer其中peerConfigRef指向一个CiliumBGPPeerConfiggroup与kind可省略默认分别为cilium.io与CiliumBGPPeerConfig。当 Operator 依据 ClusterConfig 的nodeSelector匹配到节点后会为每个匹配节点创建同名以节点名命名的CiliumBGPNodeConfig作为该节点上 BGP 守护进程的实际配置来源这一转换逻辑位于 operator/pkg/bgp/cluster.go 的upsertNodeConfigs函数。关于图片BGP Control Plane 的完整资源映射架构图见 Documentation/network/bgp-control-plane/bgp.png其中清晰展示了用户创建的 CRD黄色与 Operator 创建的 BGP Node Instance绿色之间的层级与引用关系。问题一已应用 CiliumBGP 资源但 BGP 对等关系始终未建立这是最常见的现象资源已 apply 成功节点上却看不到任何 BGP 会话。排查应按以下顺序进行。第一步确认 CiliumBGPNodeConfig 是否已生成BGP 会话由每个节点上的 Cilium agent 内嵌的 BGP speaker当前唯一实现为 GoBGP见 pkg/bgp/cell.go 中gobgp.NewRouterProvider驱动而 agent 只消费CiliumBGPNodeConfig。因此首先检查目标节点是否存在对应的 NodeConfigkubectl get ciliumbgpnodeconfigs若某个节点的CiliumBGPNodeConfig缺失说明 Operator 侧处理异常请检查 Cilium Operator 日志kubectl -n kube-system logs cilium operator pod name | grep subsysbgp-cp-operatorOperator 是 NodeConfig 的创建者operator/pkg/bgp/cluster.go 的upsertNodeConfigs负责创建/更新deleteNodeConfigs负责清理失效的 NodeConfig任何创建失败都会在此日志中留下痕迹。第二步核对 nodeSelector 与对等配置如果 NodeConfig 存在但 BGP 状态不是established则需要核对两处CiliumBGPClusterConfig的nodeSelector是否真正匹配了目标节点对等体peer配置peerASN、peerAddress等是否正确。nodeSelector为空nil时表示选择所有节点——这一点在 bgp_cluster_types.go 的注释与 cluster.go 的实现中均有明确说明nil selector means select all nodes会使用slim_labels.Everything()作为选择器。第三步识别 NoMatchingNode 状态条件若问题出在nodeSelector——要么节点上缺少匹配的标签要么选择器表达式写错——Operator 会在CiliumBGPClusterConfig的status.conditions中写入如下条件条件类型常量定义于 bgp_cluster_types.gostatus: conditions: - lastTransitionTime: 2026-06-16T12:54:24Z message: No node matches spec.nodeSelector observedGeneration: 2 reason: MatchingNodeUnavailable status: True type: cilium.io/NoMatchingNode该条件的写入逻辑在 cluster.go当matchingNodes为空时置为True并给出MatchingNodeUnavailable原因一旦有节点匹配则翻转为False原因变为MatchingNodeSelected。排查时只需确认节点标签与选择器一致即可kubectl get nodes --show-labels kubectl get ciliumbgpclusterconfigs cilium-bgp -o yaml问题二节点已被选中但 BGP peer 仍未建立会话NodeConfig 已存在、节点确实被选中但会话仍无法建立。此时应转向对端路由器日志与 Cilium 日志并结合网络抓包定位。用 subsys 标签过滤 BGP 日志BGP Control Plane 打出的日志统一带有subsysbgp-control-plane字段该日志子系统在 pkg/bgp/cell.go 中注册。在目标节点对应的 Cilium agent pod 上过滤kubectl -n your namespace cilium pod running on the target node logs | grep bgp-control-plane输出示例来自 bgp-control-plane-troubleshooting.rstlevelwarning msgsent notification Dataas number mismatch expected 65003, received 65000 Key10.0.1.1 TopicPeer asn65001 componentgobgp.BgpServerInstance subsysbgp-control-plane示例中Data字段明确指出期望的 ASN 是 65003实际收到的是 65000即配置的peerASN与对端路由器的真实 ASN 不一致导致 OPEN 报文校验失败、会话无法建立。BGP 层错误与底层错误的区别BGP 层错误如 ASN 不匹配、BGP capability 不匹配、Peer IP 错误大概率会出现在上述日志中。但以下两类低层错误往往不会反映在 BGP 日志里到 Peer IP 的网络连通性缺失路由不通、防火墙丢包等eBGP peer 距离超过 1 跳多跳场景未正确配置TTL 不足以让 BGP 报文到达对端。对这两类问题WireShark或tcpdump抓包是更有效的手段。可在 Cilium agent 所在节点上抓取与对端之间的 BGP 流量默认 TCP 179 端口或localPort指定的端口tcpdump -i any tcp port 179 -n观察是否有 TCP 握手与 BGP OPEN 报文即可判断是报文根本没到还是到了但被对端拒绝。借助 cilium bgp 命令确认会话状态除了日志还可以用cilium bgp子命令直接查看每个节点的实时 BGP 会话状态详见 bgp-control-plane-operation.rst# 查看所有节点的 BGP 对等状态 cilium bgp peers # 查看本地 BGP 路由表available / advertised 两种视角 cilium bgp routes available ipv4 unicast cilium bgp routes advertised ipv4 unicastcilium bgp peers输出中包含每个会话的established状态与持续时间cilium bgp routes则可核对期望通告/接收的路由数量辅助判断会话虽建立但路由缺失的情况。问题三新增的 CiliumBGPClusterConfig 不生效BGP Control Plane 的冲突检测规则是多个CiliumBGPClusterConfig不能通过nodeSelector选中同一个节点。若出现这种情况Operator 会拒绝为后续的 ClusterConfig 创建对应的CiliumBGPNodeConfig并在该 ClusterConfig 上写入冲突条件status: conditions: - lastTransitionTime: 2026-06-16T12:55:24Z message: Selecting the same node(s) with ClusterConfig(s): [tor-control-plane] observedGeneration: 1 reason: ClusterConfigConflict status: True type: cilium.io/ConflictingClusterConfig从源码看这一检测在 cluster.go当目标节点已存在由其他ClusterConfig 拥有的 NodeConfig 时upsertNodeConfigs会记录冲突来源conflictingClusterConfigs并跳过该节点随后由updateConflictingClusterConfigsConditioncluster.go写入条件message中会列出所有与之冲突的 ClusterConfig 名称。解决方案调整其中一个 ClusterConfig 的nodeSelector使各配置选中的节点集合互不重叠冲突消除后条件会自动翻转为False原因变为ClusterConfigValidated新增配置随即生效。问题四CiliumBGPPeerConfig 不生效CiliumBGPPeerConfig通过CiliumBGPClusterConfig中每个 peer 的peerConfigRef字段引用。如果配置看起来已经 apply但对等会话参数没有任何变化首先怀疑peerConfigRef存在拼写错误或指向了不存在的资源——这种引用是静默失败的不会报 apply 错误。此时检查 ClusterConfig 的状态条件若出现以下内容即表示引用的 PeerConfig 缺失status: conditions: - lastTransitionTime: 2026-06-16T12:57:47Z message: Referenced CiliumBGPPeerConfig(s) are missing: [peer-config-1] observedGeneration: 1 reason: PeerConfigsMissing status: True type: cilium.io/MissingPeerConfigs底层实现为missingPeerConfigs函数cluster.go它遍历所有 BGP 实例的 peers逐个按peerConfigRef.name在 PeerConfig 存储中查询收集不存在的引用排序并去重以保证输出稳定再由updateMissingPeerConfigsConditioncluster.go写入状态。引用全部可解析后该条件翻转为False原因变为PeerConfigsResolved。排查步骤# 1. 确认引用的 PeerConfig 是否存在 kubectl get ciliumbgppeerconfigs # 2. 检查 ClusterConfig 中的 peerConfigRef 拼写 kubectl get ciliumbgpclusterconfigs name -o yaml | grep -A3 peerConfigRef状态条件机制解析条件如何产生与清除综合以上四个问题可以看到 Cilium Operator 在 operator/pkg/bgp/cluster.go 的reconcileBGPClusterConfig中统一维护三类状态条件条件类型触发场景触达原因cilium.io/NoMatchingNodenodeSelector未匹配任何节点MatchingNodeUnavailablecilium.io/ConflictingClusterConfig多个 ClusterConfig 选中同一节点ClusterConfigConflictcilium.io/MissingPeerConfigspeerConfigRef引用的 PeerConfig 不存在PeerConfigsMissing三个条件类型常量集中定义于 bgp_cluster_types.go并通过AllBGPClusterConfigConditions列表统一注册。reconcile 流程cluster.go每次都会重新评估三个条件仅在条件发生变化时才调用 Kubernetes API 更新status见第 94-104 行更新前还会对条件做稳定排序。有两个细节值得注意状态上报可关闭reconcileBGPClusterConfig中通过enableStatusReporting开关控制cluster.go。当通过 Helm 值bgpControlPlane.statusReport.enabledfalse关闭时控制器会主动清除此前上报的所有条件避免遗留过期状态误导排查。该功能在大型集群中可显著降低 API Server 负载但会牺牲可观测性日常建议保持开启详见 bgp-control-plane-operation.rst 中 Disabling CRD Status Report 一节。条件带 observedGeneration每个条件都记录了触发时对应的observedGeneration可用它与资源的metadata.generation对比判断当前条件是否反映最新一次配置变更后的状态。排查工作流总结面对BGP 会话起不来的问题推荐按以下闭环流程推进看 NodeConfigkubectl get ciliumbgpnodeconfigs缺失则查 Operator 日志subsysbgp-cp-operator看状态条件kubectl get ciliumbgpclusterconfigs name -o yaml重点核对上述三类条件及其 message 中列出的具体资源名看会话状态cilium bgp peers确认是否establishedcilium bgp routes advertised/available核对路由看日志kubectl ... logs | grep bgp-control-plane过滤 BGP 层错误ASN 不匹配、capability 不匹配等看网络对日志无报错但连不上的情况用tcpdump/WireShark抓取 179 端口流量确认底层连通性与多跳问题。相关资源索引故障排查原文Documentation/network/bgp-control-plane/bgp-control-plane-troubleshooting.rst配置详解含完整 YAML 示例与自动发现Documentation/network/bgp-control-plane/bgp-control-plane-configuration.rst运维操作状态查看、日志、节点维护、Graceful RestartDocumentation/network/bgp-control-plane/bgp-control-plane-operation.rst架构图Documentation/network/bgp-control-plane/bgp.pngCRD 类型定义含nodeSelector、peerConfigRef字段校验规则与条件常量pkg/k8s/apis/cilium.io/v2/bgp_cluster_types.go冲突检测与状态条件实现operator/pkg/bgp/cluster.go状态条件单元测试operator/pkg/bgp/cluster_test.goBGP Control Plane 模块装配GoBGP 路由提供者、日志子系统pkg/bgp/cell.go【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
