Skip to content

Document cross-namespace clusterRef for shadow links in Kubernetes (26.1) #1794

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
JakeSCahill merged 1 commit into from
Jul 15, 2026
Merged

Document cross-namespace clusterRef for shadow links in Kubernetes (26.1) #1794

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 31 additions & 2 deletions modules/manage/pages/kubernetes/shadowing/k-shadow-linking.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,10 +70,39 @@ The operator automatically resolves cluster connection details from the referenc
+
[NOTE]
====
When using `clusterRef`, the operator handles authentication automatically using the cluster's internal credentials. For cross-namespace or external clusters, use `staticConfiguration` instead.
When using `clusterRef`, the operator handles authentication automatically using the cluster's internal credentials. For clusters that are not managed by the same operator, use `staticConfiguration` instead.
====
+
By default, a `clusterRef` resolves in the same namespace as the `ShadowLink` resource. Starting in Redpanda Operator v26.1.9, if the source and shadow clusters are managed by the same operator but deployed in different namespaces on the same Kubernetes cluster, you can set the `namespace` field on the source cluster's `clusterRef`:
+
.`shadowlink.yaml`
[,yaml]
----
apiVersion: cluster.redpanda.com/v1alpha2
kind: ShadowLink
metadata:
name: disaster-recovery-link
spec:
shadowCluster:
clusterRef:
name: redpanda-shadow
sourceCluster:
clusterRef:
name: redpanda-source
namespace: <source-namespace>
topicMetadataSyncOptions:
autoCreateShadowTopicFilters:
- name: '*'
filterType: include
patternType: literal
----
+
[WARNING]
====
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`:
Comment on lines +102 to +105

@coderabbitai coderabbitai Bot Jul 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 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.

@coderabbitai coderabbitai Bot Jul 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ 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

+
Create a shadow link with explicit connection details:
+
Expand Down
Loading