вы указали правильный хост или порт? ошибка в Kubernetes

Проблема в том, что ваш kubeconfig не тот. Чтобы автоматически сгенерировать его, запустите:

gcloud container clusters get-credentials "CLUSTER NAME"

Это сработало для меня.

Убедитесь, что ваша конфигурация настроена на проект -

gcloud config set project [PROJECT_ID]

1. Запустите контрольный список кластеров в учетной записи:

gcloud container clusters list

2. Проверьте вывод:

NAME           LOCATION       MASTER_VERSION  MASTER_IP      MACHINE_TYPE  NODE_VE.      NUM_NODES  STATUS
alpha-cluster  asia-south1-a  1.9.7-gke.6     35.200.254.78  f1-micro      1.9.7-gke.6   3          RUNNING

3. Запустите следующий cmd, чтобы получить учетные данные для вашего работающего кластера:

gcloud container clusters get-credentials your-cluster-name --zone your-zone       --project your-project

4. Следующий вывод следует:

Fetching cluster endpoint and auth data.
kubeconfig entry generated for alpha-cluster.

5. Попробуйте проверить детали узла, на котором запущен kubectl, например, ниже, чтобы перечислить все модули в текущем пространстве имен с более подробной информацией:

kubectl get nodes -o wide

Должно быть хорошо.

После выполнения команды "kubeinit" кубернетес просит вас запустить подписку как обычный пользователь.

mkdir -p $ HOME / .kube

sudo cp -i /etc/kubernetes/admin.conf $ HOME / .kube / config

sudo chown $ (идентификатор -u): $ (идентификатор -g) $ HOME / .kube / config

Но если вы запустите это как обычный пользователь, вы получите сообщение «В соединении с сервером localhost: 8080 было отказано - вы указали правильный хост или порт?» при попытке доступа от имени пользователя root и наоборот. Итак, попробуйте получить доступ к "kubectl" от имени пользователя, выполнившего указанные выше команды.

Просто не забудьте следовать: https://cloud.google.com/container-engine/docs/before-you-begin до http://kubernetes.io/docs/hellonode/

Воспроизведите ту же ошибку при выполнении учебника от Udacity под названием Scalable Microservices with Kubernetes https://classroom.udacity.com/courses/ud615, в разделе Использование Kubernetes, часть 3 урока.

Запустить единичный экземпляр:

kubectl run nginx --image=nginx:1.10.0

Ошибка:

Unable to connect to the server: dial tcp [::1]:8080: connectex: No connection could be made because the target machine actively refused it.

Как я разрешил ошибку:

Войдите в Google Cloud Platform

Перейдите к Container Engine Google Cloud Platform, Container Engine

Нажмите ПОДКЛЮЧИТЬ в кластере.

Используйте учетные данные для входа в кластер [NAME] в вашем Teminal

Продолжены работы !!!

У меня была такая же ошибка, это сработало для меня. Запустить

minikube status

если ответ

type: Control Plane
host: Stopped
kubelet: Stopped
apiserver: Stopped
kubeconfig: Stopped

запустить minikube start

type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Вы можете перейти

Эта ошибка означает, что kubectl пытается подключиться к apiserver Kubernetes, запущенному на вашем локальном компьютере, что является значением по умолчанию, если вы не настроили его для взаимодействия с удаленным apiserver.

Повторная инициализация gcloud с соответствующей учетной записью и проектом сработала для меня.

gcloud init

После этой повторной попытки следующая команда была успешной, и была сгенерирована запись kubeconfig.

gcloud container clusters get-credentials "cluster_name"

проверьте информацию о кластере с помощью

kubectl cluster-info

У меня была эта проблема с использованием локального докера. Что нужно сделать, это проверить журналы контейнеров, которые он вращает, чтобы выяснить, что пошло не так. Для меня выяснилось, что etcd упал

   $ docker logs <etcdContainerId>
   <snip>
   2016-06-15 09:02:32.868569 C | etcdmain: listen tcp 127.0.0.1:7001: bind: address already in use

Ага! Я играл с Cassandra в контейнере докеров и перенаправил все порты, так как не был уверен, какие из них нужно открыть, а 7001 - один из его портов. Остановка Cassandra, очистка беспорядка и перезапуск исправили ситуацию.

Если вы создали кластер на AWS с помощью kops, то kops создаст для вас ~/.kube/config, что приятно. Но если кому-то еще нужно подключиться к этому кластеру, им также необходимо установить kops, чтобы он мог создать для вас kubeconfig:

export AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id)
export AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key)
export CLUSTER_ALIAS=kubernetes-cluster

kubectl config set-context ${CLUSTER_ALIAS} \
    --cluster=${CLUSTER_FULL_NAME} \
    --user=${CLUSTER_FULL_NAME}

kubectl config use-context ${CLUSTER_ALIAS}

kops export cluster --name ${CLUSTER_FULL_NAME} \
  --region=${CLUSTER_REGION} \
  --state=${KOPS_STATE_STORE}

попробуйте запустить с sudo режимом разрешений
пример sudo kubectl....

Независимо от вашей среды (gcloud или нет) вам необходимо указать свой kubectl на kubeconfig. По умолчанию kubectl ожидает путь как $ HOME / .kube / config или указывает ваш собственный путь как переменную env (для сценариев и т. Д.) Export KUBECONFIG = / your_kubeconfig_path

