Size: a a a

Kubernetes — русскоговорящее сообщество

2020 June 25

DS

Dmitry Sergeev in Kubernetes — русскоговорящее сообщество
Andrey Kartashov
ну у вас же есть Jenkins, который мониторит github - логичнее отслеживать эвенты пуллреквестов из него.
не умеет Jenkins при интеграции с github понимать что бранч был удален или смержен. Все равно костылить придется. У меня например в jenkins периодически задача выполняется, которая читстит k8s от веток которые были удалены. А человек вот целый оператор написал, почему бы и нет. А по ссылке что вы указали, нет вменяймых решений, сплошные костыли, которые ничем не лучше
источник

SM

Sarah Mia in Kubernetes — русскоговорящее сообщество
hello
источник

VR

Vadim Rutkovsky in Kubernetes — русскоговорящее сообщество
кстати в очередной раз рекламирую call for papers для минимитапа
https://hackmd.io/@vrutkovs/k8sru-meetup
источник

N

Nikita Massalitin in Kubernetes — русскоговорящее сообщество
есть какие-то рецепты как внести изменения в rules и dasboards, что приезжают с prometheus-operator?
источник

SK

Sasha Kryuchkova in Kubernetes — русскоговорящее сообщество
Михаил SinTeZoiD
Переслано от Anna Petrova
Всем привет!

В четверг 25 июня мы зовем вас присоединиться к Online Databases Meetup #2.

В программе Пётр Зайцев, CEO Percona, расскажет, как собрать гибридное облако на Kubernetes, которое может заменить DBaaS.

Для участия необходимо зарегистрироваться:
https://corp.mail.ru/ru/press/events/databases-2/
Кстати, про БД в кубере начинается онлайн: https://www.youtube.com/watch?v=-l911x0bLpw
источник

DS

Dmitry Sergeev in Kubernetes — русскоговорящее сообщество
Infatum
Блин, но все же терзаюсь надеждами не плодить деплойменты, а прикинуть как-то эти секреты каждому поду
ерундой занимаетесь. Деплоймент задуман под один под, который может скейлится. Зачем использовать инстурмент не по назначению. Если нужные разные поды, используйте разные деплойменты
источник

ST

Sergey Trapeznikov in Kubernetes — русскоговорящее сообщество
источник

I

Infatum in Kubernetes — русскоговорящее сообщество
Dmitry Sergeev
ерундой занимаетесь. Деплоймент задуман под один под, который может скейлится. Зачем использовать инстурмент не по назначению. Если нужные разные поды, используйте разные деплойменты
Уже использую, просто кастомеров куча
источник

AK

Andrey Kartashov in Kubernetes — русскоговорящее сообщество
Dmitry Sergeev
не умеет Jenkins при интеграции с github понимать что бранч был удален или смержен. Все равно костылить придется. У меня например в jenkins периодически задача выполняется, которая читстит k8s от веток которые были удалены. А человек вот целый оператор написал, почему бы и нет. А по ссылке что вы указали, нет вменяймых решений, сплошные костыли, которые ничем не лучше
можно сделать pipeline, который будет срабатывать как обычно, на пуш в мастер, но при этом опрашивать GitHub по API и смотреть недавно закрытые PR
источник

DS

Dmitry Sergeev in Kubernetes — русскоговорящее сообщество
Andrey Kartashov
можно сделать pipeline, который будет срабатывать как обычно, на пуш в мастер, но при этом опрашивать GitHub по API и смотреть недавно закрытые PR
можно что угодно накостылить. Например оператор
источник

DS

Dmitry Sergeev in Kubernetes — русскоговорящее сообщество
Infatum
Уже использую, просто кастомеров куча
у меня куча приложений в кластере, но мне почему-то не хочется их в один деплоймент пихать
источник

AK

Andrey Kartashov in Kubernetes — русскоговорящее сообщество
Dmitry Sergeev
можно что угодно накостылить. Например оператор
оператор у вас постоянно работать должен, а тут
1) не в кластере, а там где логически должно быть (CI/CD)
2) не нужно запихивать в кластер креды от гитхаба
3) работает по событию, а не периодически
4) не нужно запихивать в кластер дополнительный аккаунт с расширенными привилегиями для удаления ns
источник

AK

Andrey Kartashov in Kubernetes — русскоговорящее сообщество
вообще если делать по уму, то тут не оператор в куб, а плагин в дженкинс напрашивается
источник

DS

Dmitry Sergeev in Kubernetes — русскоговорящее сообщество
Andrey Kartashov
оператор у вас постоянно работать должен, а тут
1) не в кластере, а там где логически должно быть (CI/CD)
2) не нужно запихивать в кластер креды от гитхаба
3) работает по событию, а не периодически
4) не нужно запихивать в кластер дополнительный аккаунт с расширенными привилегиями для удаления ns
ну так, пуш в мастер раз в неделю, неделю не чистим куб? Такое себе приемущество. Лучше уж периодически проверять
источник

AK

Andrey Kartashov in Kubernetes — русскоговорящее сообщество
если дженкинс открыт наружу (что лично я бы не рекомендовал), то гитхаб может дёргать вебхуки дженкинса
источник

AK

Andrey Kartashov in Kubernetes — русскоговорящее сообщество
Dmitry Sergeev
ну так, пуш в мастер раз в неделю, неделю не чистим куб? Такое себе приемущество. Лучше уж периодически проверять
если пуш в мастер раз в неделю, значит мержат раз в неделю, значит чистить в течении недели нечего
источник

DS

Dmitry Sergeev in Kubernetes — русскоговорящее сообщество
Andrey Kartashov
если дженкинс открыт наружу (что лично я бы не рекомендовал), то гитхаб может дёргать вебхуки дженкинса
Jenkins умеет только запускать джобу по событию из github. А какое-то событие понимать не умеет. То есть тебе надо будет все это реализовывать самому
источник

DS

Dmitry Sergeev in Kubernetes — русскоговорящее сообщество
Andrey Kartashov
если пуш в мастер раз в неделю, значит мержат раз в неделю, значит чистить в течении недели нечего
сильно зависит от workflow, могут быть пре релизные ветки в которые мержатся фича-ветки (которые надо читсить)
источник

4

4c74356b41 in Kubernetes — русскоговорящее сообщество
Dmitry Sergeev
Jenkins умеет только запускать джобу по событию из github. А какое-то событие понимать не умеет. То есть тебе надо будет все это реализовывать самому
в смысле не умеет
источник

4

4c74356b41 in Kubernetes — русскоговорящее сообщество
вебхуки
источник