Kubernetes на проблемах главного узла AWS

После запуска Kubernetes на AWS в течение нескольких дней мой главный узел сходит. Это произошло после настройки 2 разных кластеров. Пакеты все еще запущены и доступны, но нет способа управлять/прокси.Kubernetes на проблемах главного узла AWS

Вопрос: почему? Или, альтернативно, как заменить главный узел на AWS? Или, альтернативно, как мне отладить существующий? Или, альтернативно, как я могу использовать нечто, отличное от t2.micro, которое может быть слишком маленьким для запуска мастера?

Симптом: $ kubectl получить стручки ошибка: не удалось прочитать версию с сервера: Получить https: //**.###.###.###/api:. Наберите ** # TCP ## ### ###:.. 443: подключение отказалось

Edit: Это то, что я нашел после дальнейшей отладки:

goroutine 571 [running]: 
net/http.func·018() 
    /usr/src/go/src/net/http/transport.go:517 +0x2a 
net/http.(*Transport).CancelRequest(0xc2083c0630, 0xc209750d00) 
    /usr/src/go/src/net/http/transport.go:284 +0x97 
github.com/coreos/go-etcd/etcd.func·003() 
    /go/src/github.com/GoogleCloudPlatform/kubernetes/Godeps/_workspace/src/github.com/coreos/go-etcd/etcd/requests.go:159 +0x236 
created by github.com/coreos/go-etcd/etcd.(*Client).SendRequest 
    /go/src/github.com/GoogleCloudPlatform/kubernetes/Godeps/_workspace/src/github.com/coreos/go-etcd/etcd/requests.go:168 +0x3e3 

goroutine 1 [IO wait, 12 minutes]: 
net.(*pollDesc).Wait(0xc20870e760, 0x72, 0x0, 0x0) 
    /usr/src/go/src/net/fd_poll_runtime.go:84 +0x47 
net.(*pollDesc).WaitRead(0xc20870e760, 0x0, 0x0) 
    /usr/src/go/src/net/fd_poll_runtime.go:89 +0x43 
net.(*netFD).accept(0xc20870e700, 0x0, 0x7f4424a42008, 0xc20930a168) 
    /usr/src/go/src/net/fd_unix.go:419 +0x40b 
net.(*TCPListener).AcceptTCP(0xc20804bec0, 0x5bccce, 0x0, 0x0) 
    /usr/src/go/src/net/tcpsock_posix.go:234 +0x4e 
net/http.tcpKeepAliveListener.Accept(0xc20804bec0, 0x0, 0x0, 0x0, 0x0) 
    /usr/src/go/src/net/http/server.go:1976 +0x4c 
net/http.(*Server).Serve(0xc20887ec60, 0x7f4424a66dc8, 0xc20804bec0, 0x0, 0x0) 
    /usr/src/go/src/net/http/server.go:1728 +0x92 
net/http.(*Server).ListenAndServe(0xc20887ec60, 0x0, 0x0) 
    /usr/src/go/src/net/http/server.go:1718 +0x154 
github.com/GoogleCloudPlatform/kubernetes/cmd/kube-apiserver/app.(*APIServer).Run(0xc2081f0e00, 0xc20806e0e0, 0x0, 0xe, 0x0, 0x0) 
    /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/cmd/kube-apiserver/app/server.go:484 +0x264a 
main.main() 
     /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/cmd/kube-apiserver/apiserver.go:48 +0x154

источник

2015-08-24 JuanIsFree

Что вы пробовали до сих пор с точки зрения отладки? Как и в случае с любым сервисом, первые вещи, которые нужно проверить, это (а) - это запуск службы? И (b) он регистрировал ошибки в системном журнале или в журнале приложений? – larsks

Я должен отметить, что мастер работает, но я не могу войти. Я бы предположил, что есть что-то вроде утечки дескриптора файла, но кто знает? – JuanIsFree

Установка большего мастера (из браузера github) export MASTER_SIZE = XXX – JuanIsFree

Это почти наверняка, что первоначальный размер машины был слишком низким , и закончилась память (или что-то подобное). Чтобы использовать более крупный размер кластера, следуйте этой ссылке [1] и установите переменную среды, прежде чем вы откроете свой кластер.

В этом случае, что-то вроде:

export MINION_SIZE=t2.large

должен работать навсегда [2].

[1] http://kubernetes.io/docs/getting-started-guides/aws/

[2] или его разумное приближение. :)

источник

2015-09-11 20:08:49 aronchick

Kubernetes на проблемах главного узла AWS

ответ

Смежные вопросы