a replacement for kubectl vsphere login

[Shachar Ben David]

Hello,

Working in CLi before VCF9.x i have used "kubectl vsphere login" to access and update the kubeconfig file.

In VCF 9.x the command was deprecated and we should use VCF to create the context (i can run it, but it's not supported anymore)

I'm looking for a procedure to replace the "kubectl vsphere login" - I didn't find anything like that in the VCF CLI.

the User story , that he or she run one time the command "vcf context create <context_name> --endpoint <SUPERVISOR_ENDPOINT> --workload-cluster-name <WORKLOAD_CLUSTER_NAME> --workload-cluster-namespace <WORKLOAD_CLUSTER_NAMESPACE> -u <USER> --insecure-skip-tls-verify"

and now they just want to login again and choose the context - not to recretate.

i.e. in the past i was able to choose the client cluster using vsphere login to it, and run kubectl commands. 

Looking for advice. TIA

[Allan Solomon Mejia]

Hello @Shachar

You're correct that kubectl vsphere login was deprecated starting with VCF 9.x. The recommended replacement is to use the VCF CLI to create a kubeconfig context once, and then use the standard Kubernetes context management commands thereafter.

 

A typical workflow is:

 

vcf context create \

  --endpoint <SUPERVISOR_ENDPOINT> \

  --workload-cluster-name <WORKLOAD_CLUSTER_NAME> \

  --workload-cluster-namespace <WORKLOAD_CLUSTER_NAMESPACE>

 

After the context has been created, users don't need to recreate it every time. They can simply switch between existing contexts using:

kubectl config get-contexts

kubectl config use-context <context_name>

 

If the authentication token expires or the kubeconfig becomes invalid (for example, after credential changes), you'll need to run vcf context create again to refresh the context.

 

So the equivalent of the old kubectl vsphere login experience is:

 

• One-time (or occasional): vcf context create
• Day-to-day: kubectl config use-context <context_name>

[Shachar Ben David]

Thanks for the detailed answer.

The caveat is that running the same "vcf context create" command will ended with "context "xyz" already exists".

I can, of course, create a new context name, and delete the old entries, but I wonder if there is a better way to do it?

Shachar

[Shachar Ben David]

I have found the solution.

When the authentication token expires or the kubeconfig becomes invalid , and kubectl should display "couldn't get current server api group list : the server has asked for the client to provide credentials"

The solution is to run vcf context use <context name>

The vcf utility will ask to sign in again, and will automatically refresh all related contexts.

BR,

Shachar

[Allan Solomon Mejia]

Nice find, and thanks for sharing. It'll definitely save others some time.

 

Using vcf context use <context-name> is a much cleaner approach than recreating or deleting contexts. When the authentication token has expired or the kubeconfig is no longer valid, switching back to the existing context prompts for re-authentication and refreshes the associated credentials without having to rebuild the context.

 

This is especially useful for long-lived environments where you want to preserve existing context names and avoid unnecessary cleanup.

[Shachar Ben David]

What I didn't find is how to update the context list with new vcf namespaces  that were created after running "vcf context create"

my solution is to create all contexts again with a new name.. but i don't like it - there must be a more elegant way to do it.

[Inter Soldi]

good to know that vcf context use can refresh the existing context without recreating it. Does this also work reliably after a password change.Chengwei Semiconductor

------------------------------
JEWELLOK
------------------------------

[Shachar Ben David]

Yes, I tested it a few times and it fine.