Оно сегодня при удалении релиза удалило то, что в релиз не входило :)

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

Ну package manager должен уж как то гарантировать корректность

Еще эта идея публиковать тарболы в стиле 90х, брр

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

Helm.sh/post-upgrade хук: Если это job то следующий апгрейд релиза провалится, так как оно не сможет его создать.

Еще этот tiller, нафига? Все равно все пишет в configmap, а атомарность create позволяет делать лок на конекретный редиз, так что тиллер вполне себе мог бы жить в клиенте

Просто кому то хотелось в grpc поиграться :)

нет, это кривой kubectl apply с блэкджеком

никакой транзакционности и роллбэков. может посчитать что изменений нет,хотя если сравнить оъект в helm get release и в kubectl get XXX -o yaml они будут разными

все подвязано на labels и selectors ,от этого ты можешь установить новый релиз, удалить его, а оно с собой утянит что-то что было до этого. просто потому что labels совпали :)

базовые вещи поломаны: релиз может "усыновить" ресурсы которые уже были, в итоге сам релиз фэйлится и пользователь скажем решает его удалить. оно удаляет и то, что реально не было установлено :) или скажем оно забывает про любые ресурсы, в которых явно прописан namespace. ну или самый ад: upgrade after failure, оно делает совсем не то, что кажется - там внутри идет генерация патча на каждый апгрейд, при этом база для патча - последний релиз, неважно зафэйлин он был или нет. в итоге скажем в релизе изменили A, B при этом B сломало релиз, пользователь делает B' и ожидает получить в кубе и A и B', а получает только B' :)

зато rudder плагины пилят и другие шашечки, проблемы выше даже, как bug не помечают. для них bug это когда panic в их коде :)

тьфу, я думал спам пришел)

Надо какой то Wiki уже сделать ))

Надо какой то Wiki уже сделать ))

+1

в случае факапа - просто другой инстанс за DNS

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

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

Ну тут надо взвесит все вероятности и понять нужно ли это делать до того как вы пойдете в прод

Еще поищу истрию и объеденю под тагом #helmговно для будущих поколений

helm.sh уже есть, осталось дописать к нему .it и можно туда все это сложить

ну и ссылку с основного сайта "Наши друзья: helm.sh.it"

Ребят, а кто как решает HA для докер регистри?

bintray как вариант.

ну и ссылку с основного сайта "Наши друзья: helm.sh.it"

:D

Всем привет, а я тут продолжаю всякими непотребствами заниматься: https://github.com/kvaps/kube-lustre/

Всем привет. Прошу пнуть в нужную сторону, не знаю с чего начать и что читать в сторону kubernetes. Есть 4 тачки на которых настроен к8с 1 мастер и 3 слейва (Bare Metal). Всё функционирует. Говорил с разрабами, они хотят, что бы всё у них поднималось автоматически (SaltStack, Ansible и т.п.). Может есть у кого, примеры/статейки/инструкции как собирать кластер на к8с для продакшн целей. Всем спасибо

https://puppet.com/blog/new-supported-puppet-modules-make-kubernetes-deployments-easier свежак

>> Говорил с разрабами, они хотят, что бы всё у них поднималось автоматически (SaltStack, Ansible и т.п.) это как?

>> Говорил с разрабами, они хотят, что бы всё у них поднималось автоматически (SaltStack, Ansible и т.п.) это как?

всё что бы поднималось автоматически с помощью скриптов соли или ансибла, к тому же автоматически пересобиралось, если что-то упало

возможно, вы хотели написать “боли” вместо “соли”? :)

админской

возможно, вы хотели написать “боли” вместо “соли”? :)

что-то в этом есть

похоже автор вообще не знает что ему надо

"всё" это что?

"всё" это что?

насколько я понял, поды

всё что бы поднималось автоматически с помощью скриптов соли или ансибла, к тому же автоматически пересобиралось, если что-то упало

вам не нужен никакой ансибл с кубом

просто почитайте с разрабами введение в доку по ролям

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

просто почитайте с разрабами введение в доку по ролям

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

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

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

c LFS158x

c LFS158x

Linux from scratch?

нет, там другие обозначения :)

Достаточно просто https://kubernetes.io/docs/concepts/ прочитать

