там проблемы похожи для @coreos_ru

отправил все три ноды в ребут

конфиги вроде валидные

Ну апи + етцд + kubectl работают?

$ kubectl get no Должно мастер-ноду возвращать

сейчас новый контекст создам для kubectl

пока не перегенеришь весь CA

Чойто? Там разве нет проверки на отозванные серты?

А как?

Ну вот чисто физически как ты это себе представляешь?

У аписервера есть только публичная часть CA

С ее помощью оно проверяет, что сертификат входящего действительно подписан этим CA

От того, что я его отозвал, он не перестает быть подписаным

Ну т.е. типа black-list

С ее помощью оно проверяет, что сертификат входящего действительно подписан этим CA

Дык а как ты думаешь браузеры работают?

Как там отзываются сертификаты

Ну расскажи мне

Он ходит в СА и проверяет, отозван ли

OCSP все дела

Наверное я тут чего-то не знаю

А теперь в мане к аписерверу покажи мне это

;)

Хотя вот. https://github.com/coreos/etcd/issues/4034

:)

todo world

Сертификаты-то самоподписанные

Весь "удостоверяющий центр" находится на моем лаптопе

Только тут я могу сертификаты выпускать, подписывать и отзывать

А кубернетес может только проверить, действительно ли я этот сертификат подписывал и не истек ли он

Весь "удостоверяющий центр" находится на моем лаптопе

Это уже детали.

Можно же хоть let's encrypt прикрутить

пока упоролся с CoreOS юнитом)

надо было ему полный путь до mkdir

Можно же хоть let's encrypt прикрутить

А юзерам сертификаты как выпускать через него?

Которые не имеют ни айпи, ни доменов

Наверняка что-то можно придумать

Было бы желание. Доменов третьего уровня нагенерить можно много.

Вопрос - надо ли?)

Это другой вопрос) мы о технической части.

Но я согласен, что с токенами удобнее будет.

$ /opt/bin/kubelet /opt/bin/kubelet: line 1: syntax error near unexpected token `<' /opt/bin/kubelet: line 1: `<?xml version='1.0' encoding='UTF-8'?><Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message></Error>'

приехали))

Какая-то хуйня там вместо симлинка ;)

)) именно

А чмод +х сделал на скаченный кьюблет?

а ну всё понятно

я в версии забыл v указать

он отсюда пытался забрать https://storage.googleapis.com/kubernetes-release/release/1.3.6/bin/linux/amd64/kubelet

Ггг

Бывает

в sudo journalctl -u kube-kubelet -f ругается: Aug 27 17:16:17 loadbal1 kubelet[4453]: I0827 17:16:17.247263 4453 operation_executor.go:843] UnmountVolume.TearDown succeeded for volume "kubernetes.io/secret/644a6f32-5fd2-11e6-a399-44a842348b74-default-token-yxrvo" (OuterVolumeSpecName: "default-token-yxrvo") pod "644a6f32-5fd2-11e6-a399-44a842348b74" (UID: "644a6f32-5fd2-11e6-a399-44a842348b74"). InnerVolumeSpecName "default-token-yxrvo". PluginName "kubernetes.io/secret", VolumeGidValue ""

Это нормально

Контроллер-манагера еще нет

Он придет и повыпускает эти секреты

а

я уже запаниковал

на миньонах должен быть только манифест для прокси, правильно?

Да

Сижу в Старбаксе. Обновляю конфиг в CoreOS. Рядом парень с девушкой - свидание. Она ему что-то увлеченно рассказывает. А он у меня в мониторе залипает.

Нас не изменить )

# kubectl get no # kubectl get namespaces NAME STATUS AGE default Active 43m kube-system Active 43m

😂

Ну чего там?

Поперло?

Сижу в Старбаксе. Обновляю конфиг в CoreOS. Рядом парень с девушкой - свидание. Она ему что-то увлеченно рассказывает. А он у меня в мониторе залипает.

Свидание в старбаксе…

С другой стороны - могло бы и в макдональдсе…

С другой стороны - могло бы и в макдональдсе…

И не свидание...

И не с девушкой?)

Поперло?

kubectl get no показывает ничего - это ок? )

Kubelet и прокси запущены?

Прокси!

Точно!

и ещё кстати kubectl не обновил

вот теперь обновил

kubectl get no по прежнему пусто

и ещё занятно, что kubectl cluster-info dump возвращает список со старым namespaces

journalctl -u kube-kubelete -f на мастере говорит, что kube-controller-manager не удаётся запустить

kubectl get po --namespace kube-system тоже пусто

Максим, модификация etcd в моём случае (как второй инстанс) должна быть такая? ... - "/usr/local/bin/etcd --listen-peer-urls 'http://127.0.0.1:3380' --listen-client-urls 'http://127.0.0.1:3379' --advertise-client-urls 'http://127.0.0.1:3379' --data-dir /var/lib/etcd" # --client-cert-auth true --trusted-ca-file /etc/kubernetes/ssl/ca.pem --cert-file /etc/kubernetes/ssl/apiserver.pem --key-file /etc/kubernetes/ssl/apiserver-key.pem --peer-client-cert-auth true --peer-trusted-ca-file /etc/kubernetes/ssl/ca.pem --peer-cert-file /etc/kubernetes/ssl/apiserver.pem --peer-key-file /etc/kubernetes/ssl/apiserver-key.pem livenessProbe: httpGet: host: 127.0.0.1 port: 3379 path: "/health" initialDelaySeconds: 15 timeoutSeconds: 15 ports: - name: serverport containerPort: 3380 hostPort: 3380 - name: clientport containerPort: 3379 hostPort: 3379 ...

нашёл ещё расхождение, что версия controller-manager 1.3.5, а не 1.3.6. перезапустил