Change:
echo "Running GKE internal configuration script" . "${KUBE_HOME}/bin/gke-internal-configure-helper.sh" gke-internal-master-start <ins> elif [[ -n "${KUBE_BEARER_TOKEN:-}" ]]; then echo "setting up local admin kubeconfig" create-kubeconfig "local-admin" "${KUBE_BEARER_TOKEN}" echo "export KUBECONFIG=/etc/srv/kubernetes/local-admin/kubeconfig" > /etc/profile.d/kubeconfig.sh </ins> fi }

Discussion:
What happened: Used kube- to bring up a GCE cluster and then logged on to the master. Run kubectl on the master, is hangs for a while (30 seconds) and then returns an error. $ kubectl get nodes Error from server (InternalError): an error on the server ("") has prevented the request from succeeding What you expected to happen: I expected to get the node list. If I use one of the system account's kubeconfig files it works. $ sudo kubectl --kubeconfig=/mnt/disks/master-pd/srv/kubernetes/kube-bootstrap/kubeconfig get nodes NAME STATUS ROLES AGE VERSION kubernetes-master Ready,SchedulingDisabled <none26m v1.18.0-alpha.2.55+-dirty kubernetes-minion-group-jfk6 Ready <none26m v1.18.0-alpha.2.55+-dirty kubernetes-minion-group-mqnp Ready <none26m v1.18.0-alpha.2.55+-dirty kubernetes-minion-group-x540 Ready <none26m v1.18.0-alpha.2.55+-dirty How to reproduce it (as minimally and precisely as possible): Bring up a GCE cluster from head, ssh to master and run "kubectl get nodes" Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.0-alpha.2.55+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2020-01-23T00:38:39Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.0-alpha.2.55+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2020-01-23T00:36:29Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: GCE OS (e.g: ): COS m_77 Kernel (e.g.

): 4.19.76 Install tools: cluster/kube- Network plugin and version (if this is a network-related bug): Others: I believe this used to work based on talking to KAS on the insecure port using no authentication. The insecure port is now turned off and we require authentication materials. We should probably setup an admin account specifically for the master.
/sig cli
/assign
I also would not have expected a hang, but an immediate error, and I would have expected an authentication error, not an internal error
I believe the internal error is due to it defaulting to port 8080. Nothing is listening on that port. This used to work but I would guess it stopped working when we stopped listening on the insecure port.
changed behavior of client-go on connection refused errors, which changed a short wait and an "invalid host/port" error into a long retry wait and a confusing "internal server" error /assign
if kubectl is intended to work automatically against the local API server, then a kubeconfig file should be set up, but the 30 second delay and incorrect error are a bug that should be fixed in client-go /sig api-machinery
/remove-sig api-machinery /unassign actually, moved the client-go issue to will keep this one for the GCE $KUBECONFIG resolution
I agree that seems like the right fix.
I'm not sure this belong to sig-cli... looks like made this change /sig cluster-lifecycle /cc
Re: set up a kubeconfig That's what we do for GKE: create an authenticated kubeconfig and set the env var. E.g. if you have an authenticated kubeconfig at :
Yes, GKE sets up an admin system account for the master(s) as part of the internal-configure-helper. I believe we should do the same thing for GCE.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale