Document cross-namespace clusterRef for shadow links in Kubernetes (26.1)#1794
Conversation
The Redpanda Operator now supports an optional namespace field on clusterRef (redpanda-operator#1562, backported in #1663), so a ShadowLink can reference a source cluster in a different namespace on the same Kubernetes cluster. Add an example and state that this topology is for development and testing only; production disaster recovery should place source and shadow clusters in separate Kubernetes clusters and cloud regions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
✅ Deploy Preview for redpanda-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
📝 WalkthroughWalkthroughUpdated the Kubernetes Operator “Create a shadow link” instructions to clarify Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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: 2
🤖 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/manage/pages/kubernetes/shadowing/k-shadow-linking.adoc`:
- Around line 102-105: Update the separate-cluster production guidance around
staticConfiguration to require broker addresses that are externally reachable
from the other Kubernetes cluster, rather than cluster-local *.svc.cluster.local
names. Add a concise note about configuring externally reachable advertised
listeners, or replace the example with a valid separate-cluster configuration
while preserving the existing same-cluster example.
- Line 105: Update the staticConfiguration guidance in the ShadowLink
documentation to state that the Secrets referenced by caCertSecretRef and
passwordSecretRef must exist in the ShadowLink’s <shadow-namespace>. Clarify
that users must create or copy equivalent Secrets there; Secrets with the same
names only in <source-namespace> are not sufficient.
🪄 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: 10b65d46-d2fe-4696-a3c4-dc4c32266081
📒 Files selected for processing (1)
modules/manage/pages/kubernetes/shadowing/k-shadow-linking.adoc
| Use this same-cluster, cross-namespace topology only for development and testing, such as rehearsing replication and failover on a single Kubernetes cluster. A single Kubernetes cluster is a single failure domain, so it cannot provide disaster recovery. For production, deploy the source and shadow clusters in separate Kubernetes clusters, ideally in separate cloud regions, and connect them using `staticConfiguration`. | ||
| ==== | ||
|
|
||
| - For external or cross-namespace clusters, use `staticConfiguration`: | ||
| - For external clusters, or clusters that are not managed by the same operator, use `staticConfiguration`: |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Use reachable broker addresses for the separate-cluster production example.
The new production guidance recommends separate Kubernetes clusters, but the staticConfiguration example below uses *.svc.cluster.local broker names. Those addresses are cluster-local and generally cannot be resolved or reached from another cluster. Add a note requiring externally reachable advertised listeners, or provide a separate-cluster example.
🤖 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/manage/pages/kubernetes/shadowing/k-shadow-linking.adoc` around lines
102 - 105, Update the separate-cluster production guidance around
staticConfiguration to require broker addresses that are externally reachable
from the other Kubernetes cluster, rather than cluster-local *.svc.cluster.local
names. Add a concise note about configuring externally reachable advertised
listeners, or replace the example with a valid separate-cluster configuration
while preserving the existing same-cluster example.
| ==== | ||
|
|
||
| - For external or cross-namespace clusters, use `staticConfiguration`: | ||
| - For external clusters, or clusters that are not managed by the same operator, use `staticConfiguration`: |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Document where the staticConfiguration Secrets must exist.
caCertSecretRef and passwordSecretRef are namespace-scoped, and this ShadowLink is applied in <shadow-namespace>. The example uses source-cluster Secret names but does not tell users to create or copy equivalent Secrets into the shadow namespace, so the manifest can fail even when the Secrets exist in <source-namespace>.
🤖 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/manage/pages/kubernetes/shadowing/k-shadow-linking.adoc` at line 105,
Update the staticConfiguration guidance in the ShadowLink documentation to state
that the Secrets referenced by caCertSecretRef and passwordSecretRef must exist
in the ShadowLink’s <shadow-namespace>. Clarify that users must create or copy
equivalent Secrets there; Secrets with the same names only in <source-namespace>
are not sufficient.
Source: Learnings
|
Operator 26.1.9 is already released https://github.com/redpanda-data/redpanda-operator/releases/tag/operator%2Fv26.1.9 |
|
@JakeSCahill Could you review |
3 participants
Description
26.1 counterpart of #1793.
The optional
namespacefield onclusterRefwas backported to the operator's 26.1.x line in redpanda-data/redpanda-operator#1663 and will ship in operator v26.1.9 (v26.1.8 was cut before the backport merged). This updates the Configure Shadowing in Kubernetes page (26.1) to:clusterRef.namespace, noting it requires Redpanda Operator v26.1.9 or later.staticConfiguration.Page previews
🤖 Generated with Claude Code