kube-ovn: update egress gateway document#685
kube-ovn: update egress gateway document#685zhangzujian wants to merge 1 commit intoalauda:masterfrom
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughRewrites the Kube‑OVN Egress Gateway doc: reframes as VPC Egress Gateway, replaces macvlan examples with Kube‑OVN underlay subnet/NAD examples, updates VpcEgressGateway fields to Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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.
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/configure_egress_gateway.mdx (1)
489-541:⚠️ Potential issue | 🟡 MinorInconsistent VPC name between gateway2 spec and sample output.
The manifest on Line 496 sets
vpc: ovn-cluster, but the examplekubectl get vegoutput on Line 541 shows the VPC column asvpc1. Readers following the example will not seevpc1. Please align the two (either change the output toovn-cluster, or changespec.vpctovpc1— noting that the surroundinglr-policy-list ovn-clustercommands and LRP outputs on Lines 548–566 assume theovn-clusterVPC, so updating thekubectl get vegoutput is likely the correct fix).Also worth double-checking: the OVN address-set hash
$VEG.8ca38ae7da18on Lines 556–557 is identical to the one shown forgateway1on Lines 368–369. Since that identifier is derived from the gateway identity, it should differ betweengateway1andgateway2— please regenerate this sample output from an actualgateway2deployment.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` around lines 489 - 541, The VPC name in the VpcEgressGateway manifest (metadata name: gateway2, spec.vpc: ovn-cluster) does not match the sample `kubectl get veg` output (VPC column shows vpc1) and the OVN address-set hash ($VEG.8ca38ae7da18) is duplicated from gateway1; update the sample output to use VPC "ovn-cluster" and regenerate the gateway2-specific OVN identifiers (address-set hash) so they differ from gateway1, ensuring consistency between the manifest (spec.vpc), the `kubectl get veg` output, and the downstream `lr-policy-list`/LRP outputs.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx`:
- Around line 489-541: The VPC name in the VpcEgressGateway manifest (metadata
name: gateway2, spec.vpc: ovn-cluster) does not match the sample `kubectl get
veg` output (VPC column shows vpc1) and the OVN address-set hash
($VEG.8ca38ae7da18) is duplicated from gateway1; update the sample output to use
VPC "ovn-cluster" and regenerate the gateway2-specific OVN identifiers
(address-set hash) so they differ from gateway1, ensuring consistency between
the manifest (spec.vpc), the `kubectl get veg` output, and the downstream
`lr-policy-list`/LRP outputs.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 041b8d41-b092-4595-bec1-6dc805c2d30e
📒 Files selected for processing (1)
docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx
zhangzujian
force-pushed
the
veg
branch
2 times, most recently
from
ecf263a to
9014c12
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx (2)
389-422: Consider moving the external-IP preparation note above the scale command.The note at lines 420-422 ("Before scaling out replicas, make sure to prepare enough external IPs...") currently appears after the
kubectl scaleexample. Readers walking through the steps will already have executed the scale by the time they reach the note. Placing it right before the command block would make the requirement hard to miss.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` around lines 389 - 422, Move the preparatory note about external IPs ("Before scaling out replicas, make sure to prepare enough external IPs in the external subnet and specify them in _.spec.externalIPs_.") so it appears immediately before the kubectl scale example (the block starting with "kubectl scale veg -n default gateway1 --replicas=2") rather than after the command; update surrounding text so readers see the .spec.externalIPs requirement prior to executing the scale operation (ensure the note remains unchanged in content and formatting).
489-509: Optional: clarify behavior whenexternalIPsis omitted.
gateway2specifiesreplicas: 2withoutexternalIPs, while thegateway1callouts (lines 218-220) recommend reserving.spec.replicas + 1IPs inexternalIPs. A short sentence confirming thatexternalIPsis optional (and, when omitted, IPs are auto-allocated from the external subnet) would prevent readers from interpreting the earlier guidance as mandatory.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` around lines 489 - 509, Add a short clarifying sentence near the gateway2 example stating that .spec.externalIPs is optional: when omitted (as in the VpcEgressGateway "gateway2" example) IPs will be auto-allocated from the specified externalSubnet, and the earlier note about reserving .spec.replicas + 1 IPs applies only when you manually set .spec.externalIPs (as in the "gateway1" example). Reference the VpcEgressGateway resource and the fields .spec.replicas, .spec.externalIPs, and .spec.externalSubnet so readers understand which behavior applies.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx`:
- Around line 124-127: The callout markers are misaligned: the marker is on
"cniVersion" but the bodies describe "type", "server_socket" and "provider";
update the markup so the callouts match their described keys—either remove the
callout from "cniVersion" and add the callout to the NAD `provider` key
("provider": "underlay-ext.default.ovn") to match existing bodies, or add a new
callout body for `cniVersion`; ensure the callout markers now reference the
exact JSON keys `"type"`, `"server_socket"` and `"provider"` so each description
aligns with the correct line.
---
Nitpick comments:
In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx`:
- Around line 389-422: Move the preparatory note about external IPs ("Before
scaling out replicas, make sure to prepare enough external IPs in the external
subnet and specify them in _.spec.externalIPs_.") so it appears immediately
before the kubectl scale example (the block starting with "kubectl scale veg -n
default gateway1 --replicas=2") rather than after the command; update
surrounding text so readers see the .spec.externalIPs requirement prior to
executing the scale operation (ensure the note remains unchanged in content and
formatting).
- Around line 489-509: Add a short clarifying sentence near the gateway2 example
stating that .spec.externalIPs is optional: when omitted (as in the
VpcEgressGateway "gateway2" example) IPs will be auto-allocated from the
specified externalSubnet, and the earlier note about reserving .spec.replicas +
1 IPs applies only when you manually set .spec.externalIPs (as in the "gateway1"
example). Reference the VpcEgressGateway resource and the fields .spec.replicas,
.spec.externalIPs, and .spec.externalSubnet so readers understand which behavior
applies.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fbd9e290-f6b3-4a7d-ac72-563b99de994e
📒 Files selected for processing (1)
docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx
There was a problem hiding this comment.
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/configure_egress_gateway.mdx (1)
499-545:⚠️ Potential issue | 🟡 MinorExternal IP sample output doesn't match
externalIPsin the spec.The
gateway2spec declaresexternalIPs: [172.17.0.11, 172.17.0.12, 172.17.0.13](lines 500‑502), but the sample status output on line 545 reportsEXTERNAL IPS ["172.17.0.13","172.17.0.14"]. Per the CRD, gateway instances must allocate IPs from the declaredexternalIPslist, so172.17.0.14should not appear here. Please align the two — either add172.17.0.14to the spec (and bump the reservation toreplicas + 1 = 3) or change the status example to IPs that are actually in the list.✏️ Proposed fix (align status with spec)
-gateway2 ovn-cluster 2 true underlay-ext Completed true ["10.16.0.102","10.16.0.103"] ["172.17.0.13","172.17.0.14"] ["node1","node2"] 58s +gateway2 ovn-cluster 2 true underlay-ext Completed true ["10.16.0.102","10.16.0.103"] ["172.17.0.12","172.17.0.13"] ["node1","node2"] 58s🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` around lines 499 - 545, The sample status output for resource gateway2 is inconsistent with the manifest: externalIPs lists 172.17.0.11–13 but the status shows 172.17.0.13 and 172.17.0.14; update either the spec or the status to match. Specifically, edit the manifest block with externalIPs (externalIPs) or the status example line (kubectl get veg ... EXTERNAL IPS) so the EXTERNAL IPS are drawn only from the declared externalIPs list (e.g., replace 172.17.0.14 with one of 172.17.0.11/0.12 or add 172.17.0.14 to externalIPs and adjust replicas/reservation accordingly) ensuring gateway2's replicas count and reservation match the chosen change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx`:
- Around line 499-545: The sample status output for resource gateway2 is
inconsistent with the manifest: externalIPs lists 172.17.0.11–13 but the status
shows 172.17.0.13 and 172.17.0.14; update either the spec or the status to
match. Specifically, edit the manifest block with externalIPs (externalIPs) or
the status example line (kubectl get veg ... EXTERNAL IPS) so the EXTERNAL IPS
are drawn only from the declared externalIPs list (e.g., replace 172.17.0.14
with one of 172.17.0.11/0.12 or add 172.17.0.14 to externalIPs and adjust
replicas/reservation accordingly) ensuring gateway2's replicas count and
reservation match the chosen change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 69a8fd95-42e5-47b6-ab88-4b93a1e3460d
📒 Files selected for processing (1)
docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx (1)
124-127:⚠️ Potential issue | 🟡 MinorCallout/body alignment still looks off for the NAD block.
The prior review thread was marked as resolved, but the current markup still places callouts on
cniVersion,type,server_socket(lines 124–126), while theproviderkey at line 127 has no marker. Meanwhile, Callouts bodies 1–3 read:
- "Use the Kube-OVN CNI plugin for the secondary network." — semantically describes
"type": "kube-ovn", notcniVersion.- "Kube-OVN daemon socket used by the CNI plugin." — describes
server_socket.- "Provider name in the format
<NAD>.<ns>.ovn." — describesprovider, which currently has no callout.So bodies 1/2/3 are one line ahead of the markers they describe. Please either drop the callout on
cniVersionand add one toprovider, or add a dedicated body forcniVersion.✏️ Proposed fix
config: |- { - "cniVersion": "0.3.0", [!code callout] + "cniVersion": "0.3.0", "type": "kube-ovn", [!code callout] "server_socket": "/run/openvswitch/kube-ovn-daemon.sock", [!code callout] - "provider": "underlay-ext.default.ovn" + "provider": "underlay-ext.default.ovn" [!code callout] }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` around lines 124 - 127, The callouts are misaligned: the markers are on "cniVersion", "type", "server_socket" but the bodies describe "type", "server_socket", and "provider" respectively; fix by removing the callout marker from "cniVersion" and adding the callout marker to "provider" so the bodies match the keys ("type", "server_socket", "provider"); ensure the callout texts remain: "Use the Kube-OVN CNI plugin for the secondary network." for "type", "Kube-OVN daemon socket used by the CNI plugin." for "server_socket", and "Provider name in the format <NAD>.<ns>.ovn." for "provider".
🧹 Nitpick comments (2)
docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx (2)
225-225: Callout 9 mentions Pod selectors but the example only showsnamespaceSelector.Either add a
podSelectorentry underselectorsin the YAML example, or reword the callout to match the example ("Namespace selectors used to select Pods..."). Readers copying the snippet may otherwise be unsure of the full shape ofselectors[].🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` at line 225, Callout 9 references both Namespace selectors and Pod selectors but the YAML example only shows namespaceSelector; either add a podSelector field under the selectors array in the example (showing an empty or example pod label selector) or change the Callout 9 text to only mention namespaceSelector (e.g., "Namespace selectors used to select Pods..."). Update the example's selectors block (selectors / namespaceSelector / podSelector) or amend the callout text (Callout 9) so the example and description match.
622-622: Consider using the Kube-OVN documentation stable alias for future-proofing.The hard-coded link to
v1.15.xis currently correct—v1.15.x is the latest stable Kube-OVN documentation version. However, to reduce maintenance burden when Kube-OVN releases v1.16.x or newer, consider using the stable alias instead:https://kubeovn.github.io/docs/stable/en/vpc/vpc-egress-gateway/This way, readers will always land on the latest stable Kube-OVN reference without requiring documentation updates.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` at line 622, Replace the hard-coded versioned Kube-OVN URL "[Egress Gateway - Kube-OVN Document](https://kubeovn.github.io/docs/v1.15.x/en/vpc/vpc-egress-gateway/)" with the stable alias URL "https://kubeovn.github.io/docs/stable/en/vpc/vpc-egress-gateway/" so readers always reach the latest stable Kube-OVN docs; locate the Markdown link text and update only the URL portion to use the /docs/stable/... path.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx`:
- Line 615: Rename the section heading "Changing the number of replicas" to a
more specific phrase like "Reducing the number of replicas" or "Scaling down
replicas" and update the section text to focus only on scale-down behavior
(terminating gateway Pods may interrupt existing flows) rather than implying
that any scaling (including scaling up) will interrupt traffic; ensure
references in the same paragraph to "replicas" or "scaling" use the chosen
narrower wording to avoid discouraging horizontal scaling.
---
Duplicate comments:
In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx`:
- Around line 124-127: The callouts are misaligned: the markers are on
"cniVersion", "type", "server_socket" but the bodies describe "type",
"server_socket", and "provider" respectively; fix by removing the callout marker
from "cniVersion" and adding the callout marker to "provider" so the bodies
match the keys ("type", "server_socket", "provider"); ensure the callout texts
remain: "Use the Kube-OVN CNI plugin for the secondary network." for "type",
"Kube-OVN daemon socket used by the CNI plugin." for "server_socket", and
"Provider name in the format <NAD>.<ns>.ovn." for "provider".
---
Nitpick comments:
In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx`:
- Line 225: Callout 9 references both Namespace selectors and Pod selectors but
the YAML example only shows namespaceSelector; either add a podSelector field
under the selectors array in the example (showing an empty or example pod label
selector) or change the Callout 9 text to only mention namespaceSelector (e.g.,
"Namespace selectors used to select Pods..."). Update the example's selectors
block (selectors / namespaceSelector / podSelector) or amend the callout text
(Callout 9) so the example and description match.
- Line 622: Replace the hard-coded versioned Kube-OVN URL "[Egress Gateway -
Kube-OVN
Document](https://kubeovn.github.io/docs/v1.15.x/en/vpc/vpc-egress-gateway/)"
with the stable alias URL
"https://kubeovn.github.io/docs/stable/en/vpc/vpc-egress-gateway/" so readers
always reach the latest stable Kube-OVN docs; locate the Markdown link text and
update only the URL portion to use the /docs/stable/... path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3de380ee-6f8c-4a14-a1fc-f7d963b393f2
📒 Files selected for processing (1)
docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx
|
|
||
| The following operations may briefly interrupt egress traffic because they delete or recreate gateway instances: | ||
|
|
||
| 1. Changing the number of replicas |
There was a problem hiding this comment.
"Changing the number of replicas" is slightly too broad.
Scaling up should not interrupt traffic for existing flows; only scale-down (terminating a gateway Pod that is handling flows) does. Consider narrowing this to "Reducing the number of replicas" or "Scaling down replicas" to avoid discouraging horizontal scaling.
✏️ Proposed wording
-1. Changing the number of replicas
+1. Reducing the number of replicas (scale-down)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` at
line 615, Rename the section heading "Changing the number of replicas" to a more
specific phrase like "Reducing the number of replicas" or "Scaling down
replicas" and update the section text to focus only on scale-down behavior
(terminating gateway Pods may interrupt existing flows) rather than implying
that any scaling (including scaling up) will interrupt traffic; ensure
references in the same paragraph to "replicas" or "scaling" use the chosen
narrower wording to avoid discouraging horizontal scaling.
Co-authored-by: Copilot <copilot@github.com> Signed-off-by: zhangzujian <zhangzujian.7@gmail.com>
There was a problem hiding this comment.
♻️ Duplicate comments (2)
docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx (2)
124-155:⚠️ Potential issue | 🟡 MinorCallout markers on the NAD block are still off-by-one against the body text.
Despite the earlier round being marked addressed, the mismatch persists:
- Line 124
cniVersioncarries callout ① but body ① ("Use the Kube-OVN CNI plugin for the secondary network") describestype: kube-ovn.- Line 125
type→ body ② ("Kube-OVN daemon socket…"), which describesserver_socket.- Line 126
server_socket→ body ③ ("Provider name in the format…"), which describes the NADprovider.- Line 127
providerhas no marker.Either drop the callout on
cniVersionand add one toprovider, or add a body forcniVersion. The former matches the existing body text.✏️ Proposed fix
config: |- { - "cniVersion": "0.3.0", [!code callout] + "cniVersion": "0.3.0", "type": "kube-ovn", [!code callout] "server_socket": "/run/openvswitch/kube-ovn-daemon.sock", [!code callout] - "provider": "underlay-ext.default.ovn" + "provider": "underlay-ext.default.ovn" [!code callout] }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` around lines 124 - 155, The NAD callout markers are misaligned with the explanatory list: cniVersion incorrectly has a callout while provider is missing one; update the NAD block so the callouts match the bodies by removing the callout from "cniVersion" and adding the corresponding callout to "provider" (ensure "type", "server_socket", and "provider" map to bodies 1–3 respectively), or alternatively add a new explanatory body for "cniVersion" if you prefer to keep its callout; reference the identifiers "cniVersion", "type", "server_socket", and "provider" to locate and adjust the markers.
620-625:⚠️ Potential issue | 🟡 Minor"Changing the number of replicas" is still too broad.
Same concern as the previous round: scaling up does not terminate existing gateway Pods and therefore should not interrupt existing flows — only scale-down does. Consider narrowing item 1 to scale-down so you don't discourage horizontal scaling.
✏️ Proposed wording
-1. Changing the number of replicas +1. Reducing the number of replicas (scale-down)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx` around lines 620 - 625, The phrase "Changing the number of replicas" in list item 1 is too broad; update that item to explicitly say reducing replicas or scale-down (e.g., "Reducing the number of replicas (scale-down)") and optionally add a short parenthetical note that scaling up does not terminate existing gateway Pods so it does not interrupt existing flows; modify the list item text that currently reads "Changing the number of replicas" accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx`:
- Around line 124-155: The NAD callout markers are misaligned with the
explanatory list: cniVersion incorrectly has a callout while provider is missing
one; update the NAD block so the callouts match the bodies by removing the
callout from "cniVersion" and adding the corresponding callout to "provider"
(ensure "type", "server_socket", and "provider" map to bodies 1–3 respectively),
or alternatively add a new explanatory body for "cniVersion" if you prefer to
keep its callout; reference the identifiers "cniVersion", "type",
"server_socket", and "provider" to locate and adjust the markers.
- Around line 620-625: The phrase "Changing the number of replicas" in list item
1 is too broad; update that item to explicitly say reducing replicas or
scale-down (e.g., "Reducing the number of replicas (scale-down)") and optionally
add a short parenthetical note that scaling up does not terminate existing
gateway Pods so it does not interrupt existing flows; modify the list item text
that currently reads "Changing the number of replicas" accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 37ef6ee4-16ba-41ef-8672-c064f91a7bf9
📒 Files selected for processing (1)
docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx
2 participants
Summary by CodeRabbit