да вроде жив

docker ps -a выдаёт список активных контейнеров

облин, а до тлс я не дочитал

извиняюсь

показывай параметры запуска кьюблета

только с другого хоста уже ;)

ps -p `pgrep kubelet` -o args

ключевая аномалия у тебя какая-то там

а все потому, что кто-то ленится читать мануалы до конца ;)

еще и вместо официальных читает короосные

если внимательно почитать официальную документацию в части аутентификации: http://kubernetes.io/docs/admin/authentication/

ключевая аномалия у тебя какая-то там

Самая жесть, что она на ровном месте образовалась, после kubectl apply -f одного из подов приложения.

то станет понятно, что городить весь этот хитрый SSL-огород вовсе необязательно

и можно ограничиться публичной частью CA и токеном

даже так

ps -p `pgrep kubelet` -o args

Крутая команда, но в CoreOS пишет error: process ID list syntax error :)

там ps из бизибокса чтоли?

Не исключено :)

ну короче, покажи, как запускается кьюблет

Конкретно на этой машине: ExecStart=/opt/bin/kubelet \ --address=0.0.0.0 \ --port=10250 \ --hostname-override=${COREOS_PRIVATE_IPV4} \ --api-servers=${MASTER_PRIVATE_IPV4}:8080 \ --allow-privileged=true \ --logtostderr=true \ --cadvisor-port=4194 \ --healthz-bind-address=0.0.0.0 \ --tls-cert-file=/etc/kubernetes/ssl/www1-worker.pem \ --tls-private-key-file=/etc/kubernetes/ssl/www1-worker-key.pem \ --cluster-dns=10.100.0.100 \ --cluster-domain="kube.local" \ --healthz-port=10248

эээ

а почему 8080?

ты к апишечке по plain-http идешь?

Это фрагмент из cloud-init, я вот сейчас смотрю и тут явно ключи указаны старые, для прошлого ca.pem

Там же kube-proxy поднят

Я чё-то не помню зачем)

на 8080

чочо?

какой кубепрокси на 8080

а не, не так прочитал

там kube-apiserver

kube-proxy - это та штука, которая тебе на хостах iptables настраивает

ExecStart=/opt/bin/kube-apiserver \ --allow-privileged=true \ --etcd-servers=http://127.0.0.1:2379 \ --secure-port=6443 \ --bind-address=0.0.0.0 \ --insecure-port=8080 \ --insecure-bind-address=0.0.0.0 \ --service-cluster-ip-range=10.100.0.0/24 \ --runtime-config=extensions/v1beta1=true,extensions/v1beta1/thirdpartyresources=true \ --admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota \ --tls-cert-file=/etc/kubernetes/ssl/apiserver.pem \ --tls-private-key-file=/etc/kubernetes/ssl/apiserver-key.pem \ --client-ca-file=/etc/kubernetes/ssl/ca.pem \ --service-account-key-file=/etc/kubernetes/ssl/apiserver-key.pem \ --kubelet-certificate-authority=/etc/kubernetes/ssl/ca.pem \ --kubelet-client-certificate=/etc/kubernetes/ssl/apiserver.pem \ --kubelet-client-key=/etc/kubernetes/ssl/apiserver-key.pem \ --service-node-port-range='70-32767' \ --logtostderr=true

она должна быть на всех нодах

да, она на всех хостах, просто туда же смотрит на master:8080

--insecure-port=8080 \ --insecure-bind-address=0.0.0.0 \

да

ты можешь сертификаты выкидывать

они тебе не нужны

приехали

ну я серьезно

ты всему миру разрешил входить в апи не представляясь

не всё так просто :) там iptables только 80 и 443 разрешает с мира

я не об этом

но надо выпилить insecure да?

те, кто может дойти до http://<apiserver>:8080, получают рут-акцесс до кубернетеса забесплатно

ну то есть внутри кластера тебе сертификаты не нужны

ты сам сделал их использование ненужным

ок, тут дилемма - стоит ли разрешать доступ без сертификатов с других серверов кластера?

вроде как нет

это может быть неустойчиво к man-in-the-middle атакам

не стоит конечно

более того, если ты решил развивать тему с аутентификацией посредством сертификатов, то выпускай уникальную пару для каждого сервера

с рестриктом по айпи

потому что отозвать, в случае чего, ты их не сможешь

сейчас уже сертификаты уникальные для каждой машины

а как restrict по IP задать?

покажи openssl x509 -in /где/там/сертификат/любого/хоста.pem -text -noout|grep DNS

а, ты про это

?

шаблон такой: [req] req_extensions = v3_req distinguished_name = req_distinguished_name [req_distinguished_name] [ v3_req ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names [alt_names] IP.1 = \$ENV::MINION_IP EOL

а, во

то есть с другой машины этим сертификатом уже не воспользоваться

фак-оф им всем :)

ну хоть так

надо изменить параметры запуска apiserver тогда

ты там с кьюблетом-то разобрался на .18?

как я понял

ну да

у меня там ... --bind-address=0.0.0.0 --secure-port=8443 --insecure-bind-address=127.0.0.1 --insecure-port=8080 ...

сейчас в мануале COS: - apiserver - --bind-address=0.0.0.0 - --etcd-servers=${ETCD_ENDPOINTS} - --allow-privileged=true - --service-cluster-ip-range=${SERVICE_IP_RANGE} - --secure-port=443 - --advertise-address=${ADVERTISE_IP} - --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota - --tls-cert-file=/etc/kubernetes/ssl/apiserver.pem - --tls-private-key-file=/etc/kubernetes/ssl/apiserver-key.pem - --client-ca-file=/etc/kubernetes/ssl/ca.pem - --service-account-key-file=/etc/kubernetes/ssl/apiserver-key.pem - --runtime-config=extensions/v1beta1=true,extensions/v1beta1/networkpolicies=true

у тебя тоже insecure?

у меня insecure только для локалхоста

а учитывая, что оно в контейнере, считай для никого

а какого фига они тут тут apiserver в поде запускают? https://coreos.com/kubernetes/docs/latest/deploy-master.html

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

а какого фига они тут тут apiserver в поде запускают? https://coreos.com/kubernetes/docs/latest/deploy-master.html

и правильно делают

у меня так же

# ls /etc/kubernetes/manifests/ addon-manager.yaml apiserver.yaml controller-manager.yaml etcd.yaml proxy.yaml scheduler.yaml

весь кубернетес стартует в контейнерах