docs: add MetalLB underlay configuration doc for ACP >= 4.2.2#541
docs: add MetalLB underlay configuration doc for ACP >= 4.2.2#541
Conversation
添加 Kube-OVN Underlay + MetalLB LoadBalancer Service 配置文档： - 支持 ACP >= 4.3 - IPPool 名称统一为 acp-underlay-pool - 添加 IPv4 only 限制说明 - 添加 Service 指定 IPPool/fixed IP 的注释说明
changluyi
changed the title
WalkthroughLower ACP prerequisite to >= 4.2.2, add IPv4-only support note, rename MetalLB IPAddressPool and L2Advertisement from Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@docs/en/configure/networking/how_to/kube_ovn/config_metallb_underlay.mdx`:
- Around line 13-15: Update the "Environment Requirements" section by changing
the ACP version requirement bullet "- **ACP version**: >= 4.2.2" to "- **ACP
version**: >= 4.3" so the document's stated requirement matches the PR objective
and commit message; edit the line containing the ACP version entry in the
Environment Requirements block.
🧹 Nitpick comments (1)
docs/en/configure/networking/how_to/kube_ovn/config_metallb_underlay.mdx (1)
171-172: Consider usingmetallb.io/loadBalancerIPsannotation instead of deprecatedspec.loadBalancerIP.The annotation
metallb.io/address-poolis correct for the current MetalLB version. However,spec.loadBalancerIPis deprecated by Kubernetes and MetalLB recommends using the annotationmetallb.io/loadBalancerIPsas the preferred way to request specific IPs. Whilespec.loadBalancerIPstill works, updating the documentation comment to suggest the modern approach would better align with MetalLB's current guidance and improve future compatibility.
Deploying alauda-container-platform with
|
| Latest commit: |
b1e124c
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://af3d48b4.alauda-container-platform.pages.dev |
| Branch Preview URL: | https://feat-add-metallb-underlay-do-mwzb.alauda-container-platform.pages.dev |
Signed-off-by: clyi <clyi@alauda.io>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/en/configure/networking/how_to/kube_ovn/config_metallb_underlay.mdx (1)
167-181:⚠️ Potential issue | 🟡 MinorStep 5 Service example is inconsistent with step 7 and mentions deprecated API field.
Two concerns:
Missing annotation: The Service in step 5 relies on
autoAssignwithout themetallb.io/address-poolannotation, whereas step 7 explicitly includes it for new services. If multipleIPAddressPoolresources exist, the Service here could receive an IP from an unintended pool. Add the annotation to make the example consistent with step 7 and self-contained.
spec.loadBalancerIPdeprecation: The comment on line 172 referencesspec.loadBalancerIP, which was deprecated in Kubernetes 1.24 for being under-specified and not supporting dual-stack. MetalLB's recommended replacement is themetallb.io/loadBalancerIPsannotation.Suggested update
apiVersion: v1 kind: Service metadata: name: backend-lb-service - # To use specific IPPool: add annotation `metallb.io/address-pool: acp-underlay-pool` - # To use fixed IP: set `spec.loadBalancerIP: 10.180.208.201` + annotations: + metallb.io/address-pool: acp-underlay-pool # Specify the Underlay address pool + # To use a fixed IP, add: metallb.io/loadBalancerIPs: 10.180.208.201 spec: type: LoadBalancer externalTrafficPolicy: Local # **IMPORTANT**: Required for preserving source IP and enabling direct Pod routing
🤖 Fix all issues with AI agents
In `@docs/en/configure/networking/how_to/kube_ovn/config_metallb_underlay.mdx`:
- Around line 198-208: Add a clear warning to the "7. Migrating Existing
Services" section explaining that changing or adding the metallb.io/address-pool
annotation (e.g., setting to acp-underlay-pool via kubectl annotate service
<existing-service-name> metallb.io/address-pool=acp-underlay-pool --overwrite)
will cause MetalLB to deallocate the current external IP and assign a new one
(service IP change), and instruct users to update DNS records and client
configurations (and verify with kubectl get svc <existing-service-name> -o wide)
before performing the migration to avoid disruptions.
🧹 Nitpick comments (1)
docs/en/configure/networking/how_to/kube_ovn/config_metallb_underlay.mdx (1)
210-235: The new service example and verification look good overall.Minor nit: The
curlcommand on line 234 hardcodes10.180.208.200, which may not be the IP assigned to a newly created service. Consider replacing it with a note to use the actual assigned IP, e.g.:-curl http://10.180.208.200 +curl http://<EXTERNAL-IP> # Use the EXTERNAL-IP from the kubectl get svc output aboveThis same suggestion applies to line 195 in step 6.
| ### 7. Migrating Existing Services | ||
|
|
||
| For existing services using the old address pool (node subnet only), you can migrate them to the new Underlay address pool: | ||
|
|
||
| ```bash | ||
| # Add annotation to migrate existing service | ||
| kubectl annotate service <existing-service-name> metallb.io/address-pool=acp-underlay-pool --overwrite | ||
|
|
||
| # Verify the service has been assigned a new IP from the Underlay pool | ||
| kubectl get svc <existing-service-name> -o wide | ||
| ``` |
There was a problem hiding this comment.
Add a warning that migration will change the service's external IP.
When metallb.io/address-pool is added/changed, MetalLB deallocates the current IP and assigns a new one from the target pool. This causes a service IP change, which can disrupt existing clients. The migration section should warn users about this and recommend updating DNS records or client configurations accordingly.
Suggested addition
### 7. Migrating Existing Services
For existing services using the old address pool (node subnet only), you can migrate them to the new Underlay address pool:
+> ⚠️ **Warning**: Migrating a service to a new address pool will change its external IP address. Ensure DNS records and client configurations are updated accordingly. Plan this migration during a maintenance window to minimize disruption.
+
```bash
# Add annotation to migrate existing service
kubectl annotate service <existing-service-name> metallb.io/address-pool=acp-underlay-pool --overwrite🤖 Prompt for AI Agents
In `@docs/en/configure/networking/how_to/kube_ovn/config_metallb_underlay.mdx`
around lines 198 - 208, Add a clear warning to the "7. Migrating Existing
Services" section explaining that changing or adding the metallb.io/address-pool
annotation (e.g., setting to acp-underlay-pool via kubectl annotate service
<existing-service-name> metallb.io/address-pool=acp-underlay-pool --overwrite)
will cause MetalLB to deallocate the current external IP and assign a new one
(service IP change), and instruct users to update DNS records and client
configurations (and verify with kubectl get svc <existing-service-name> -o wide)
before performing the migration to avoid disruptions.
2 participants
添加 Kube-OVN Underlay + MetalLB LoadBalancer Service 配置文档：
Summary by CodeRabbit