я вот и сам хочу спросить, слышал, что такое используется

меня интересует обновление кластера на бареметалах

понятно, что вручную всегда можно сделать. Ансиблом вроде тоже тривиально. Мой кластер поднят через kubeadm + напильник = HA. Но kubeadm всё равно страшно использовать для обновлений

так попробуй на стенде сначала =)

предположу что тебе придется сделать - напильник, вернуть все к состоянию, которое знакомо kubeadm, апдейтить, и + напильник

Господа, с чего начать переход со сворма на кубер? Исходные данные - сворм из 10 машин, 3 из них мастеры (менее нагруженные, но на них тоже по одному-два докер образа крутится)

Полагаю, что начать следует с поднятия etcd кластера на бывших мастер-нодах. После поднять overlay сетку, flannel видится самым распространённым решением. Адепты кубера, подскажите плз, на верном ли я пути?

я думаю не очень идея смешивать

поскольку докер точно придется из swarm выводить, лучше все с нуля начать

Что именно?

Докер то точно из сморма будет выведен

k8s & swarm, flannel & docker overlay

Разве не вариант поднимать потихоньку кубер, на сворме оно пока крутится

Потом разом переключить

Даунтайма нельзя допустить. Понятно, что без него совсем не получится, но надо обеспечить самый минимальный хотя бы

Посему и собрался заводить параллельно

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

потому что после etcd нужно запускать kubelet, который должен будет запустить еще свои компоненты в контейнерах. и не думаю что это получится при живом swarm

ну там попроще, прибить все стеки, все сервисы и прочее подобное, прибить сетки, прибить ноды и сам сворм. Это всё сделается чуть ли не в одну строчку и весьма быстро К этому времени кубер желательно чтобы был хотя бы поднят, мастеры и ноды руг о друге знали и были готовы к поднятию подов

не выйдет так думаю

Принято, спасибо. Буду выбивать согласования на даунтайм. А по подходу - всё ли верно? etcd-кластер, flannel сначала?

я вообще негативщик. я думаю на работающем сворме kubelet ничего не запустит

тогда какой самый нормальный подход в вашем понимании? Прибиваем сворм (полностью) - далее что делать?

решаем как будем деплоить к8с

kubespray для своего железа, или kubeadm, или вручную

Вручную

kubeadm бета, и не совсем понятно что он делает внутри. Плюс нет гарантий что без косяков обойдётся

kubeadm бета, и не совсем понятно что он делает внутри. Плюс нет гарантий что без косяков обойдётся

kubeadm вполне норм утилита для поднятия, но одного мастера + много воркеров

остальное напильником

kubespray для своего железа, или kubeadm, или вручную

вот кстати в сторону kubespray ещё не сильно смотрел

решаем как будем деплоить к8с

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

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

Благодарствую, сейчас почитаем

kubespray норм

думаю написать статейку как в 10 команд поднять baremetal кластер с использованием kubespray и демо-приложение с letsencrypt

думаю написать статейку как в 10 команд поднять baremetal кластер с использованием kubespray и демо-приложение с letsencrypt

флаг в руки (я не шучу)

думаю написать статейку как в 10 команд поднять baremetal кластер с использованием kubespray и демо-приложение с letsencrypt

Плюсую яростно заочно! Просим!!!

Ну это без тонкостей. Для быстрого старта в самый раз. То, чего мне не хватало две недели назад

Ну это без тонкостей. Для быстрого старта в самый раз. То, чего мне не хватало две недели назад

Всё украдено до нас :))

https://dev-ops-notes.ru/%D1%83%D1%87%D0%B5%D0%B1%D0%BD%D0%B8%D0%BA-kubernetes/

это 1/3. А еще Ingress, а еще letsencrypt

это 1/3. А еще Ingress, а еще letsencrypt

https://dev-ops-notes.ru/kubernetes/kubernetes-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-ingress/

letsencrypt для чего? https на внешку?

letsencrypt - спорный вопрос

для входа да, остально проще своими сертами мутить

прочитал, у меня несколько по-другому. И не факт что у меня правильно

letsencrypt для чего? https на внешку?

ну да

letsencrypt - спорный вопрос

а чего спорить? лично у меня нет желания покупать Wildcard SSL за >$ 334.95 /год для различных севисов на своем домене - от блога и своих проектов до owncloud

