DOC-2267: Document BYOC GCP centralized egress with VPC Peering#624
DOC-2267: Document BYOC GCP centralized egress with VPC Peering#624ppanagiotis wants to merge 5 commits into
Conversation
Follows the same Jira ticket as the AWS equivalent (PR #587 — the PR description notes "GCP and Azure paths are planned and will be tracked in separate DOC tickets", so you may want to swap in the actual GCP ticket number once it's created).
✅ Deploy Preview for rp-cloud ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis PR adds documentation for a new beta feature: centralized egress for BYOC clusters on GCP. It introduces two new pages — Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Possibly related PRs
Suggested reviewers
🚥 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 |
PR Review: Document BYOC GCP centralized egress with VPC Peering (#624)Files reviewed: 2 new pages + 3 edits (nav, create-cluster, What's New) What this PR doesAdds two GCP how-to pages: provisioning a customer hub VPC + NAT VM ( Jira alignment
Should-fix
Suggestions (minor / polish)
Impact on other files
Doc DetectiveNot a practical automated-test candidate: the gcloud steps and What works well
CodeRabbitNo CodeRabbit review or comments posted yet. |
micheleRP
changed the title
|
@ppanagiotis one open question from the review: AWS documents its Cloud API egress field in |
Remove em dashes, replace "via" with "through", remove directional references, rewrite the self-referential hub-egress intro, sentence-case the managed instance group heading, and match the AWS What's New entry format (glossterm:beta[]). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
modules/networking/pages/byoc/gcp/nat-free-egress.adoc (1)
17-17: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider "After completing these steps" for how-to convention alignment.
Line 17 reads "After reading this page, you will be able to:" which is typical for reference pages. Since this page is marked
:page-topic-type: how-toand includes procedural steps (lines 123–129), consider aligning the learning objective lead-in with how-to conventions: "After completing these steps, you will be able to:". This is a minor polish improvement for consistency with Redpanda's how-to guide standards.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@modules/networking/pages/byoc/gcp/nat-free-egress.adoc` at line 17, The learning objectives lead-in on line 17 currently reads "After reading this page, you will be able to:" which is typical for reference pages. Since this page is marked as a how-to guide (`:page-topic-type: how-to`) and contains procedural steps, change the text to "After completing these steps, you will be able to:" to align with Redpanda's how-to documentation standards.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@modules/get-started/pages/cluster-types/byoc/gcp/create-byoc-cluster-gcp.adoc`:
- Around line 48-52: The cross-reference
xref:networking:byoc/gcp/nat-free-egress.adoc[] on line 51 is missing link text
within the square brackets. For Antora cross-references to be accessible and
readable, you must provide descriptive link text. Add the destination page title
as the link text between the square brackets of the xref syntax, replacing the
empty brackets with the appropriate descriptive text for the NAT free egress
documentation page.
In `@modules/networking/pages/byoc/gcp/gcp-hub-egress.adoc`:
- Line 12: The learning objectives lead-in text uses "After reading this page"
which does not match the how-to page convention. Change the text "After reading
this page, you will be able to:" to "After completing these steps, you will be
able to:" to properly reflect the procedural nature of the how-to guide and
align with the established page type conventions.
- Around line 362-376: The gcloud compute instance-templates create command in
the hub-nat-template creation block contains the `--address=$NAT_PUBLIC_IP` flag
which is not supported by instance template creation commands. Remove this flag
entirely from the command since instance templates cannot assign specific static
IP addresses. External IP assignment must be handled separately at instance
creation time through the managed instance group, not at template definition
time.
---
Nitpick comments:
In `@modules/networking/pages/byoc/gcp/nat-free-egress.adoc`:
- Line 17: The learning objectives lead-in on line 17 currently reads "After
reading this page, you will be able to:" which is typical for reference pages.
Since this page is marked as a how-to guide (`:page-topic-type: how-to`) and
contains procedural steps, change the text to "After completing these steps, you
will be able to:" to align with Redpanda's how-to documentation standards.
🪄 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: 80bcd634-4edf-467a-bc59-a70b5e453f70
📒 Files selected for processing (5)
modules/ROOT/nav.adocmodules/get-started/pages/cluster-types/byoc/gcp/create-byoc-cluster-gcp.adocmodules/get-started/pages/whats-new-cloud.adocmodules/networking/pages/byoc/gcp/gcp-hub-egress.adocmodules/networking/pages/byoc/gcp/nat-free-egress.adoc
| gcloud compute instance-templates create hub-nat-template \ | ||
| --project=$HUB_PROJECT \ | ||
| --region=$REGION \ | ||
| --machine-type=e2-micro \ | ||
| --image-family=debian-13 \ | ||
| --image-project=debian-cloud \ | ||
| --boot-disk-size=10GB \ | ||
| --boot-disk-type=pd-balanced \ | ||
| --can-ip-forward \ | ||
| --tags=nat-direct \ | ||
| --network=$VPC_NAME \ | ||
| --subnet=$SUBNET_NAME \ | ||
| --private-network-ip=$NAT_INTERNAL_IP \ | ||
| --address=$NAT_PUBLIC_IP \ | ||
| --metadata-from-file=startup-script=/tmp/nat-startup.sh |
There was a problem hiding this comment.
🩺 Stability & Availability | 🔴 Critical
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the gcloud instance-templates create syntax and parameters
# Check the official gcloud documentation or test the command
gcloud compute instance-templates create --help | grep -A 5 "address"Repository: redpanda-data/cloud-docs
Length of output: 202
🌐 Web query:
gcloud compute instance-templates create --address parameter documentation
💡 Result:
The gcloud compute instance-templates create command does not support a top-level --address flag [1][2]. The documentation for gcloud compute instance-templates create does not list --address as a valid parameter for configuring network interfaces in an instance template [1][2]. While some other gcloud commands (such as gcloud compute instances create) allow you to assign a specific external IP address using an --address flag [1], this flag is not applicable to instance templates. Instance templates are blueprints for creating instances; because instance templates are meant to be reusable for many instances, they cannot reserve or assign a specific static IP address to the instances created from them. If you are attempting to configure network settings for an instance template, you may use other network-related flags provided by the command, such as --network, --subnet, or --network-tier, to define the network environment that instances will use [1][2].
Citations:
- 1: https://cloud.google.com/sdk/gcloud/reference/compute/instance-templates/create
- 2: https://docs.cloud.google.com/sdk/gcloud/reference/compute/instance-templates/create
Remove the --address=$NAT_PUBLIC_IP flag from the instance template creation command.
The --address parameter is not supported by gcloud compute instance-templates create [1]. Instance templates are reusable blueprints and cannot reserve or assign specific static IP addresses. Attempting to use this flag will cause the command to fail.
External IP assignment must occur at instance creation time through the managed instance group, not at template definition time. Remove line 375 entirely, or configure external IPs after the MIG creates instances from this template using a separate step or resource.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@modules/networking/pages/byoc/gcp/gcp-hub-egress.adoc` around lines 362 -
376, The gcloud compute instance-templates create command in the
hub-nat-template creation block contains the `--address=$NAT_PUBLIC_IP` flag
which is not supported by instance template creation commands. Remove this flag
entirely from the command since instance templates cannot assign specific static
IP addresses. External IP assignment must be handled separately at instance
creation time through the managed instance group, not at template definition
time.
There was a problem hiding this comment.
Partly correct, but the suggested fix would break the feature, so I've resolved it differently in commit 846c234.
What's right: --address is not a valid flag for gcloud compute instance-templates create (it's for gcloud compute instances create), so the command as written would fail. Good catch on the flag.
What's not: removing the flag (or relying on the MIG's --stateful-external-ip, which only preserves an existing IP rather than assigning a specific reserved one) would leave the NAT VM with an ephemeral public IP. That defeats the entire purpose of centralized egress: a single, predictable public IP for outbound allowlisting.
A reserved static external IP can be pinned in an instance template, on the network interface. The tested reference for this guide — the redpanda-data/cloud-examples/gcp-hub-egress Terraform — does exactly this:
network_interface {
network = google_compute_network.hub.self_link
subnetwork = google_compute_subnetwork.hub.self_link
network_ip = google_compute_address.nat_internal.address
access_config {
nat_ip = google_compute_address.nat.address
}
}Fix applied: consolidated the four separate network flags into a single --network-interface flag with address=, which is the gcloud equivalent of the Terraform access_config.nat_ip and keeps the single reserved egress IP:
- --network=$VPC_NAME \
- --subnet=$SUBNET_NAME \
- --private-network-ip=$NAT_INTERNAL_IP \
- --address=$NAT_PUBLIC_IP \
+ --network-interface=network=$VPC_NAME,subnet=$SUBNET_NAME,private-network-ip=$NAT_INTERNAL_IP,address=$NAT_PUBLIC_IP \The Console step (set the external IPv4 address to hub-nat-ip) is unchanged and still valid.
@ppanagiotis I couldn't run gcloud locally to validate this exact invocation. Could you confirm --network-interface=...,address=$NAT_PUBLIC_IP works against your tested setup / matches the Terraform, before we merge? If your tested command differs, let me know and I'll match it.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
--address is not a valid flag for `gcloud compute instance-templates create`. Consolidate the network flags into --network-interface with address= so the NAT VM keeps the single reserved public IP, mirroring the cloud-examples gcp-hub-egress Terraform (access_config.nat_ip). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…tation - Shorten gcp-hub-egress.adoc intro to 35 words (was ~74), outcome-led - Add egress_spec.gcp Cloud API section to nat-free-egress.adoc behind show-preview-api gate, matching the AWS pattern - Add GCP egress_spec block to controlplane-api.adoc partial - Remove incorrect immutability claims from AWS and GCP egress_spec entries (storage layer confirms egress_spec is updatable) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
PR Review: BYOC GCP centralized egress (#624)Files reviewed: 7 (.adoc) · Assessment: Strong PR that closely mirrors the AWS centralized egress pages. Nav, What's New, Cloud overview, and the create-cluster TIP are all wired up. One internal contradiction to reconcile. Jira alignment: DOC-2267 ("BYOC support for alternate internet egress... routing through a VPC Hub"). Fully addressed for GCP. Critical
Suggestions
Impact on other filesNo missing wiring detected. What's New entry added, nav entries for both pages (order matches AWS), Cloud overview "Features in beta" updated, create-cluster TIP added, and all xref targets and anchors resolve. Only concern is the AWS immutability follow-up above. CodeRabbit triageAll three findings already resolved:
What works well
|
2 participants
Description
Resolves https://redpandadata.atlassian.net/browse/DOC-2267
Documents centralized egress for BYOC clusters on GCP (beta), the GCP counterpart to the AWS Transit Gateway egress feature. Centralized egress lets customers route all BYOC cluster internet traffic through their own GCP hub VPC and NAT VM instead of a per-cluster Cloud NAT, so outbound traffic exits through a single, predictable public IP for inspection and allowlisting.
This PR adds:
Audience: platform administrators. Mirrors the structure of the AWS centralized egress pages.
Preview pages
Checks