You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
💡[COMMAND REQUEST] Multi-Cluster Support for create, read, apply, and logs #31
Supporting create, read, apply, and logs across multiple clusters leads to duplicated logic and higher maintenance. Direct use of apply reduces the effectiveness of label-based binding policies.
Proposed Solution
Overload these kubectl verbs to add multi-cluster functionality. Aggregate results across clusters. Guide users toward using label-based binding policies for resource propagation instead of direct multi-cluster apply.
Before starting implementation, I plan to review the existing kubectl multi command architecture to understand how multi-cluster operations are currently handled and identify the common execution path that can be reused across commands.
My approach would be to:
Design a reusable execution flow for multi-cluster command dispatch rather than duplicating logic for each verb.
Ensure results from multiple clusters are aggregated consistently while preserving cluster-specific context.
Keep the implementation aligned with the project's recommendation of using label-based binding policies, avoiding changes that encourage direct multi-cluster apply as the primary workflow.
If the scope is too large for a single PR, I'm happy to split the work into smaller incremental changes based on your guidance.
If this issue is still available, I'd be glad to work on it. Please let me know if there's any preferred implementation approach or if you'd like the work broken into multiple PRs.
Activity
clubanderson commentedon Aug 27, 2025
/help-wanted
Om-Beast commentedon Jul 20, 2026
Hi @oorrja,
I'd like to work on this enhancement.
Before starting implementation, I plan to review the existing
kubectl multicommand architecture to understand how multi-cluster operations are currently handled and identify the common execution path that can be reused across commands.My approach would be to:
applyas the primary workflow.If this issue is still available, I'd be glad to work on it. Please let me know if there's any preferred implementation approach or if you'd like the work broken into multiple PRs.