[kubernetes/kubectl] Improve default kubectl behavior when it doesn't know what cluster to talk to (#1340)
Brian Grant
At minimum, we need to improve the error message:
The connection to the server localhost:8080 was refused - did you specify the right host or port?
We might also want to consider not using localhost as the default, though we want to keep it aligned with our single-node dev cluster plans. kubernetes/kubernetes#24106
cc @kubernetes/kubectl @dlorenc @vishh
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Kubernetes Prow Robot
@bgrant0607: 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/test-infra repository.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Tim Bannister
Could we deprecate not having a kubeconfig but still retain the (deprecated) existing behavior?
If we do that, we could output this for a failed connection:
Warning: no Kubernetes client configuration found. The kubectl tool was not able to find a configuration for connecting to your Kubernetes cluster. Previous versions of Kubernetes supported trying to connect without a Kubernetes configuration. The tool can still use defaults to connect, but this is deprecated since Kubernetes 1.42 due to concerns about security. Additionally, when kubectl tried to use default values to connect, the connection to localhost on port 8080 timed out after 10 seconds. To learn how to configure kubectl, visit https://k8s.io/whatever
or, if the connection worked OK, something like:
Warning: no Kubernetes client configuration found. Using defaults. Warning: insecure connection to Kubernetes control plane (no TLS). NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
(bold: stderr; normal weight: stdout)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Brian Grant
I don't remember which parts of this issue were in the client library vs kubectl, but it sounds reasonable to me.
BTW, we need a bot to notify the current people involved in the relevant SIG or something. Almost certainly these old issues don't have the right/best people subscribed to them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Tim Bannister
I don't know about a bot, but I already mentioned it in Slack.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Eddie Zaneski
It's probably a good time to pull the trigger on adding a better warning here.
/triage accepted
/assign @ShivamTyagi12345
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
shivam tyagi
Could we deprecate not having a kubeconfig but still retain the (deprecated) existing behavior?
If we do that, we could output this for a failed connection:
Warning: no Kubernetes client configuration found.
The kubectl tool was not able to find a configuration for connecting to your Kubernetes cluster.
Previous versions of Kubernetes supported trying to connect without a Kubernetes configuration.
The tool can still use defaults to connect, but this is deprecated since Kubernetes 1.42 due to
concerns about security.Additionally, when kubectl tried to use default values to connect, the connection to localhost
on port 8080 timed out after 10 seconds.To learn how to configure kubectl, visit https://k8s.io/whatever
or, if the connection worked OK, something like:
Warning: no Kubernetes client configuration found. Using defaults.
Warning: insecure connection to Kubernetes control plane (no TLS).
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453(bold: stderr; normal weight: stdout)
I will go ahead and add this error as i feel that it has the consensus, @sftim can you please let me know which file location would be required to change inorder to display this warning
Thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Tim Bannister
Sorry - I'm not actually someone who codes in Go very often.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Kubernetes Triage Robot
This issue is labeled with priority/important-soon but has not been updated in over 90 days, and should be re-triaged.
Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.
You can:
- Confirm that this issue is still relevant with
/triage accepted(org members only) - Deprioritize it with
/priority important-longtermor/priority backlog - Close this issue with
/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.