安装方式
手动下载安装
下载 ZIP 后解压到技能目录即可安装。若在桌面客户端 WebView中直接下载出现异常,本站会改为提示页 + 原始链接,请按页内说明操作。
下载 ZIP (shub-k8-multicluster-v1.0.0.zip)触发指令
/k8s-multicluster
跨平台安装指引
该技能声明兼容以下 1 个平台,将 ZIP 解压到对应目录即可被识别。
unzip shub-k8-multicluster-v1.0.0.zip -d ~/.claude/skills/
mkdir -p 创建;启用 Skill 后请重启对应 Agent 让配置生效。
使用指南
Kubernetes 多集群
围绕 Kubernetes 多集群:多集群上下文切换、联邦或 GitOps 跨集群操作提示;与「kubernetes」基础向互补。 无需在每次任务前把零散英文说明手工拼进上下文,也 减少 与客户端默认行为脱节的试错;具体命令、钩子与 JSON 参数仍以 ZIP 包内 SKILL.md 为权威。下文结构与站内 MCP CLI 类专题稿相同:何时用、前置、流程、速查与故障。
何时使用
- 多集群上下文切换、联邦或 GitOps 跨集群操作提示
- 与「kubernetes」基础向互补
- 已获取本技能 ZIP,并准备在 Claude Code / OpenClaw 中按 SKILL.md 挂载。
- 希望用中文专题稿快速判断「该不该启用」,再深入英文 SKILL 查参数与边界。
- 需要与团队对齐同一套触发方式、目录约定或回调格式时。
前置条件
- 通用:可运行 Claude Code 或文档要求的客户端;有可读写的项目工作区(或 SKILL.md 指定的沙箱目录)。
- 权威细节:API Key / OAuth、钩子路径、环境变量以 ZIP 内 SKILL.md 为准。
典型流程
- 从 ClawHub / 站内分发获取技能 ZIP,校验版本与校验和(若提供)。
- 阅读 SKILL.md 的安装段落:目录落点、客户端类型(Claude Code / OpenClaw / 脚本)。
- 用文档中的最小示例完成第一次调用(单文件修改、单次查询或单次委派)。
- 确认工作目录、权限边界与输出路径后,再处理多文件或长耗时任务。
- 需要回调 / Webhook / 通知时,按 SKILL.md 配置端点并在测试环境先验通。
与 ZIP / SKILL.md 的关系
站内专题稿与 MCP CLI 类 oss 稿同样:概括何时用、怎么接、怎么排错;命令模板、钩子名、JSON 字段、版本矩阵一律以 ZIP 内 SKILL.md 与 ClawHub 上游为准。
命令示例(摘自包内 SKILL.md)
以下为从上游 SKILL.md(或入库正文)自动抽取的终端/脚本片段;路径、环境变量与参数以当前 ZIP 与官方说明为准。
ClawHub slug:k8-multicluster(安装命令以 SKILL.md / claw CLI 为准)。
站内入库时的触发命令(完整语义见 ZIP):
# 使用本技能时可在对话中引用或执行上述指令;完整参数与示例见下载包内 SKILL.md。
/k8s-multicluster
最佳实践
- 先 SKILL.md 再猜参数;站内专题稿不替代 schema 与必填字段说明。
- 委派任务时写清验收标准(命令、文件路径、测试命令),减少来回追问。
- 长任务用文档推荐的回调 / 日志落盘代替高频轮询,省 Token 也省机器负载。
- 多技能同时启用时,注意钩子加载顺序与重复工具调用(以 SKILL.md 冲突说明为准)。
调试与排错
- 打开 stderr 与客户端日志;PTY/tmux 场景同时看面板最后几十行输出。
- 参数错误时对照 SKILL.md 中的 JSON/CLI 示例(引号、转义、工作目录)。
- 网络类失败:查代理、防火墙、MCP 传输方式(stdio / HTTP / SSE)。
速查
| 动作 | 说明 |
|------|------|
| 获取技能包 | ClawHub / 站内 ZIP,核对版本 |
| 权威步骤 | 优先阅读 ZIP 内 SKILL.md |
| 首次试跑 | 使用 SKILL.md 最小示例 |
| 验收 | 对照路径、测试命令或回调负载 |
常见故障
- 无输出或立即退出 → 工作目录错误、依赖未装、或 Claude Code 未登录;按 SKILL.md 自检清单执行。
- 权限被拒绝 → 检查沙箱路径、
--permission-mode与工具白名单。 - 与简介不符 → 以英文 SKILL 与上游仓库为准,站内稿仅作结构化导读。
# Multi-Cluster Kubernetes Management
Cross-cluster operations and context management using kubectl-mcp-server's multi-cluster support.
## Context Management
### List Available Contexts
```
list_contexts_tool()
```
### View Current Context
```
kubeconfig_view() # Shows sanitized kubeconfig
```
### Switch Context
CLI: `kubectl-mcp-server context <context-name>`
## Cross-Cluster Operations
All kubectl-mcp-server tools support the `context` parameter:
```python
# Get pods from production cluster
get_pods(namespace="default", context="production-cluster")
# Get pods from staging cluster
get_pods(namespace="default", context="staging-cluster")
```
## Common Multi-Cluster Patterns
### Compare Environments
```
# Compare deployment across clusters
compare_namespaces(
namespace1="production",
namespace2="staging",
resource_type="deployment",
context="production-cluster"
)
```
### Parallel Queries
Query multiple clusters simultaneously:
```
# Production cluster
get_pods(namespace="app", context="prod-us-east")
get_pods(namespace="app", context="prod-eu-west")
# Development cluster
get_pods(namespace="app", context="development")
```
### Cross-Cluster Health Check
```
# Check all clusters
for context in ["prod-1", "prod-2", "staging"]:
get_nodes(context=context)
get_pods(namespace="kube-system", context=context)
```
## Cluster API (CAPI) Management
For managing cluster lifecycle:
### List Managed Clusters
```
capi_clusters_list_tool(namespace="capi-system")
```
### Get Cluster Details
```
capi_cluster_get_tool(name="prod-cluster", namespace="capi-system")
```
### Get Workload Cluster Kubeconfig
```
capi_cluster_kubeconfig_tool(name="prod-cluster", namespace="capi-system")
```
### Machine Management
```
capi_machines_list_tool(namespace="capi-system")
capi_machinedeployments_list_tool(namespace="capi-system")
```
### Scale Cluster
```
capi_machinedeployment_scale_tool(
name="prod-cluster-md-0",
namespace="capi-system",
replicas=5
)
```
See [CONTEXT-SWITCHING.md](CONTEXT-SWITCHING.md) for detailed patterns.
## Multi-Cluster Helm
Deploy charts to specific clusters:
```
install_helm_chart(
name="nginx",
chart="bitnami/nginx",
namespace="web",
context="production-cluster"
)
list_helm_releases(
namespace="web",
context="staging-cluster"
)
```
## Multi-Cluster GitOps
### Flux Across Clusters
```
flux_kustomizations_list_tool(
namespace="flux-system",
context="cluster-1"
)
flux_reconcile_tool(
kind="kustomization",
name="apps",
namespace="flux-system",
context="cluster-2"
)
```
### ArgoCD Across Clusters
```
argocd_apps_list_tool(namespace="argocd", context="management-cluster")
```
## Federation Patterns
### Secret Synchronization
```
# Read from source cluster
get_secrets(namespace="app", context="source-cluster")
# Apply to target cluster (via manifest)
apply_manifest(secret_manifest, namespace="app", context="target-cluster")
```
### Cross-Cluster Service Discovery
With Cilium ClusterMesh or Istio multi-cluster:
```
cilium_nodes_list_tool(context="cluster-1")
istio_proxy_status_tool(context="cluster-2")
```
## Best Practices
1. **Naming Convention**: Use descriptive context names
- `prod-us-east-1`, `staging-eu-west-1`
2. **Access Control**: Different kubeconfigs per environment
- Prod: Read-only for most users
- Dev: Full access for developers
3. **Always Specify Context**: Avoid accidental cross-cluster operations
```
# Explicit is better
get_pods(namespace="app", context="production")
```
4. **Cluster Groups**: Organize by purpose
- Production: `prod-*`
- Staging: `staging-*`
- Development: `dev-*`
## Related Skills
- [k8s-troubleshoot](../k8s-troubleshoot/SKILL.md) - Debug across clusters
- [k8s-gitops](../k8s-gitops/SKILL.md) - GitOps multi-cluster