When managing multiple Kubernetes clusters (e.g., local development and cloud-based environments), deployment scripts must explicitly target the correct cluster to avoid accidental cross-cluster operations. This solution addresses a scenario where scripts defaulted to a cloud cluster instead of the intended local cluster, breaking the workflow.

Issue

Deployment scripts failed because Kubernetes commands defaulted to an incorrect cluster context (e.g., a cloud-based cluster like Azure AKS) instead of the intended local cluster. This occurred due to:

Ambiguous naming conventions for cluster contexts (e.g., default for both local and cloud environments).
Lack of explicit cluster targeting in scripts, relying instead on the active context.
No enforcement mechanism to guarantee the correct cluster was selected.

Culprit

The root cause was an unstandardized context-naming approach:

The local Kubernetes cluster used a generic default context name.
Cloud clusters had descriptive names (e.g., mcp-rag-aks), but scripts lacked safeguards.
No environment variables or script-level checks enforced cluster selection.

Solution

To prevent accidental cross-cluster operations, the following measures were implemented:

Context Standardization and Renaming

Renamed ambiguous context names (e.g., default → descriptive names) for clarity.
Enforced a consistent naming convention to avoid confusion.

Environment-Driven Cluster Selection

Introduced an environment variable (CLUSTER_CONTEXT) to specify the target cluster.

Modified all scripts to explicitly use the context:

kubectl --context ${CLUSTER_CONTEXT} [command] [flags] [file]

Updated core scripts (e.g., pipeline.sh, deploy-versioned.sh) to load the environment variable and enforce context usage.

Best Practices for Scripting

Prompt Integration: Added context visibility to shell prompts (e.g., PS1) to alert users of the active cluster.
Pre-Execution Verification: Scripts now validate the current context before proceeding.
Override Flexibility: Allowed explicit context overrides via environment variables for testing or edge cases.

Key Outcomes

Zero Accidental Operations: Scripts now reliably target the correct cluster.
Self-Documenting Workflow: Context names and environment variables make intent clear.
Flexibility: Supports dynamic cluster selection without modifying scripts.

This solution ensures robust, maintainable, and error-resistant Kubernetes deployments across multi-cluster environments.