Warn Users of Region Before Executing kubectl Commands

[Divakar-Raju]

What would you like to be added:
Currently, kubectl does not provide any warning regarding which Kubernetes cluster or cloud region the command is being executed on. This can lead to accidental modifications in the wrong environment (e.g., production instead of staging or wrong region ).

Add an interactive warning before executing any kubectl apply, delete, patch, replace, taint, exec, create, run commands, displaying the current region and asking for user confirmation before proceeding.

Example :

$ kubectl apply -f deployment.yaml
WARNING: You are making changes in region us-east-1 (Cluster: prod-cluster).
Do you want to continue? (yes/no): 

This ensures users are aware of the region and cluster before proceeding.

Why is this needed:
Prevents accidental changes in production clusters.
Helps users working across multiple environments in difference regions
Enhances safety in cloud-based Kubernetes deployments.

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ardaguclu]

There is no region concepts in kubectl (or even in kubernetes). There is context or cluster concept. Adding a warning message would be breaking change. I think, plugin can be implemented for this. But I don't think, we'd want or can add this feature in kubectl.
I'll close this, if you don't mind.
/close

[k8s-ci-robot]

@ardaguclu: Closing this issue.

In response to this:

There is no region concepts in kubectl (or even in kubernetes). There is context or cluster concept. Adding a warning message would be breaking change. I think, plugin can be implemented for this. But I don't think, we'd want or can add this feature in kubectl.
I'll close this, if you don't mind.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.