А что есть серьёзный доклад? все-же зависит от среднего уровня участников. На мезоскон половина докладов - basic level

basic-уровень тоже нужен. Со знаниями не рождаются :)

Доброго времени суток. У меня pet-стартап и я пытаюсь понять нужен ли мне kubernetes в данный момент. Я застопорился на вопросе: нормально ли крутить k8s на vps’ках? Или смысл в использовании k8s начинается когда уже есть минимум 3 физических сервера? Я заранее извиняюсь за столь глупый вопрос, но ответ на него даст мне понять стоит ли копать дальше. Сама потребность в k8s возникла из-за того что пришло время внедрять CI/CD. Посмотрел в сторону gitlab и выяснил что он вроде как дружит k8s. Плюс расчитываю сэкономить на количестве арендуемых VPS’ок, т.к сейчас беру на каждый микросервис по VPS’ке, в итоге имею кучу виртуалок с загрузкой ЦП чуть выше нуля. Ну и еще вопрос. Что делать с БД? Думаю что никто БД не держит в контейнерах. Как в этом случае поступают? БД живет на отдельной машине?

Заранее извиняюсь за то что я написал выше и прошу не пинать дурака. Спасибо.

Доброго времени суток. У меня pet-стартап и я пытаюсь понять нужен ли мне kubernetes в данный момент. Я застопорился на вопросе: нормально ли крутить k8s на vps’ках? Или смысл в использовании k8s начинается когда уже есть минимум 3 физических сервера? Я заранее извиняюсь за столь глупый вопрос, но ответ на него даст мне понять стоит ли копать дальше. Сама потребность в k8s возникла из-за того что пришло время внедрять CI/CD. Посмотрел в сторону gitlab и выяснил что он вроде как дружит k8s. Плюс расчитываю сэкономить на количестве арендуемых VPS’ок, т.к сейчас беру на каждый микросервис по VPS’ке, в итоге имею кучу виртуалок с загрузкой ЦП чуть выше нуля. Ну и еще вопрос. Что делать с БД? Думаю что никто БД не держит в контейнерах. Как в этом случае поступают? БД живет на отдельной машине?

Крутить кубер на впс нормально. Не обязательно иметь физические сервера. Единственное что было бы хорошо - иметь три впс для etcd но на начальном этапе можно мастер и etcd поместить на 1 впс. Гитлаб умеет кубер да, у нас он работает. Кубер мало создаёт накладных расходов.

Если у вас почти не используется цпу на каждой впс- тем более, но там надо учитывать и память, конечно.

Про дб - по моему дб не очень безопасно держать под кубером. Особенно если у вас нет хорошего опыта с распределёнными хранилищами.

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

Но так же вам надо будет организовать сеть для кубера. Флаллель и тд.

Крутить кубер на впс нормально. Не обязательно иметь физические сервера. Единственное что было бы хорошо - иметь три впс для etcd но на начальном этапе можно мастер и etcd поместить на 1 впс. Гитлаб умеет кубер да, у нас он работает. Кубер мало создаёт накладных расходов.

спасибо что откликнулись! буду дальше знакомиться с технологией. По поводу БД вычитал что в докере не держат, даже при использовании k8s. Наткнулся на эту ссылку с вопросом как быть БД и k8s https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

Вопрос снят. Подсказали ссылочку почитать про StatefulSets https://habrahabr.ru/company/flant/blog/328756/

https://docs.tarmak.io/en/latest/ кто что может сказать ?

Доброго времени суток. У меня pet-стартап и я пытаюсь понять нужен ли мне kubernetes в данный момент. Я застопорился на вопросе: нормально ли крутить k8s на vps’ках? Или смысл в использовании k8s начинается когда уже есть минимум 3 физических сервера? Я заранее извиняюсь за столь глупый вопрос, но ответ на него даст мне понять стоит ли копать дальше. Сама потребность в k8s возникла из-за того что пришло время внедрять CI/CD. Посмотрел в сторону gitlab и выяснил что он вроде как дружит k8s. Плюс расчитываю сэкономить на количестве арендуемых VPS’ок, т.к сейчас беру на каждый микросервис по VPS’ке, в итоге имею кучу виртуалок с загрузкой ЦП чуть выше нуля. Ну и еще вопрос. Что делать с БД? Думаю что никто БД не держит в контейнерах. Как в этом случае поступают? БД живет на отдельной машине?

Скорее всего он вам е нужен

