Kubernetes Skills

Manage multiple Kubernetes clusters, switch contexts, and perform cross-cluster operations. Use when working with multiple clusters, comparing environments, or managing cluster lifecycle.

Security Scan

The instructions align with multi-cluster Kubernetes tasks, but the skill references reading kubeconfigs and syncing secrets while declaring no credential or config requirements and has no verifiable source — that mismatch is a significant concern.

Purpose & Capability

The skill's name, description, and runtime instructions consistently target multi-cluster Kubernetes management (context switching, CAPI, Helm, GitOps, secret sync). That capability set is coherent with the stated purpose.

Instruction Scope

SKILL.md instructs the agent to view/sanitize kubeconfigs (kubeconfig_view()), list contexts, read secrets from a source cluster and apply them to targets, and to obtain workload kubeconfigs via CAPI tools. Those instructions implicitly require access to kubeconfig files and cluster credentials and perform sensitive actions (secret synchronization, cross-cluster writes). The skill does not constrain or document how sensitive data will be handled or where it may be transmitted.

Install Mechanism

Instruction-only skill with no install spec and no code files — nothing will be downloaded or written by the skill itself. This minimizes supply-chain/installation risk.

Credentials

The skill declares no required env vars, credentials, or config paths, yet the instructions rely on kubeconfigs (examples use export KUBECONFIG and kubeconfig_view()) and service-account patterns. There is a mismatch between declared requirements (none) and the obvious need for cluster credentials and kubeconfig files to perform the described operations.

Persistence & Privilege

The skill is not always-enabled and is user-invocable. It does not request persistent presence or modify other skills. Autonomous invocation is enabled (default) but not, by itself, a red flag here.

What to consider before installing

This skill appears to be a legitimate multi-cluster Kubernetes helper, but take these precautions before installing or using it: - Verify provenance: the skill's source and homepage are unknown; prefer skills from trusted publishers. - Expect it needs access to kubeconfig files or cluster credentials even though it doesn't declare them. Do not expose production kubeconfigs or long-lived admin tokens to untrusted skills or agents. - Secret-sync examples show the agent reading secrets in one cluster and applying them to another — this is sensitive. Confirm how kubeconfig_view() sanitizes secrets and audit any secret exports before allowing the skill to run. - Limit permissions: use short-lived, least-privilege service accounts and separate kubeconfig files for non-prod testing before running in production. - Ask the publisher or maintainer for clarification: which platform tools back get_pods(), apply_manifest(), and kubeconfig_view(), and how is sensitive data handled/transmitted? If you cannot verify those answers, avoid granting access to real kubeconfigs or prod clusters. If you want, I can list specific questions to ask the skill author or suggest a safe test plan (isolated dev cluster and restricted kubeconfig) to evaluate the skill's behavior.

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:

# 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 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 - Debug across clusters
• k8s-gitops - GitOps multi-cluster