деталей на знаю, prometheus занимается @W2opTY

Благодарю)

Подскажите, пожалуйста, по поводу внедрения kubernetes в продакшн. Можно пальцем в небо. Сколько обычно занимает по времени разбить готовое приложение: - веб сервер - приложение - БД - кэш - хранилище файлов на контейнеры и запустить это все на kubernetes? И добавить какой-нибудь мониторинг. Ну и по отказоустойчивости допилить. Сколько вот такое мероприятие может занимать по времени?

думаю 1-3 месяца в зависимости от компетентности

думаю 1-3 месяца в зависимости от компетентности

Т.е. месяц работы одному специалисту? Это реально?

думаю 1-3 месяца в зависимости от компетентности

Или имеется в виду, что человек каждый день ставит kubernetes, ceph, proxmox и прочее?

1 мес это займет у человека который такие вопросы не задает. Судя по наличию вопроса - я б сказал что минимум 2 мес =) просто то б не ошибиться в сроках

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

(личный опыт)

Я никогда не тетсирую свой код, но если тестирую то в продакшене (с)

=)

перевели всю инфру с авс на азур за 2 месяца

со старого кубера на новый

Товарищи, кто подскажет, нормально ли деплоится и работает ceph на кубернетес через DaemonSet? и какие есть подводные камни работы цефа на кубере?

Всем привет. Кто-то мониторит Kubernetes на bare-metal?

https://blog.argoproj.io/volume-monitoring-in-kubernetes-with-prometheus-3a185e4c4035

Товарищи, кто подскажет, нормально ли деплоится и работает ceph на кубернетес через DaemonSet? и какие есть подводные камни работы цефа на кубере?

зачем вам? на бареметал всяко лучше сторадж вне кубера делать, в клаудах - есть широкий выбор volumes

зачем вам? на бареметал всяко лучше сторадж вне кубера делать, в клаудах - есть широкий выбор volumes

Ридврайтмэни поддерживают крайне мало решений. На диджитадоушен диски слабо поддерживаются кубером

зачем вам? на бареметал всяко лучше сторадж вне кубера делать, в клаудах - есть широкий выбор volumes

почему вне и в чем там будут плюсы?

данные гонять между серверами и амазоном так хорошо?

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

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

удобно. dynamical provisioning

а разве на своем железе нельзя сделать динамическое выделение?

почему вне и в чем там будут плюсы?

когда кубер заглючит, ваши данные не пострадают. Обычно это важно.

Хм... а можно примеры реальных затрат на это? Меня сейчас по большей части смущают именно они

просто я реально сомневаюсь что туда стоит те же БД пихать например

Ридврайтмэни поддерживают крайне мало решений. На диджитадоушен диски слабо поддерживаются кубером

судя по https://github.com/kubernetes/kubernetes/issues/32334 есть воркараунд. Но на мой взгляд чем проще, тем лучше. KISS. И отказоустойчивость лучше делать средствами сервиса, а не средствами СХД.

просто я реально сомневаюсь что туда стоит те же БД пихать например

если вы реально понимаете что делаете, и для чего. Hello-world DB нормально работают в кубере. Но для бизнес вещей я бы лично не стал их туда пихать.

Blablacar запихало галеру в кубер

И живут в проде

Так, просто чтобы подержать беседу :)

ну убер тоже. не вопрос. Если знаешь что делаешь.

судя по https://github.com/kubernetes/kubernetes/issues/32334 есть воркараунд. Но на мой взгляд чем проще, тем лучше. KISS. И отказоустойчивость лучше делать средствами сервиса, а не средствами СХД.

Да читал уже, и даже есть сервисы которые умеют в ДО цеплять динамически диски, даже попробовали их и они работают, но хочется более продакшн реди

на DO печаль в том что нельзя более 5 дисков маунтить в одну машину

Да читал уже, и даже есть сервисы которые умеют в ДО цеплять динамически диски, даже попробовали их и они работают, но хочется более продакшн реди

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

А как быстрее разворачивать kubernetes, чтобы не потерять в гибкости? https://github.com/kubernetes-incubator/kubespray - юзаете?

разве поиск по чату не дает исчерпывающий ответ?

разве поиск по чату не дает исчерпывающий ответ?

Это мне? А по каким тегам можно дернуть поиск?

> если знаешь что делаешь > галера начнем же срач

разве поиск по чату не дает исчерпывающий ответ?

вроде что-то нашел по kuberspray в чате. буду изучать

> если знаешь что делаешь > галера начнем же срач

имеете что бросить на вентилятор? )) имхо БД в кубере для тех, кто знает все тонкости БД без кубера. + имеет большие инженерные ресурсы (как кубер так и БД) на решение проблем.

имеете что бросить на вентилятор? )) имхо БД в кубере для тех, кто знает все тонкости БД без кубера. + имеет большие инженерные ресурсы (как кубер так и БД) на решение проблем.

