Also, version, componentstatus, cluster-info, current-context, api-versions.

Video from skippbox:
https://www.youtube.com/watch?v=iMfUfrEYfRQ

FWIW, the relationship with glcoud is also a bit confusing when switching contexts.

My "best guess" gcloud config set container/cluster CLUSTER_NAME doesn't change the kubeconfig, i.e., "best guess" is not "good guess".

But gcloud container clusters get-credentials CLUSTER_NAME does, which was unexpected.

Took me a while (and grubbing through the sdk) to realize that it was get-credentials making the change, not the set.

get-credentials is kind of overkill but better than using kubectl directly since the kubeconfig context.name != CLUSTER_NAME.

cc @quinton-hoole

Ref #23492

It's also unfortunate that it takes 3 commands to set up kubectl for a new cluster. For example:

kubectl config set-cluster minikube --insecure-skip-tls-verify=true --server=http://192.168.99.100:8080
kubectl config set-context minikube --cluster=minikube
kubectl config use-context minikube

There's some discussion in #25383, also

#25601 for deleting cluster from kubectl config

I'd like to suggest that we look at : http://kubernetes.io/docs/user-guide/docker-cli-to-kubectl/
and consider what it would take to make the kubectl version of these commands as easy and friendly to use as they are with Docker. That could really help define a pattern for how we revamp things.

Each extra parameter, each extra step needed, each extra bit of extra output (noise) should be scrutinized and questioned.

Yes, I'm holding up Docker as our minimum bar because I think they've done a great job so far. If kubectl can surpass them then that's great, but let's at least give our users an on-par experience.

oh oops, this is about just kubectl config, not just kubectl in general... I'll try to find a better home for the comment. :-)

oh oops, this is about just kubectl config, not just kubectl in general... I'll try to find a better home for the comment. :-)

@duglin tag me in where you end up dropping this? I'd like some more detail on which commands you want to emulate. Some commands like docker ps I could see, but others like docker run (75-ish flags and counting) are less obvious to hold up as a examples.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

/remove-lifecycle stale
/lifecycle frozen

Adding a native way to get the current namespace that's simpler than kubectl config view -o jsonpath="{.contexts[?(.name==\"$(kubectl config current-context)\")].context.namespace}" would be a win too 😄

As another source of ideas, kubectx & kubens have been great tools for our team — managing a small set of contexts rather than hundreds of cluster/namespace combinations. Maybe they could even be folded into kubectl?