Доброго времени суток. У меня pet-стартап и я пытаюсь понять нужен ли мне kubernetes в данный момент. Я застопорился на вопросе: нормально ли крутить k8s на vps’ках? Или смысл в использовании k8s начинается когда уже есть минимум 3 физических сервера? Я заранее извиняюсь за столь глупый вопрос, но ответ на него даст мне понять стоит ли копать дальше. Сама потребность в k8s возникла из-за того что пришло время внедрять CI/CD. Посмотрел в сторону gitlab и выяснил что он вроде как дружит k8s. Плюс расчитываю сэкономить на количестве арендуемых VPS’ок, т.к сейчас беру на каждый микросервис по VPS’ке, в итоге имею кучу виртуалок с загрузкой ЦП чуть выше нуля. Ну и еще вопрос. Что делать с БД? Думаю что никто БД не держит в контейнерах. Как в этом случае поступают? БД живет на отдельной машине?

Бд должна быть отдельным отказоустойчивым сервисом как и сторадж

Бд должна быть отдельным отказоустойчивым сервисом как и сторадж

ее не стоит вообще c k8s связывать? так я и думал

ее не стоит вообще c k8s связывать? так я и думал

Возможно это может управляться кубернетисом. Но такие сервисы как бд и стораджи в любом случае должны быть сами по себе очень отказоустойчивыми и не зависеть от того где и как приложения работают. В идеале у тебя сторадж может быть доступен больше чем для одно кластера куба , но тут уже вопрос как организовать всё. Ясное дело можно забить на то как принято делать правильные микросервисы и самому по граблям походить

если что, в postgres 10 есть логическая репликация из коробки.

если что, в postgres 10 есть логическая репликация из коробки.

Ну занесли пглодджикал во внутрь, что то еще изменилось ?

не знаю, я не смотрел особо. просто вставил ремарку, вдруг кто-то не слышал :)

Всем привет! А подскажите пожалуйста, как найти описание, как правильно запускать kubelet в новой версии (1.8) ? А то я обновился и выяснилось, что ключи не подходят. Нашёл описание ключей https://kubernetes.io/docs/admin/kubelet/ и выяснилось, что ключа "--api-servers" больше нет )) там же нашёл, что теперь есть ключ "--kubeconfig string" Но его описание крайне скудно: Path to a kubeconfig file, specifying how to connect to the API server. (default "/var/lib/kubelet/kubeconfig") Подскажите, где найти (и как правильно искать) синтаксис этого файла?

и "--register-schedulable" ключа тоже походу больше нет ))

Поиск этого файла по репе кубера не принёс результатов?

принёс))) https://github.com/kubernetes/kubernetes/blob/master/cluster/saltbase/salt/kubelet/kubeconfig он пустой и добавлен два года назад)))

принёс))) https://github.com/kubernetes/kubernetes/blob/master/cluster/saltbase/salt/kubelet/kubeconfig он пустой и добавлен два года назад)))

https://github.com/kelseyhightower/kur/blob/master/kubeconfigs/kubelet.kubeconfig сдаётся мне это тот файл что лежит у вас в хом дире .kube/

https://github.com/kelseyhightower/kur/blob/master/kubeconfigs/kubelet.kubeconfig сдаётся мне это тот файл что лежит у вас в хом дире .kube/

Спасибо!

вобщем если хотите настоящий HA то не ставьте этот параметр и терпите вечный трафик в etcd на обновление этой записи каждые N секунд. в противном случе если apiserver упадет (или будет выключен для обновления скажем), то 1/X коннектов к apiserver будут с ошибкой, где X - количетсво apiservers

думаю над --apiserver-count для kube-apiserver. как часто apiserver будет замещать чужой адрес из kubernetes.svc? мутить еще один балансировщик для apiserver не хочется. вроде отлично иметь N endpoints с мультимастером, а вроде и не очень, если один выпал.

есть такой вмердженный pr https://github.com/kubernetes/kubernetes/pull/51698 который похоже только в 1.9 появится. который добавляет опцию --alpha-endpoint-reconciler-type=(master-count, lease, none) (default "master-count"). The original reconciler is 'master-count'. The 'lease' reconciler uses the storageapi and a TTL to keep alive an endpoint within the `kube-apiserver-endpoint` storage namespace. The 'none' reconciler is a noop reconciler that does not do anything. This is useful for self-hosted environments. которая возможно все приведет в порядок c lease reconciler

господа, а есть работающие бест-практисы организации манифестов для kubernetes в репозитории и их последующего деплоя? наивный подход "один неймспейс - один репозиторий - деплой всегда через kubectl apply -f /path/to/root --recursive" становится неудобным и странненьким достаточно быстро. сразу начинает хотеться добавить шаблонизаторов в configMap, например. или последовательного деплоя (новая конфигмапа со сгенерированным лейблом, потом передеплой деплоймента с новой конфигмапой). как канонично решаются такие проблемы?

