2014-09-09 8 views
4

Я запускаю (из Windows 8.1) Vagrant VM для CoreOS (yungsang/coreos).kubernetes не удается подключиться к новой установке CoreOS

Я установил kubernetes в соответствии с руководством, которое я нашел here и создал json для pod, используя мои изображения.

Когда я исполняю sudo ./kubecfg list /pods я получаю следующее сообщение об ошибке:

F0909 06:03:04.626251 01933 kubecfg.go:182] Got request error: Get http://localhost:8080/api/v1beta1/pods?labels=: dial tcp 127.0.0.1:8080: connection refused 

То же самое касается sudo ./kubecfg -h http://127.0.0.1:8080 -c /vagrant/app.json create /pods

EDIT: Update

Вместо запуска команды сам я интегрированы в бродячей файл (как such).

Это делает кубернеты хорошо работающими. ОДНАКО после некоторого времени мое бродяжное соединение ssh закрывается. Я снова подключаюсь, и любые команды kubernetes я указываю результат с той же ошибкой, что и выше.

EDIT 2: Update

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

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

sudo systemctl start etcd 
sudo systemctl start download-kubernetes 
sudo systemctl start apiserver 
sudo systemctl start controller-manager 
sudo systemctl start kubelet 
sudo systemctl start proxy 

Я считаю, что это на самом деле apiserver, который нуждается в перезапуске

Что является источником этого «тайм-аут»? (Где любые журналы, которые я могу найти по этому вопросу)

+0

Не знаю, если бы вы когда-либо нашли решение этого бита, я наткнулся на него сегодня. Эта ошибка в основном означает, что что-то не так с сервисом apirusver. Я могу предоставить более подробную информацию, если вы заинтересованы. – jmreicha

+0

Да, пожалуйста. Это было оставлено на полке из-за отсутствия прогресса. – mangusbrother

ответ

3

Развитие Kubernetes движется безумно быстро, так что это может быть устаревшим к завтрашнему дню. Имея это в виду, кубернеты рекомендуют следовать одному из своих official installation guides. Лучшим советом было бы начать заново с одного из новых руководств по установке, но есть несколько советов, которые я узнал сам.

Первое, что нужно отметить, это то, что Kubecfg устарел в пользу kubectl. Поэтому для дальнейшего использования, если вы хотите получить информацию о контейнере, вы будете запускать что-то вроде:

./kubectl get pods.

С kubectl вам также потребуется установить переменную ENV так kubectl знают, как разговаривать с apiserver:

KUBERNETES_MASTER=http://IPADDRESS:8080.

Самый простой способ отладки точно, что происходит, если вы используете CoreOS является хвост журналы для сервиса вы заинтересованы Так что если у вас есть kube-apiserver блок вы можете посмотреть на то, что творится, запустив:.

journalctl -f -u kube-apiserver

от узла, на котором работает apersver. Если эта служба не работает, что может быть случай, вы можете запустить его с:

systemctl start kube-apiserver

+0

Спасибо за это. Я столкнулся с аналогичной проблемой, описанной в разделе «Анализ данных в реальном времени с помощью Кубнертеса, Редиса и BigQuery в Google Cloud Platform» на веб-сайте Google Cloud Platform: https: //cloud.google.com/solutions/real-time/ kubernetes-redis-bigquery Это относится к kubecfg.sh, который был устарел в пользу kubectl.sh, как вы говорите. –

+0

@rdc Да, разработка по-прежнему очень быстро развивается, поэтому документы быстро устаревают. Рад, что вы разобрались! – jmreicha

0

На CoreOS вы должны посмотреть журналы, используя journalctl.

Например, если вы хотите увидеть etcd журналов, которые Kubernetes полагается на для хранения состояния это приспешники, запустить journalctl _COMM=etcd, а так же journalctl _COMM=apiserver покажет вам бревно из apiserver, один из ключевых компонентов в Kubernetes.

Вы также получите последние несколько записей в журнале, если вы запустите systemctl status apiserver.

0

на основе рекомендаций errordevelopers, моя недавняя установка побежала против подобной проблемы.

Использование systemctl status apiserver и sudo systemctl start apiserver Мне удалось снова запустить среду.