а чего спорить? лично у меня нет желания покупать Wildcard SSL за >$ 334.95 /год для различных севисов на своем домене - от блога и своих проектов до owncloud

я прекрасно вас понимаю - у самого более сотнее доменов на letsencrypt с автоматическим обновлением через jenkins. Речь про то, что тянуть letsencrypt для etcd и master - оверхед в подовляющем большинстве случаев.

да. кстати автообновление letencrypt я не проверял. Но могу сказать что в моем самосборе а-ля Ingress-controler для Docker Swarm автообновление letsencrypt не работало. Как только подходил срок приходилось стопорить контейнера и перезапускать чтобы сертификаты обновлились

я прекрасно вас понимаю - у самого более сотнее доменов на letsencrypt с автоматическим обновлением через jenkins. Речь про то, что тянуть letsencrypt для etcd и master - оверхед в подовляющем большинстве случаев.

почему? Если собственного CA нету

почему? Если собственного CA нету

ну о том речь - поднять его для кубера - отличная затея. Гораздо лучше, нежели пытаться выехать на сервисе letsencrypt. Ну мы накушались с обновлением, я тоже не на ровном месте полемику развожу. Ждём wildcard от letsencypt - в 2018 обещали

ну о том речь - поднять его для кубера - отличная затея. Гораздо лучше, нежели пытаться выехать на сервисе letsencrypt. Ну мы накушались с обновлением, я тоже не на ровном месте полемику развожу. Ждём wildcard от letsencypt - в 2018 обещали

поднимать CA только ради того, чтобы поднять CA - идея очень плохая

поднимать CA только ради того, чтобы поднять CA - идея очень плохая

Kubernetes hard way - вроде с сертов и начинается, и это правильно, поскольку на понимание этого уходит много времени. В конце концов - просто точка зрения.

А кто нибудь уже поднимал на CoreOS кубернет 1.8 ? А то у меня что-то не поднимается, не пойму почему. kubelet поднимает паузные контейнеры "gcr.io/google_containers/pause-amd64:3.0 "/pause" k8s_POD_kube-proxy-10.1.29.12_kube-system_30c721be7d28f79fadf551ad172b9927_0" И дальше тишина - основные контейнеры не поднимаются((

Господа, пытаюсь делать kubeadm init в сислоге Oct 30 17:12:00 gmuweb-srv kubelet: W1030 17:12:00.767469 51660 cni.go:196] Unable to update cni config: No networks found in /etc/cni/net.d

Что ему не хватает? какой нить flannel просит?

для летсенкрипт есть кубе лего с автообновлением и плюхами

Что ему не хватает? какой нить flannel просит?

up

ну епт

а документацию почитать?

https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/

после инита на мастере нужно сеть втащить

Так инит не проходит

Я в этой доке и сижу

там еще открыв инфу по calico, можно увидеть ключ pod-network-cidr

хочешь сказать он тебе не выдал в конце kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>

после init kubelet еще не может начать работу, сети нет

хотя нет, гоню. он уже должен запустить apiserver точно

и etcd

Подскажите пожалуйста, как изменить путь к образу гиперкуба на локальный реджестри для кублета? делаю вот по этому мануалу: https://coreos.com/kubernetes/docs/latest/deploy-master.html Добавил это: Environment=KUBELET_IMAGE_TAG={{.hyperkube_version}} Environment=KUBELET_IMAGE_URL=docker://{{.insecure_registry}}/k8s/hyperkube В итоге в рокете гиперкуб стартует, но при попытке поднять аписервер (и прочие компоненты) в докере - ошибка "Back-off pulling image \"quay.io/coreos/hyperkube:1.8.1\" и как видно из ошибки - лезет опять наружу...

там еще открыв инфу по calico, можно увидеть ключ pod-network-cidr

что с ключом, что без - kubeadm init не проходит

[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10255/healthz' failed with error: Get http://localhost:10255/healthz: dial tcp [::1]:10255: getsockopt: connection refused.

Стопицот ошибок что он локально ломиться пытается

выхлоп у kubeadm init какой?

[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10255/healthz' failed with error: Get http://localhost:10255/healthz: dial tcp [::1]:10255: getsockopt: connection refused.

Ну это одна из строк

Полный вывод кинуть?

iptables не блокирует общение?

блин, да не должен

порт 10255 должен кубелет открыть