Обратитесь к :: https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/

Если у вас нет файла kubeconfig для вашего кластера, создайте его, указав :: https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

Требуется найти ca.crt кластера, ключ apiserver-kubelet-client и сертификат.

У меня такая же проблема с момента почти выпуска, похоже, я должен использовать KUBECONFIG явный

sudo cp /etc/kubernetes/admin.conf $ HOME /

sudo chown $ (идентификатор -u): $ (идентификатор -g) $ HOME / admin.conf

экспорт KUBECONFIG = $ HOME / admin.conf

Я получал ошибку при запуске

sudo kubectl get pods
The connection to the server localhost:8080 was refused - did you specify the right host or port?

Наконец, для моей среды этот параметр команды работает

sudo kubectl --kubeconfig /etc/kubernetes/admin.conf get pods

при выполнении kubectl без полномочий root.

Я пытался подключиться к локальному хосту и столкнулся с той же проблемой, но потом обнаружил, что мне нужно запустить прокси для сервера Kubernetes API.

kubectl proxy --port=8080

https://kubernetes.io/docs/tasks/extend-kubernetes/http-proxy-access-api/

У меня была такая же проблема после перезагрузки, я следовал описанному руководству здесь

Итак, попробуйте следующее:

$ sudo -i
# swapoff -a
# exit
$ strace -eopenat kubectl version

После этого работает нормально.

как улучшение Omokahfe:

minikube status

если ответ

E0623 09:12:24.603405   21127 status.go:396] kubeconfig endpoint: extract IP: "minikube" does not appear in /home/<user>/.kube/config
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Misconfigured
timeToStop: Nonexistent


WARNING: Your kubectl is pointing to stale minikube-vm.
To fix the kubectl context, run `**minikube update-context**`

запустить

minikube update-context

тогда это покажет

* "minikube" context has been updated to point to 10.254.183.66:8443
* Current context is "minikube"

а потом

minikube status

покажет

type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
timeToStop: Nonexistent

Это происходит из-за того, что ваш kubectl не может подключиться к серверу kubernetes. Запустите свой кластер.

minikube start

Если вы хотите получить доступ к сервису через файл конфигурации kube, вы можете получить к нему доступ через

 kubectl --kubeconfig ~/.kube/config  get jobs

~ / .kube / config: Путь к файлу конфигурации, измените путь к файлу w.r.t

Я также получал такую ​​же ошибку ниже:

Невозможно подключиться к серверу: наберите tcp [:: 1]: 8080: connectex: Невозможно установить соединение, потому что целевая машина активно отказалась от него.

Затем я просто выполняю команду ниже и обнаружил, что все работает нормально.

PS C:>. \ Minikube.exe запустить

Запуск локального кластера Kubernetes v1.10.0 ... Запуск виртуальной машины ... Загрузка Minikube ISO 150,53 МБ / 150,53 МБ [============================ ==================] 100.00% 0s Получение IP-адреса ВМ ... Перемещение файлов в кластер ... Скачивание kubeadm v1.10.0 Скачивание kubelet v1.10.0 Завершено Скачивание kubelet v1 .10.0 Завершено Загрузка kubeadm v1.10.0 Настройка сертификатов ... Подключение к кластеру ... Настройка kubeconfig ... Запуск компонентов кластера ... Kubectl теперь настроен на использование кластера. Загрузка кешированных изображений из файла конфигурации. PS C:>. \ Minikube.exe start Запуск локального кластера Kubernetes v1.10.0 ... Запуск виртуальной машины ... Получение IP-адреса виртуальной машины ... Перемещение файлов в кластер ... Настройка сертификатов ... Подключение к кластеру .. Настройка kubeconfig ... Запуск компонентов кластера ... Kubectl теперь настроен на использование кластера.

У меня возникла эта проблема при использовании Bash в Windows с лазурными кубернетами

az aks get-credentials -n <myCluster>-g <myResourceGroup>

Файл конфигурации создается автоматически и помещается в файл '~ / .kube / config' в соответствии с ОС (в моем случае это Windows).

Чтобы решить эту проблему - Запустите из командной строки Bash cp <yourWindowsPathToConfigPrintedFromAbobeCommand> ~/.kube/config

Правильный ответ из всего вышеперечисленного - выполнить следующие команды:

sudo cp /etc/kubernetes/admin.conf $HOME/

sudo chown $(id -u):$(id -g) $HOME/admin.conf

export KUBECONFIG=$HOME/admin.conf

Если кто-то, как и я, наткнулся на эту тему из-за основной ошибки на этапе сборки облака при переключении с gcr.io/cloud-builders/kubectl на gcr.io/google.com/cloudsdktool/cloud-sdk, вам нужно будет явно вызвать get-credentials, чтобы kubectl заработал. Мой конвейер:

steps:
  - name: gcr.io/google.com/cloudsdktool/cloud-sdk
    entrypoint: 'sh'
    args:
      - '-c'
      - |
        gcloud container clusters get-credentials --zone "$$CLOUDSDK_COMPUTE_ZONE" "$$CLOUDSDK_CONTAINER_CLUSTER"
        kubectl call-what-you-need-here
options:
  env:
    - 'CLOUDSDK_COMPUTE_ZONE=europe-west3-a'
    - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'

Решение такое:

minikube delete
minikube start --vm-driver none