У нас есть проблема с нодами, которые периодически рестартятся из за кернел паника, в дампе каждый раз разная причина (тут есть логи https://gist.github.com/dandronov-alytics/d999698122674106cedf7fd7507daca0), проблема возникает крайне хаотично, нода может работать несколько недель (вплоть до месяца) а потом упасть 3 раза за сутки, связи с нагрузкой на сервер не обнаружено (сервер не сильно нагружен, пиков по нагрузке тоже не бывает). версии компонентов: OS: ubuntu 16.04 (kernel 4.10) kubernetes 1.8.3 etcd 3.2.4 docker 17.03 CNI: calico 2.6.2

Прогоняли мемтест в течении суток. Нет проблем с памятью. Запустили диагностику дисков, но чето ощущение что и там чисто будет. Может таки кто нибудь поделится версиями компонент стабильных продакшен кластеров? ??

И еще вопрос - могут быть подобные проблемы от некорректного сетапа кластера?

линукс-говно

воможно

линукс-говно

фрибсд?

inferno

радикально

Гайз, а есть кто под маком и на docker edge с кубернетесом? Как ему сказать, чтобы не делал docker pull а использовал локальные images?

Прогоняли мемтест в течении суток. Нет проблем с памятью. Запустили диагностику дисков, но чето ощущение что и там чисто будет. Может таки кто нибудь поделится версиями компонент стабильных продакшен кластеров? ??

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

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

Думаете это может дать какую то дополнительную полезную информацию для анализа, кроме той что - да, на нагрузке падает? Мб подскажете пример подобной тулзы?

Думаете это может дать какую то дополнительную полезную информацию для анализа, кроме той что - да, на нагрузке падает? Мб подскажете пример подобной тулзы?

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

https://www.tecmint.com/linux-cpu-load-stress-test-with-stress-ng-tool/ вот например

https://www.tecmint.com/linux-cpu-load-stress-test-with-stress-ng-tool/ вот например

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

Гайз, а есть кто под маком и на docker edge с кубернетесом? Как ему сказать, чтобы не делал docker pull а использовал локальные images?

Вроде разобрался. imagePullPolicy=Never

кто как миграции баз проводит?

кто как миграции баз проводит?

слева направо

вот все время одно и то же, вместо того чтобы сказать "у нас стандартные практики, вот ссыль" или "у нас нестандартная практика, с использованием этих инструментов гасим одно, второе третье, с использованием тех инструментов проводим миграцию, потом так-то подымаем" одно bebebe

не теки Олег, соберись

либо плати денюшки

кто как миграции баз проводит?

нет, ну а какая разница, в кубернетесе эта база или нет?

лол, как будто за денюшки будет что то адекватное... навидался я этих ниндзя-консультантов

йопта, если тебе нечего кроме дай денег сказать, так промолчи

Олег, что вы себе позволяете

нет, ну а какая разница, в кубернетесе эта база или нет?

да разниц много. боюсь перечислять. но у каждого своя. интересен опыт каждого

да разниц много. боюсь перечислять. но у каждого своя. интересен опыт каждого

разниц между инсталляциями и ворклоадом - много. но сам по себе кубернетес как хостинг для базы в вопросах _миграций_ вообще никакого влияния не вносит. ну или я умишком своим его не вижу, что тоже вполне вероятно.

кто как миграции баз проводит?

у нас в хелм чарте сервиса есть под с контейнером миграции, он запускает миграцию и уходит в слип 1

у нас в хелм чарте сервиса есть под с контейнером миграции, он запускает миграцию и уходит в слип 1

А что не initContainer?

у нас в хелм чарте сервиса есть под с контейнером миграции, он запускает миграцию и уходит в слип 1

все гасите перед апдейтом или какие-то практики blue-green deployment есть?

кто как миграции баз проводит?

На php phinx только знаю как отдельный инструмент, на go gorm. А так, в каждом фреймворке сейчас есть какой-то встроенный мигратор

Ну я в разрезе оркестровки спрашиваю

а он там есть?

А что не initContainer?

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

все гасите перед апдейтом или какие-то практики blue-green deployment есть?

гасим, блю грин в бэклоге

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

А зачем вообще гасить при миграции БД? Не лучше ли по голове бить за миграцию без обратной совместимости?

конечно лучше) но я так и ни разу не видел правильного blue-green deployment )

Там даже блу-грин не нужен, сначала мигрирует БД, потом выкладывается проект, если что просто откатывается обратно.

Оговорюсь, что у нас сейчас на кубер переведены только внутренние сервисы, которые не торчат вебом наружу. Принудительно не гасим, просто делаем хелм апгрейд и дальше кубер сам киляет и запускает в соответсвие с полиси. Миграции у нас не ломающие. Если ломающие то это вскрывается на деплоях до прода и стараемся делать чтоб не ломали. если никак то ручной сознательый деплой последовательный.

Еще в приложениях-клиентах ретраи на все внешние вызовы, поэтому даже если попадает деплоемый сервис, остальные переживут и продолжат.

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

скрипт миграции может уж понять, что миграция идет) у вас транзакции первоклассные под рукой)

Всем привет. Прошу пнуть в нужную сторону, не знаю с чего начать и что читать в сторону kubernetes. Есть 4 тачки на которых настроен к8с 1 мастер и 3 слейва (Bare Metal). Всё функционирует. Говорил с разрабами, они хотят, что бы всё у них поднималось автоматически (SaltStack, Ansible и т.п.). Может есть у кого, примеры/статейки/инструкции как собирать кластер на к8с для продакшн целей. Всем спасибо

Могу помочь с конфигами для паппета. Но к меня для другой версии паппет модуля, не для официальной.

Миша, иди спать

^ а это хороший паппет мастер, можете его мучить. >:-)