From 174f56522ba1670ea3b99161666374959c7c9281 Mon Sep 17 00:00:00 2001 From: changluyi <47097611+changluyi@users.noreply.github.com> Date: Wed, 12 Aug 2026 14:41:16 +0800 Subject: [PATCH 1/4] docs(acp): add MetalLB host FRR S2 workaround --- ...S2_Use_Native_BGP_Backend_with_Host_FRR.md | 141 ++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 docs/en/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md diff --git a/docs/en/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md b/docs/en/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md new file mode 100644 index 000000000..ce200860b --- /dev/null +++ b/docs/en/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md @@ -0,0 +1,141 @@ +--- +kind: + - Troubleshooting +products: + - Alauda Container Platform +ProductsVersion: + - '4.3.x,4.4.x' +--- + +# S2 Workaround for Host FRR and MetalLB FRR Conflicts + +## Problem + +Some bare-metal ACP nodes already run a customer-managed FRR service as a systemd unit. When MetalLB uses its `frr` BGP backend, each MetalLB speaker Pod runs in the host network namespace with FRR-related containers. The MetalLB FRR process can then modify routes in the node's main routing table and interfere with the customer-managed FRR service. + +## Root Cause + +MetalLB speakers use `hostNetwork: true`. With the `frr` BGP backend, the speaker Pod includes `frr`, `reloader`, and `frr-metrics` containers. The MetalLB FRR process shares the node network namespace with the systemd-managed FRR service, so both processes can affect the host routing and BGP control plane. + +## Temporary Workaround + +Change MetalLB to its `native` BGP backend. This removes the MetalLB-managed FRR containers from the speaker Pod, so MetalLB no longer runs an FRR process in the node network namespace. + +Use this workaround only when all of the following conditions are met: + +- The cluster is not OpenShift. The MetalLB native BGP backend is not supported on OpenShift. +- The customer accepts the native MetalLB BGP implementation instead of the MetalLB FRR backend. +- MetalLB and the host FRR service do not use the same BGP local address, neighbor, router ID, or advertised prefixes. +- A maintenance window is available. Updating the `MetalLB` resource rolls the MetalLB speaker DaemonSet. + +This workaround prevents MetalLB from deploying its own FRR containers. It does **not** make two independent BGP implementations safe to use with the same BGP identity or the same advertised routes. Configure independent BGP peers and non-overlapping advertised prefixes, or schedule MetalLB speakers only on nodes that do not run the customer FRR service. + +The change is a configuration workaround. Verify the configuration after a MetalLB plugin upgrade or reinstall. + +### 1. Check the current MetalLB configuration + +Identify the MetalLB custom resource and record its current BGP backend: + +```bash +kubectl -n metallb-system get metallb +kubectl -n metallb-system get metallb metallb -o jsonpath='{.spec.bgpBackend}{"\n"}' +``` + +The commands in this article use the default resource name `metallb`. If the cluster uses a different resource name, replace it in all subsequent commands. + +Before changing the backend, record the current speaker placement and BGP configuration: + +```bash +kubectl -n metallb-system get ds speaker -o wide +kubectl -n metallb-system get bgppeers,bgpadvertisements,ipaddresspools +``` + +Confirm with the network administrator that the MetalLB BGP peers and advertised address pools do not overlap with the host FRR service on every node where a speaker will run. + +### 2. Back up the MetalLB resource + +Save the current custom resource so that the change can be reverted: + +```bash +kubectl -n metallb-system get metallb metallb -o yaml > metallb-before-native-backend.yaml +``` + +Do not use the backup file to restore `status` fields. The rollback command in this article updates only `spec.bgpBackend`. + +### 3. Switch to the native BGP backend + +Set `spec.bgpBackend` to `native`: + +```bash +kubectl -n metallb-system patch metallb metallb \ + --type=merge \ + -p '{"spec":{"bgpBackend":"native"}}' +``` + +Wait for the speaker DaemonSet rollout to complete: + +```bash +kubectl -n metallb-system rollout status daemonset/speaker +``` + +### 4. Verify that MetalLB FRR containers are removed + +List the speaker Pod template containers: + +```bash +kubectl -n metallb-system get daemonset speaker \ + -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\n"}{end}' +``` + +The output must not include these containers: + +- `frr` +- `reloader` +- `frr-metrics` +- `metrics-auth-proxy-frr` (when secure FRR metrics had been enabled) + +Confirm that all speaker Pods are ready: + +```bash +kubectl -n metallb-system get pods -l app=metallb,component=speaker +``` + +Finally, verify BGP session state and route advertisement using the customer's normal network monitoring tools. Do not treat Pod readiness as proof that BGP sessions are established or that the expected LoadBalancer prefixes are advertised. + +### 5. Optional: isolate speaker nodes from host FRR nodes + +When a separate set of nodes is available for MetalLB speakers, constrain the speaker DaemonSet through the `MetalLB` resource. Label only nodes that do not run the customer-managed FRR service: + +```bash +kubectl label node metallb.alauda.io/speaker=true +``` + +Then add the node selector to the MetalLB resource: + +```bash +kubectl -n metallb-system patch metallb metallb \ + --type=merge \ + -p '{"spec":{"nodeSelector":{"metallb.alauda.io/speaker":"true"}}}' +``` + +Wait for the speaker DaemonSet rollout and confirm that speakers run only on the intended nodes: + +```bash +kubectl -n metallb-system rollout status daemonset/speaker +kubectl -n metallb-system get pods -l app=metallb,component=speaker -o wide +``` + +Use this optional step when node isolation is needed. It reduces the chance of a host-level conflict, but it does not remove the requirement for distinct BGP peers and prefixes. + +## Rollback + +If native mode does not meet the BGP requirements, restore the MetalLB FRR backend: + +```bash +kubectl -n metallb-system patch metallb metallb \ + --type=merge \ + -p '{"spec":{"bgpBackend":"frr"}}' +kubectl -n metallb-system rollout status daemonset/speaker +``` + +After the rollout, confirm that the required FRR-related containers are present again and validate BGP sessions before returning the cluster to service. Do not roll back to `frr` while the original host FRR conflict is unresolved. From d372593b3e9521e93ca1b710d62c6d433eb5ba61 Mon Sep 17 00:00:00 2001 From: changluyi <47097611+changluyi@users.noreply.github.com> Date: Wed, 12 Aug 2026 14:41:19 +0800 Subject: [PATCH 2/4] docs(acp): add MetalLB host FRR S2 workaround --- ...S2_Use_Native_BGP_Backend_with_Host_FRR.md | 141 ++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 docs/zh/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md diff --git a/docs/zh/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md b/docs/zh/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md new file mode 100644 index 000000000..41122b27b --- /dev/null +++ b/docs/zh/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md @@ -0,0 +1,141 @@ +--- +kind: + - Troubleshooting +products: + - Alauda Container Platform +ProductsVersion: + - '4.3.x,4.4.x' +--- + +# S2 临时方案：解决主机 FRR 与 MetalLB FRR 的冲突 + +## 问题 + +部分裸金属 ACP 节点已通过 systemd 运行客户自行维护的 FRR 服务。当 MetalLB 使用 `frr` BGP 后端时，每个 MetalLB speaker Pod 都会在主机网络命名空间中运行多个 FRR 相关容器。MetalLB 的 FRR 进程可能修改节点主路由表，并与客户维护的 FRR 服务相互影响。 + +## 根本原因 + +MetalLB speaker 使用 `hostNetwork: true`。当 BGP 后端为 `frr` 时，speaker Pod 包含 `frr`、`reloader` 和 `frr-metrics` 容器。MetalLB FRR 进程与由 systemd 管理的 FRR 服务共享节点网络命名空间，因此二者都可能影响主机路由和 BGP 控制面。 + +## 临时解决方案 + +将 MetalLB 切换为 `native` BGP 后端。此操作会从 speaker Pod 中移除 MetalLB 管理的 FRR 容器，使 MetalLB 不再在节点网络命名空间中运行 FRR 进程。 + +仅在满足以下全部条件时使用本方案： + +- 集群不是 OpenShift。MetalLB native BGP 后端不支持 OpenShift。 +- 客户接受使用 MetalLB native BGP 实现替代 MetalLB FRR 后端。 +- MetalLB 与主机 FRR 不使用相同的 BGP 本地地址、邻居、router ID 或宣告前缀。 +- 已安排维护窗口。更新 `MetalLB` 资源会滚动更新 MetalLB speaker DaemonSet。 + +本方案仅防止 MetalLB 部署自身的 FRR 容器，**不代表**两套独立 BGP 实现可以使用相同的 BGP 身份或相同的宣告路由。应配置独立的 BGP 邻居和不重叠的宣告前缀，或仅将 MetalLB speaker 调度到未运行客户 FRR 服务的节点。 + +该变更属于配置临时方案。MetalLB 插件升级或重装后，需要重新验证配置。 + +### 1. 检查当前 MetalLB 配置 + +确认 MetalLB 自定义资源并记录当前 BGP 后端： + +```bash +kubectl -n metallb-system get metallb +kubectl -n metallb-system get metallb metallb -o jsonpath='{.spec.bgpBackend}{"\n"}' +``` + +本文使用默认资源名 `metallb`。如果实际集群使用其他资源名，请在后续命令中替换。 + +切换前，记录当前 speaker 调度位置和 BGP 配置： + +```bash +kubectl -n metallb-system get ds speaker -o wide +kubectl -n metallb-system get bgppeers,bgpadvertisements,ipaddresspools +``` + +与网络管理员确认：所有运行 speaker 的节点上，MetalLB 的 BGP 邻居和宣告地址池均不与主机 FRR 服务重叠。 + +### 2. 备份 MetalLB 资源 + +保存当前自定义资源，以便回滚： + +```bash +kubectl -n metallb-system get metallb metallb -o yaml > metallb-before-native-backend.yaml +``` + +请勿使用该备份文件恢复 `status` 字段。本文的回滚命令只更新 `spec.bgpBackend`。 + +### 3. 切换到 native BGP 后端 + +将 `spec.bgpBackend` 设置为 `native`： + +```bash +kubectl -n metallb-system patch metallb metallb \ + --type=merge \ + -p '{"spec":{"bgpBackend":"native"}}' +``` + +等待 speaker DaemonSet 滚动更新完成： + +```bash +kubectl -n metallb-system rollout status daemonset/speaker +``` + +### 4. 验证 MetalLB FRR 容器已移除 + +列出 speaker Pod 模板中的容器： + +```bash +kubectl -n metallb-system get daemonset speaker \ + -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\n"}{end}' +``` + +输出中不应包含以下容器： + +- `frr` +- `reloader` +- `frr-metrics` +- `metrics-auth-proxy-frr`（此前启用安全 FRR 指标时） + +确认所有 speaker Pod 都已就绪： + +```bash +kubectl -n metallb-system get pods -l app=metallb,component=speaker +``` + +最后，请使用客户正常的网络监控工具验证 BGP 会话状态和路由宣告。Pod 就绪并不能证明 BGP 会话已建立，也不能证明预期的 LoadBalancer 前缀已完成宣告。 + +### 5. 可选：将 speaker 节点与主机 FRR 节点隔离 + +如果有可供 MetalLB speaker 专用的节点，请通过 `MetalLB` 资源约束 speaker DaemonSet。仅为未运行客户 FRR 服务的节点添加标签： + +```bash +kubectl label node metallb.alauda.io/speaker=true +``` + +然后为 MetalLB 资源添加节点选择器： + +```bash +kubectl -n metallb-system patch metallb metallb \ + --type=merge \ + -p '{"spec":{"nodeSelector":{"metallb.alauda.io/speaker":"true"}}}' +``` + +等待 speaker DaemonSet 滚动更新，并确认 speaker 只运行在目标节点： + +```bash +kubectl -n metallb-system rollout status daemonset/speaker +kubectl -n metallb-system get pods -l app=metallb,component=speaker -o wide +``` + +当需要节点隔离时使用此可选步骤。它可以降低主机级冲突风险，但不能替代独立 BGP 邻居和非重叠前缀的要求。 + +## 回滚 + +如果 native 模式无法满足 BGP 要求，可恢复 MetalLB FRR 后端： + +```bash +kubectl -n metallb-system patch metallb metallb \ + --type=merge \ + -p '{"spec":{"bgpBackend":"frr"}}' +kubectl -n metallb-system rollout status daemonset/speaker +``` + +滚动更新完成后，确认所需的 FRR 相关容器已恢复，并在恢复集群服务前验证 BGP 会话。原有主机 FRR 冲突未解决时，不应回滚至 `frr`。 From 7ba2f9ec8c17c52538a1af0cc8769560120ab686 Mon Sep 17 00:00:00 2001 From: changluyi <47097611+changluyi@users.noreply.github.com> Date: Wed, 12 Aug 2026 15:34:19 +0800 Subject: [PATCH 3/4] docs(acp): use console flow for MetalLB S2 workaround --- ...S2_Use_Native_BGP_Backend_with_Host_FRR.md | 123 ++++-------------- 1 file changed, 22 insertions(+), 101 deletions(-) diff --git a/docs/en/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md b/docs/en/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md index ce200860b..d5d0f3b04 100644 --- a/docs/en/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md +++ b/docs/en/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md @@ -21,121 +21,42 @@ MetalLB speakers use `hostNetwork: true`. With the `frr` BGP backend, the speake Change MetalLB to its `native` BGP backend. This removes the MetalLB-managed FRR containers from the speaker Pod, so MetalLB no longer runs an FRR process in the node network namespace. -Use this workaround only when all of the following conditions are met: +Use this workaround only on a non-OpenShift cluster. The native BGP backend is not supported on OpenShift. -- The cluster is not OpenShift. The MetalLB native BGP backend is not supported on OpenShift. -- The customer accepts the native MetalLB BGP implementation instead of the MetalLB FRR backend. -- MetalLB and the host FRR service do not use the same BGP local address, neighbor, router ID, or advertised prefixes. -- A maintenance window is available. Updating the `MetalLB` resource rolls the MetalLB speaker DaemonSet. +### 1. Configure BGP peers in the console -This workaround prevents MetalLB from deploying its own FRR containers. It does **not** make two independent BGP implementations safe to use with the same BGP identity or the same advertised routes. Configure independent BGP peers and non-overlapping advertised prefixes, or schedule MetalLB speakers only on nodes that do not run the customer FRR service. +Open the target cluster, then go to **Networking -> BGP Peers**. Create or edit the BGP peer used by MetalLB. -The change is a configuration workaround. Verify the configuration after a MetalLB plugin upgrade or reinstall. +Do not edit a ConfigMap or manually create `BGPPeer` resources for this configuration. Set these fields in the console: -### 1. Check the current MetalLB configuration +- **Local AS**, **Remote AS**, and **Remote IP**: use the values assigned for MetalLB by the network team. +- **Local IP**: use an address that is not used by the host FRR service. +- **Router ID**: use an identifier that is not used by the host FRR service. +- **BGP connection node**: select only the nodes assigned to MetalLB. When available, select nodes that do not run the customer-managed FRR service. -Identify the MetalLB custom resource and record its current BGP backend: +MetalLB and host FRR must not use the same local address, neighbor, router ID, or advertised prefixes. -```bash -kubectl -n metallb-system get metallb -kubectl -n metallb-system get metallb metallb -o jsonpath='{.spec.bgpBackend}{"\n"}' -``` +### 2. Configure the BGP external address pool in the console -The commands in this article use the default resource name `metallb`. If the cluster uses a different resource name, replace it in all subsequent commands. +Go to **Networking -> External IP Pools** and create or edit the pool used by the LoadBalancer Services: -Before changing the backend, record the current speaker placement and BGP configuration: +1. Set **Type** to **BGP**. +2. Enter the MetalLB VIP range in **IP Resources**. +3. Associate the BGP peer created in the previous step. +4. Select only the nodes that are allowed to advertise the VIP range. -```bash -kubectl -n metallb-system get ds speaker -o wide -kubectl -n metallb-system get bgppeers,bgpadvertisements,ipaddresspools -``` +The VIP range must not overlap with prefixes advertised by the host FRR service. -Confirm with the network administrator that the MetalLB BGP peers and advertised address pools do not overlap with the host FRR service on every node where a speaker will run. +### 3. Switch the MetalLB backend -### 2. Back up the MetalLB resource +The current console exposes BGP peers and external address pools, but does not expose the MetalLB `bgpBackend` setting. An S2 engineer changes this setting to `native` during the maintenance window. The change rolls the speaker DaemonSet. -Save the current custom resource so that the change can be reverted: +### 4. Verify the result -```bash -kubectl -n metallb-system get metallb metallb -o yaml > metallb-before-native-backend.yaml -``` +After the speaker rollout, confirm that the speaker Pod no longer contains `frr`, `reloader`, or `frr-metrics` containers. Then use the normal network monitoring tools to confirm the MetalLB BGP session and VIP route advertisement. -Do not use the backup file to restore `status` fields. The rollback command in this article updates only `spec.bgpBackend`. - -### 3. Switch to the native BGP backend - -Set `spec.bgpBackend` to `native`: - -```bash -kubectl -n metallb-system patch metallb metallb \ - --type=merge \ - -p '{"spec":{"bgpBackend":"native"}}' -``` - -Wait for the speaker DaemonSet rollout to complete: - -```bash -kubectl -n metallb-system rollout status daemonset/speaker -``` - -### 4. Verify that MetalLB FRR containers are removed - -List the speaker Pod template containers: - -```bash -kubectl -n metallb-system get daemonset speaker \ - -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\n"}{end}' -``` - -The output must not include these containers: - -- `frr` -- `reloader` -- `frr-metrics` -- `metrics-auth-proxy-frr` (when secure FRR metrics had been enabled) - -Confirm that all speaker Pods are ready: - -```bash -kubectl -n metallb-system get pods -l app=metallb,component=speaker -``` - -Finally, verify BGP session state and route advertisement using the customer's normal network monitoring tools. Do not treat Pod readiness as proof that BGP sessions are established or that the expected LoadBalancer prefixes are advertised. - -### 5. Optional: isolate speaker nodes from host FRR nodes - -When a separate set of nodes is available for MetalLB speakers, constrain the speaker DaemonSet through the `MetalLB` resource. Label only nodes that do not run the customer-managed FRR service: - -```bash -kubectl label node metallb.alauda.io/speaker=true -``` - -Then add the node selector to the MetalLB resource: - -```bash -kubectl -n metallb-system patch metallb metallb \ - --type=merge \ - -p '{"spec":{"nodeSelector":{"metallb.alauda.io/speaker":"true"}}}' -``` - -Wait for the speaker DaemonSet rollout and confirm that speakers run only on the intended nodes: - -```bash -kubectl -n metallb-system rollout status daemonset/speaker -kubectl -n metallb-system get pods -l app=metallb,component=speaker -o wide -``` - -Use this optional step when node isolation is needed. It reduces the chance of a host-level conflict, but it does not remove the requirement for distinct BGP peers and prefixes. +Pod readiness alone does not prove that the BGP session is established or that the expected VIP prefixes are advertised. ## Rollback -If native mode does not meet the BGP requirements, restore the MetalLB FRR backend: - -```bash -kubectl -n metallb-system patch metallb metallb \ - --type=merge \ - -p '{"spec":{"bgpBackend":"frr"}}' -kubectl -n metallb-system rollout status daemonset/speaker -``` - -After the rollout, confirm that the required FRR-related containers are present again and validate BGP sessions before returning the cluster to service. Do not roll back to `frr` while the original host FRR conflict is unresolved. +If native mode cannot meet the BGP requirements, an S2 engineer can change the backend back to `frr`. Do not roll back while the original host FRR conflict is unresolved. From ad627195d3b13a3575c7467404d192b51ecfccdb Mon Sep 17 00:00:00 2001 From: changluyi <47097611+changluyi@users.noreply.github.com> Date: Wed, 12 Aug 2026 15:34:46 +0800 Subject: [PATCH 4/4] docs(acp): use console flow for MetalLB S2 workaround --- ...S2_Use_Native_BGP_Backend_with_Host_FRR.md | 123 ++++-------------- 1 file changed, 22 insertions(+), 101 deletions(-) diff --git a/docs/zh/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md b/docs/zh/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md index 41122b27b..b10c2d626 100644 --- a/docs/zh/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md +++ b/docs/zh/solutions/acp/MetalLB_S2_Use_Native_BGP_Backend_with_Host_FRR.md @@ -21,121 +21,42 @@ MetalLB speaker 使用 `hostNetwork: true`。当 BGP 后端为 `frr` 时，speak 将 MetalLB 切换为 `native` BGP 后端。此操作会从 speaker Pod 中移除 MetalLB 管理的 FRR 容器，使 MetalLB 不再在节点网络命名空间中运行 FRR 进程。 -仅在满足以下全部条件时使用本方案： +本方案仅适用于非 OpenShift 集群。MetalLB native BGP 后端不支持 OpenShift。 -- 集群不是 OpenShift。MetalLB native BGP 后端不支持 OpenShift。 -- 客户接受使用 MetalLB native BGP 实现替代 MetalLB FRR 后端。 -- MetalLB 与主机 FRR 不使用相同的 BGP 本地地址、邻居、router ID 或宣告前缀。 -- 已安排维护窗口。更新 `MetalLB` 资源会滚动更新 MetalLB speaker DaemonSet。 +### 1. 在控制台配置 BGP 对等体 -本方案仅防止 MetalLB 部署自身的 FRR 容器，**不代表**两套独立 BGP 实现可以使用相同的 BGP 身份或相同的宣告路由。应配置独立的 BGP 邻居和不重叠的宣告前缀，或仅将 MetalLB speaker 调度到未运行客户 FRR 服务的节点。 +进入目标集群，选择 **网络 -> BGP 对等体**，创建或编辑 MetalLB 使用的 BGP 对等体。 -该变更属于配置临时方案。MetalLB 插件升级或重装后，需要重新验证配置。 +此处不需要编辑 ConfigMap，也不需要手动创建 `BGPPeer` 资源。请在控制台中配置以下字段： -### 1. 检查当前 MetalLB 配置 +- **本地 AS**、**对端 AS**、**对端 IP**：使用网络团队分配给 MetalLB 的参数。 +- **本地 IP**：必须与主机 FRR 使用的地址不同。 +- **Router ID**：必须与主机 FRR 使用的 Router ID 不同。 +- **BGP 连接节点**：仅选择分配给 MetalLB 的节点；如有条件，选择未运行客户 FRR 服务的节点。 -确认 MetalLB 自定义资源并记录当前 BGP 后端： +MetalLB 与主机 FRR 不得使用相同的本地地址、邻居、Router ID 或宣告前缀。 -```bash -kubectl -n metallb-system get metallb -kubectl -n metallb-system get metallb metallb -o jsonpath='{.spec.bgpBackend}{"\n"}' -``` +### 2. 在控制台配置 BGP 外部地址池 -本文使用默认资源名 `metallb`。如果实际集群使用其他资源名，请在后续命令中替换。 +选择 **网络 -> 外部地址池**，创建或编辑 LoadBalancer 服务使用的地址池： -切换前，记录当前 speaker 调度位置和 BGP 配置： +1. 将 **类型** 设置为 **BGP**。 +2. 在 **IP 资源** 中填写 MetalLB VIP 范围。 +3. 关联上一步创建的 BGP 对等体。 +4. 仅选择允许宣告该 VIP 范围的节点。 -```bash -kubectl -n metallb-system get ds speaker -o wide -kubectl -n metallb-system get bgppeers,bgpadvertisements,ipaddresspools -``` +VIP 范围不得与主机 FRR 服务宣告的前缀重叠。 -与网络管理员确认：所有运行 speaker 的节点上，MetalLB 的 BGP 邻居和宣告地址池均不与主机 FRR 服务重叠。 +### 3. 切换 MetalLB 后端 -### 2. 备份 MetalLB 资源 +当前控制台已提供 BGP 对等体和外部地址池配置，但未提供 MetalLB `bgpBackend` 配置项。由 S2 工程师在维护窗口内将其切换为 `native`，该操作会滚动更新 speaker DaemonSet。 -保存当前自定义资源，以便回滚： +### 4. 验证结果 -```bash -kubectl -n metallb-system get metallb metallb -o yaml > metallb-before-native-backend.yaml -``` +speaker 滚动更新完成后，确认 speaker Pod 中不再包含 `frr`、`reloader`、`frr-metrics` 容器。然后使用正常的网络监控工具确认 MetalLB BGP 会话及 VIP 路由宣告。 -请勿使用该备份文件恢复 `status` 字段。本文的回滚命令只更新 `spec.bgpBackend`。 - -### 3. 切换到 native BGP 后端 - -将 `spec.bgpBackend` 设置为 `native`： - -```bash -kubectl -n metallb-system patch metallb metallb \ - --type=merge \ - -p '{"spec":{"bgpBackend":"native"}}' -``` - -等待 speaker DaemonSet 滚动更新完成： - -```bash -kubectl -n metallb-system rollout status daemonset/speaker -``` - -### 4. 验证 MetalLB FRR 容器已移除 - -列出 speaker Pod 模板中的容器： - -```bash -kubectl -n metallb-system get daemonset speaker \ - -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\n"}{end}' -``` - -输出中不应包含以下容器： - -- `frr` -- `reloader` -- `frr-metrics` -- `metrics-auth-proxy-frr`（此前启用安全 FRR 指标时） - -确认所有 speaker Pod 都已就绪： - -```bash -kubectl -n metallb-system get pods -l app=metallb,component=speaker -``` - -最后，请使用客户正常的网络监控工具验证 BGP 会话状态和路由宣告。Pod 就绪并不能证明 BGP 会话已建立，也不能证明预期的 LoadBalancer 前缀已完成宣告。 - -### 5. 可选：将 speaker 节点与主机 FRR 节点隔离 - -如果有可供 MetalLB speaker 专用的节点，请通过 `MetalLB` 资源约束 speaker DaemonSet。仅为未运行客户 FRR 服务的节点添加标签： - -```bash -kubectl label node metallb.alauda.io/speaker=true -``` - -然后为 MetalLB 资源添加节点选择器： - -```bash -kubectl -n metallb-system patch metallb metallb \ - --type=merge \ - -p '{"spec":{"nodeSelector":{"metallb.alauda.io/speaker":"true"}}}' -``` - -等待 speaker DaemonSet 滚动更新，并确认 speaker 只运行在目标节点： - -```bash -kubectl -n metallb-system rollout status daemonset/speaker -kubectl -n metallb-system get pods -l app=metallb,component=speaker -o wide -``` - -当需要节点隔离时使用此可选步骤。它可以降低主机级冲突风险，但不能替代独立 BGP 邻居和非重叠前缀的要求。 +Pod 就绪并不能证明 BGP 会话已建立，也不能证明预期 VIP 前缀已完成宣告。 ## 回滚 -如果 native 模式无法满足 BGP 要求，可恢复 MetalLB FRR 后端： - -```bash -kubectl -n metallb-system patch metallb metallb \ - --type=merge \ - -p '{"spec":{"bgpBackend":"frr"}}' -kubectl -n metallb-system rollout status daemonset/speaker -``` - -滚动更新完成后，确认所需的 FRR 相关容器已恢复，并在恢复集群服务前验证 BGP 会话。原有主机 FRR 冲突未解决时，不应回滚至 `frr`。 +若 native 模式无法满足 BGP 要求，S2 工程师可将后端恢复为 `frr`。原有主机 FRR 冲突未解决时，不应回滚。