господа, а есть работающие бест-практисы организации манифестов для kubernetes в репозитории и их последующего деплоя? наивный подход "один неймспейс - один репозиторий - деплой всегда через kubectl apply -f /path/to/root --recursive" становится неудобным и странненьким достаточно быстро. сразу начинает хотеться добавить шаблонизаторов в configMap, например. или последовательного деплоя (новая конфигмапа со сгенерированным лейблом, потом передеплой деплоймента с новой конфигмапой). как канонично решаются такие проблемы?

возможно будет интересно посмотреть на helm

у нас 2 k8s кластера dev и prod. манифесты лежат в одной репе, дерево: dev/namespace/сервис/манифесты

возможно будет интересно посмотреть на helm

уже. он решает из этого фактически только шаблонизацию.

+ внутри namespace лежит манифест для namespace и role

уже. он решает из этого фактически только шаблонизацию.

Мы делаем примерно так ├── Chart.yaml ├── README.md ├── templates │   ├── NOTES.txt │   ├── _helpers.tpl │   ├── deployment.yaml │   ├── ingress.yaml │   └── service.yaml ├── values │   ├── env1 │   │   ├── secrets.enc │   │   └── values.yaml │   └── env2 │   ├── secrets.enc │   └── values.yaml └── values.yaml

я вот нашел еще https://github.com/deepmind/kapitan

Мы делаем примерно так ├── Chart.yaml ├── README.md ├── templates │   ├── NOTES.txt │   ├── _helpers.tpl │   ├── deployment.yaml │   ├── ingress.yaml │   └── service.yaml ├── values │   ├── env1 │   │   ├── secrets.enc │   │   └── values.yaml │   └── env2 │   ├── secrets.enc │   └── values.yaml └── values.yaml

а если ещё прибавить CD? (Например гитлаб). Как обновлять образы?

а если ещё прибавить CD? (Например гитлаб). Как обновлять образы?

+

а если ещё прибавить CD? (Например гитлаб). Как обновлять образы?

в cd для часто меняющихся апп - helm upgrade --install --wait --namespace $NAMESPACE -f values/$ENV/values.yaml -f values/$ENV/secrets.enc --set app.image.tag=$GIT_SHA1 $CHART_NAME ./

в cd для часто меняющихся апп - helm upgrade --install --wait --namespace $NAMESPACE -f values/$ENV/values.yaml -f values/$ENV/secrets.enc --set app.image.tag=$GIT_SHA1 $CHART_NAME ./

да это понятно, но откуда брать GIT_SHA1, если манифесты и приложение — две разные репы?

для тех, у кого версия жестко зашита и меняется вручную, вроде прометея, просто values поменять

да это понятно, но откуда брать GIT_SHA1, если манифесты и приложение — две разные репы?

зачем?

зачем?

штобы деплой в один клик

точнее, в один пуш

в смысле - зачем две разные репы?

в смысле - зачем две разные репы?

всё-таки одна репа? (хельм + приложение)

в смысле - зачем две разные репы?

потому что приложение (код) и его инстанс - разные вещи, очевидно

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

что никак не влияет на структуру самого чарта

что никак не влияет на структуру самого чарта

ну да, но инстанцируете это все вы как?

вот есть реп, где куча вызовов чартов с кучей конфигов (values.yaml)

как это деплоится?

CD система дергает helm, в нашем случае CircleCI

До shared чартов и нормального наследования мы пока не особо дошли

собственно строчка выше - это почти прямая копипаста из конфига CircleCI

всё-таки одна репа? (хельм + приложение)

всё-таки одна репа? (хельм + приложение)

для разрабатываемых приложений - да, одна

CD система дергает helm, в нашем случае CircleCI

и чарты у вас пишут разрабы, а конфиги - те кто отвечает за деплой?

грубо, если

и чарты у вас пишут разрабы, а конфиги - те кто отвечает за деплой?

Сначала это делали опсы, чтоб понять как это все работает, теперь мы обучаем разрабов и они уже остальные приложения переводят в чарты.

Задача - дать разрабам возможность максимально независимо от инфра команды выкатывать новые приложения

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

и что в контексте кубера (или данного чата) понимается под baremetal?

baremetal - это не aws\azure\gke

self managed, где нет api для управления обвязками типа балансировщиков

ну вот оно по ходу) 10 машин, где нет никакой магии кроме доступа до них. Ну и айпишник внешний на всё это дело

а чёрной магией кто-нибудь занимается? Типа оркестрации кластера кубера в ранчере или как-то ещё

а чёрной магией кто-нибудь занимается? Типа оркестрации кластера кубера в ранчере или как-то ещё

Сам себе пробовал ответить на вопрос «Зачем?»

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

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

понятно, что вручную всегда можно сделать. Ансиблом вроде тоже тривиально. Мой кластер поднят через 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 вполне норм утилита для поднятия, но одного мастера + много воркеров

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