да тут даже не в кубере проблема

ну я о базах в кубере in general, а не о конкретной реализации. Не понимаю почему из докера и кубера пытаются серебрянную пулю вылипить

если вы реально понимаете что делаете, и для чего. Hello-world DB нормально работают в кубере. Но для бизнес вещей я бы лично не стал их туда пихать.

ну так и я про что, просто про них все говорят а мне ничего в голову не приходит кроме как хранить там статику какую... но статика и так не упадет если машина грохнется, так что я не учитываю?

а что для вас статика и какой тип волюма?

ну вообще я везде persistentVolumeClaim юзаю, по факту там hostPath как я понимаю

а статика в общем смысле это то что обновляется не очень часто, т.е. ну раз в пол часа может быть если деплоиться раз в пол часа придется) некие файлы типа аваторок пользователей например тоже сюда же, можно пихнуть те же js/css и прочее подобное

в общем думаю смысл понятен

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

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

все просто глупые, не обращайте внимания.

ну вообще я везде persistentVolumeClaim юзаю, по факту там hostPath как я понимаю

нет.

а статика в общем смысле это то что обновляется не очень часто, т.е. ну раз в пол часа может быть если деплоиться раз в пол часа придется) некие файлы типа аваторок пользователей например тоже сюда же, можно пихнуть те же js/css и прочее подобное

обычно js/css не засовывают в клаудные стораджа (S3) как раз.

А что туда пихают?

потяжелее контент. картинки. видео. аудио. артефакты сборки.

js/css можно и в контейнер прямо встроить и прокешировать на CDN. Либо сразу на CDN, если бизнес-задача оправдывает.

судя по https://github.com/kubernetes/kubernetes/issues/32334 есть воркараунд. Но на мой взгляд чем проще, тем лучше. KISS. И отказоустойчивость лучше делать средствами сервиса, а не средствами СХД.

сейчас ссылку не найду, но где-то читал что новых вольюмов не будет больше, все должны использовать FlexVolume теперь: https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md

А как быстрее разворачивать kubernetes, чтобы не потерять в гибкости? https://github.com/kubernetes-incubator/kubespray - юзаете?

coreos + pxeboot

обычно js/css не засовывают в клаудные стораджа (S3) как раз.

а EBS это клаудый сторадж или нет? :)

coreos + pxeboot

а есть вменяемые варианты развертывания класса не "the hard way" ?

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

потяжелее контент. картинки. видео. аудио. артефакты сборки.

Хм.. а артефакты то зачем? Их же можно сразу в реджистри? Или как раз реджистри там и находится?

Хм.. а артефакты то зачем? Их же можно сразу в реджистри? Или как раз реджистри там и находится?

реджистри в s3 - милое дело.

как впрочем и деб-зеркала например

а как щас у кубера состояние с CRI? кто-нибудь пробовал альтернативы докеру?

Максим пробовал, спроси в питерском чате :)

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

Magento, akeneo и итд на кубернетесе #whois

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

нет, если self hosted то мейнтенить надо только только систему по запуску kubelet , а это просто. все остальное - kubectl apply

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

ну как-то в жизни оно не совсем так просто... так и сидим на 1.6 пока

всмысле там где свой велосипед.

ну может еще аукнется мне, но пока все выглядит оч хорошо, обновился на 1.8.4 влёт)

будет 1.8.5 может запишу asciicinema :)

с 1.7 ?

нет, с 1.8.2 ) но принципиально ничего не меняется все фичи те же. если скажем выкатывать RBAC, то готовиться надо потщательней, но с такими апдейтами ничего не спасет, никакой kubespray не знает какие у вас приложения и как они пострадают от RBAC или от PodSecurityPolicy

ну минорный апдейт не проблема

kubespray может и не знает, а kops более-менее

Коллеги, есть вопрос. У меня настроен provisioning volumes в связке с ceph rbd Я создаю deployment с 1 репликой, создается pod и volume. Далее я увеличиваю количество реплик до 10 и получаю 5 работающих подов и 5 с ошибкой 'MountVolume.SetUp failed for volume "id" rbd: failed to lock image'. Volume с Access mode ReadWriteOnce, собственнно ReadWriteMany не поддерживается. Это нормальное поведение?

kubespray может и не знает, а kops более-менее

что он знает? как он знает? логи с apiserver собирает перед апдейтом и говорит "у вас вот это и вот это приложения отвалятся, если апдейт раскатаете", так что ли?

Хм.. а артефакты то зачем? Их же можно сразу в реджистри? Или как раз реджистри там и находится?

Зачем хранить артефакты на своем диске?

Зачем хранить артефакты на своем диске?

не храню, пихаю в стандартный реджистри докера, но через некоторое время его будет не хватать, это да( Выгоднее получается будет использовать просто облачное хранилище чем докупать места там?)

S3 юзай, боже