там же controller reference или что-то такое было, новый стейтфулсет подберет поды?

насколько я понял из документации - должен (поправьте если ошибаюсь): https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#non-cascading-delete

насколько я понял из документации - должен (поправьте если ошибаюсь): https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#non-cascading-delete

интересно, helm такую логику умеет?

как вы обновляете поды в вашем кластере? какой самый удобный способ делать это из CD? через частный helm репозиторий?

смешались в кучу люди кони

о чем вопрос?:)

я сначала думал, что кубер сам фетчит последний образ докера, потом понял что видимо нет и надо делать kubectl rolling update, нашел блог, там человек говорит, что вызывать kubectl из cd сервиса моветон (докер-в-докере) и надо юзать helm репозиторий, я немножко запутался и решил спросить у вас как надо делать вот блог: http://blog.lwolf.org/post/how-to-create-ci-cd-pipeline-with-autodeploy-k8s-gitlab-helm/

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

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

нормально делай - нормально будет

нормально делай - нормально будет

R!

памажите советом девопсоны ><

памажите советом девопсоны ><

юзай helm :) и будет тебе счастье

юзай helm :) и будет тебе счастье

helm гавно

что лучше?

почему гавно?

почему гавно?

https://t.me/openstack_ru

при чем тут это?

Аналогов helm нет:) А гавно потому что баг на баге. То wait сломают, то изменения не применяются при upgrade

ну видимо мы его пока не в том масштабе используем, чтобы так критиковать. Если его правильно использовать, замены ему пока нет

Аналогов helm нет:) А гавно потому что баг на баге. То wait сломают, то изменения не применяются при upgrade

wait всё еще сломан?

Уже починили, но было неприятно когда сломали)

Сделали свой wait в итоге

ну то есть чтобы не наткнуться случайно на проблемки лучше напряму из kubectl делать rolling-update в CD?

Если нет ощущения, что helm сильно нужен, то можно без него. Просто делать apply для deployment. Update сам запустится

поддерживаю, если можно обойтись без helm, то лучше без него

Мы резко захотели helm, когда второй кластер появился

другое дело, что темплейтить ресурсы захочется очень быстро :)

другое дело, что темплейтить ресурсы захочется очень быстро :)

Вы используете общие темплейты для разных сервисов? Или у каждого сервиса свой набор темплейтов?

у нас есть generic-app chart где много разной магии. приложения это пустые charts (в них нет templates), они подтягивают generic-app как зависимость и переопределяют её переменные

ну я использую helm только для развертывания софта, и он в этом плане норм... а для деплоя я deis юзаю например

темплейты можно так же helm'ом описывать, helm-template'ом генерировать, пушить в репу, а потом с помощью kubectl применять

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

если требуется почему нет, по бранчам например

но мы так не делаем)

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

Чатик, у кого нить крон джобы в кубике работают?

Работают у меня. (1.5.2 версия) Нужно врубить альфа фичи в апи и в шелдулере.(или контроллер манагер точно не помню)

порноторренты? нелицензионные песни ваенги? спс не надо

посмотрел, посмеялся, спасибо

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

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

храним в отдельном локальном репо, вытягиваем перед апплаем

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

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

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

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

а ещё вопрос, пишут DIND порочная практика, но у меня, например, пока так, и образ, и apply куба вызываю в контейнере дженкинса. как вообще принято подобное обходить? я вот задумываюсь, стоит ли CI доверять куб, ну или хотя бы вынести это в отдельный пайплайн, а не в пайпе приложения всё делать

привет) пользуетесь https://github.com/fission/fission ? стабильно/нет?

интересно сравнение с https://github.com/alexellis/faas

привет) пользуетесь https://github.com/fission/fission ? стабильно/нет?

хмм, не пользуетесь?)

привет) пользуетесь https://github.com/fission/fission ? стабильно/нет?

Тестировали, работает, но не супер стабильно, в прод не решились

а ещё вопрос, пишут DIND порочная практика, но у меня, например, пока так, и образ, и apply куба вызываю в контейнере дженкинса. как вообще принято подобное обходить? я вот задумываюсь, стоит ли CI доверять куб, ну или хотя бы вынести это в отдельный пайплайн, а не в пайпе приложения всё делать

DIND порочная практика?

DIND порочная практика?

неоднократно читал и слышал. хотя сам практикую)

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

Мы все инфраструктурные штуки потихоньку выносим в отдельный репозиторий, который подключаем гит сабмодулем в 3 приложения. Хочется монорепозиторий, но пока морально не готовы.

Кроме самих приложений есть десятки системных чартов и образов, типа Prometheus и graylog. С ними автоматизация хромает. Сборка и деплой руками с локальной машины.

DIND порочная практика?

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

https://twitter.com/b0rk/status/872658092818927616 b0rk что-то задумала

Чатик, у кого нить крон джобы в кубике работают?

сегодня как раз заработали, у меня 1.5.3 версия. Нужно api server запускать с —runtime-config=batch/v2alpha1=true и порестартить kubelet дока https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

у меня celery для этого крутится

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

gitlab runner + gitlab ci

http://docs.gitlab.com/ce/ci/runners/README.html ну и там дальше .gitlab-ci.yml ложится в репу где описываются все шаги. runner можно запускать просто как docker контейнер или внутри куба. Но если в кубе запускать, то там кажется не работал кеш докера между промежуточными билдами, а с dind тоже какая-то трабла была

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

или пока никак?

А реестр и приложения как в аписервере оказываются?

А kubelet, kube-dns не из этого registry запускаются?)

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

разворачивайте registry на стадии разворачивания куба. т.е. кластер не готов, пока в нем нет kube-dns, registry и прочих обязательных для вас вещей

кстатити сам не пробывал, но точно помню были баги на гитхабе о том, что registry внутри куба работает как-то плохо

что-то насчет того , что докер не мог тянуть имаджи из регистри, который запущен под этим же самым докером.

Котаны, смотрите какая пепяка. Есть кубернетес кластер (1.5.7 на данный момент), развёрнутый через kops на AWS. Кластер разработческий, на нём много редеплоев в день. На нодах докер 1.12.3. Через некоторое время лютейшим образом увеличивается время скачивания свежих образов через docker. Реджистри значения не имеет, с любого тянется медленно. При этом сеть в принципе на ноде не деградирует вовсе.

Куда бы вы копали?

Некоторое время это +/- сутки

потом не возвращается в нормальное состояние?

рестарт демона исправляет ситуацию?

Нет

причём аффектятся все ноды

рестарт демона лечит

я подозреваю какой-то неприятный баг в докере, конечно

ну pprof его

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

Наблюдаю подобное же с версии 17.04 у соседа)

Каждый день рестартует докер

Засирается арпкеш