error: couldn't read version from server

后端 未结 6 2155
旧巷少年郎
旧巷少年郎 2021-02-13 13:12

I am getting the following error when trying to run kubectl locally.

error: couldn\'t read version from server: Get http://localhost:8080/api: dial tc

相关标签:
6条回答
  • 2021-02-13 13:34

    The above solution no longer works. You need to do the following instead:

    gcloud container clusters get-credentials <cluster-name> \
        [--zone=<zone-of-cluster> --project=<project-id>]
    
    0 讨论(0)
  • 2021-02-13 13:35

    This used to be beta, but that is no longer the case. So the command now is:

    gcloud container clusters get-credentials <cluster-name> --zone=<zone-of-cluster> --project=<project-id>    
    

    If you try to run it with the beta command you get the following error message:

    WARNING: You invoked gcloud beta, but with current configuration Kubernetes Engine v1 API will be used instead of v1beta1 API. gcloud beta will switch to use Kubernetes Engine v1beta1 API by default by the end of March 2018.

    Later on if you wish to switch between clusters via kubectl (only for ones that you have already authenticated for), you can use:

    kubectl config use-context gke_<project-name>_<zone>_<cluster>
    

    Example:

    kubectl config use-context gke_my-project_europe-west1-c_my-cluster
    

    To see where you currently are:

    kubectl config current-context
    

    Cheers

    0 讨论(0)
  • 2021-02-13 13:35

    I was using Google Container Engine (GKE) and got this error, too. In my case, it was because I forgot to create a container cluster first.

    If you create a cluster using the gcloud command, it sets the config for the you.

    gcloud container clusters create my-cluster-name
    
    0 讨论(0)
  • 2021-02-13 13:41

    This is in flux, just reference the documentation. It is currently ...

    gcloud container clusters get-credentials NAME [--zone ZONE, -z ZONE] [GLOBAL-FLAG …]
    
    0 讨论(0)
  • 2021-02-13 13:45

    I also got this error when deploying locally with a mostly default configuration on Ubuntu Trusty. Turns out the api-server was not starting due to some bug with DenyEscalatingExec particular to ubuntu in k8s v1.1.7

    https://github.com/kubernetes/kubernetes/issues/14474 https://github.com/kubernetes/kubernetes/issues/14627

    I rebuilt the cluster without it by removing the directive from the file ~/kubernetes-1.1.7/cluster/ubuntu/config-default.sh before executing kube-up.sh

    # Admission Controllers to invoke prior to persisting objects in cluster
    export ADMISSION_CONTROL=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,DenyEscalatingExec,SecurityContextDeny
    

    DenyEscalatingExec needs to be removed from that line, and as a result, it won't be a flag in your /etc/default/kube-apiserver after starting the cluster.

    Disclaimer: I'm not sure what DenyEscalatingExec does, I just found that this worked for me to solve this particular problem.

    0 讨论(0)
  • 2021-02-13 13:47

    tl;dr gcloud container get-credentials --cluster=CLUSTER_ID --zone=YOURZONE


    So a little background: the kubectl tool is developed by google but isn't actually integrated into google cloud directly, the google cloud just helps you get a compatible version with it when you tell it to install the component.

    If you're getting the Get http://localhost:8080/api: dial tcp 127.0.0.1:8080: connection refused it is likely due to the kubectl tool not being configured at all or misconfigured. What I believe it's trying to do is assuming you have kubernetes somehow setup locally only, which you don't in this case since it's all on the google cloud (hence the cryptic error).

    You can verify your kubectl is misconfigured by running kubectl config view. If it's correctly configured you should see things like a few entries in cluster, with ip addresses, and in users you should see a user for each project, etc. If you see nothing of the sort (ie. empty clusters, and empty users) then you are misconfigured; you will also encounter cryptic issues if you dont see entries for the specific cluster you are trying to work on.

    Annoyingly a lot of gcloud commands will silently auto-configure it for you, so if you follow something like a hello wordpress tutorial it will look like you dont have to do this and that somehow kubectl communicates with gcloud, but nothing of the sort happens. It's also very easy to lose that configuration.

    To tell gcloud to give you the kubectl config run the following:

    gcloud container get-credentials --cluster=CLUSTER_ID --zone=YOURZONE
    

    For cluster id run gcloud container clusters list

    Zone is "europe-west1-d" or whatever you've chosen.

    0 讨论(0)
提交回复
热议问题