Size: a a a

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

2020 December 21

ЕП

Евгений Павлов... in Kubernetes — русскоговорящее сообщество
Dmitry Sergeev
тащить в kubectl все варианты баш сниппетов которые могут тебе прийти в голову никто не будет. Но ты можешь написать плагин, там есть система плагинов для kubectl. Не вижу проблемы вобщем. В апстрим их никто не тащит и правильно делают
я не пытаюсь доказать что это срочно надо добавить, в чём твой посыл? Я просто говорю странно что для delete это есть, а для rollout нет, я смогу с этим жить
источник

DS

Dmitry Sergeev in Kubernetes — русскоговорящее сообщество
Евгений Павлов
я не пытаюсь доказать что это срочно надо добавить, в чём твой посыл? Я просто говорю странно что для delete это есть, а для rollout нет, я смогу с этим жить
хорошо
источник

VS

Vasilyev Sergey in Kubernetes — русскоговорящее сообщество
Есть приложение состоящее из 11 отдельных или не очень частей (сервисов) - 1 монолит и куча сервисов-сателитов.
Каждый сателит-сервис живет в своей репе, но при этом, каждая версия такого сателит-сервиса может "правильно" работать только с определенными версиями монолита и некоторых других сервисов.
вАпросы:
* Как это все релизить?
* Как в любую минуту понять где и какой сервис задепплоен(стейт-файл???)

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

Вот думаю, может уже есть что-то готовое?
источник

SM

Sergey Monakhov in Kubernetes — русскоговорящее сообщество
Vasilyev Sergey
Есть приложение состоящее из 11 отдельных или не очень частей (сервисов) - 1 монолит и куча сервисов-сателитов.
Каждый сателит-сервис живет в своей репе, но при этом, каждая версия такого сателит-сервиса может "правильно" работать только с определенными версиями монолита и некоторых других сервисов.
вАпросы:
* Как это все релизить?
* Как в любую минуту понять где и какой сервис задепплоен(стейт-файл???)

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

Вот думаю, может уже есть что-то готовое?
helmfile? или "патченный" хелмфайл https://github.com/zhilyaev/helmwave ,в argocd вроде тоже можно апп описать, но я не уверен
источник

AZ

Alexander Zaitsev in Kubernetes — русскоговорящее сообщество
Sergey Monakhov
helmfile? или "патченный" хелмфайл https://github.com/zhilyaev/helmwave ,в argocd вроде тоже можно апп описать, но я не уверен
когда я спрашивал нечто подобное здесь, мне тоже советовали argocd
источник

PK

Pavel Kolobaev in Kubernetes — русскоговорящее сообщество
мы юзаем submodule в гите
источник

СБ

Сергей Будников... in Kubernetes — русскоговорящее сообщество
Vasilyev Sergey
Есть приложение состоящее из 11 отдельных или не очень частей (сервисов) - 1 монолит и куча сервисов-сателитов.
Каждый сателит-сервис живет в своей репе, но при этом, каждая версия такого сателит-сервиса может "правильно" работать только с определенными версиями монолита и некоторых других сервисов.
вАпросы:
* Как это все релизить?
* Как в любую минуту понять где и какой сервис задепплоен(стейт-файл???)

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

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

GG

George Gaál in Kubernetes — русскоговорящее сообщество
Vasilyev Sergey
Есть приложение состоящее из 11 отдельных или не очень частей (сервисов) - 1 монолит и куча сервисов-сателитов.
Каждый сателит-сервис живет в своей репе, но при этом, каждая версия такого сателит-сервиса может "правильно" работать только с определенными версиями монолита и некоторых других сервисов.
вАпросы:
* Как это все релизить?
* Как в любую минуту понять где и какой сервис задепплоен(стейт-файл???)

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

Вот думаю, может уже есть что-то готовое?
1. Тебе уже сказали - где-то описать матрицу совместимости
2. Каталог сервисов + данные мониторинга + каждый сервис экспоузит  свою версию в мониторинг и в SD
источник

СБ

Сергей Будников... in Kubernetes — русскоговорящее сообщество
helm ls может легко показать какие appversion использовались при выкатке
А дальше всё эту цепочку helm можно упаковать в ArgoCD и дальше в одном месте в values-файле править целевые версии компонентов, после чего оно само будет всё катить в нужное состояние
источник

GG

George Gaál in Kubernetes — русскоговорящее сообщество
Фу, больше Хельм
источник

DS

Dmitry Sergeev in Kubernetes — русскоговорящее сообщество
Vasilyev Sergey
Есть приложение состоящее из 11 отдельных или не очень частей (сервисов) - 1 монолит и куча сервисов-сателитов.
Каждый сателит-сервис живет в своей репе, но при этом, каждая версия такого сателит-сервиса может "правильно" работать только с определенными версиями монолита и некоторых других сервисов.
вАпросы:
* Как это все релизить?
* Как в любую минуту понять где и какой сервис задепплоен(стейт-файл???)

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

Вот думаю, может уже есть что-то готовое?
а приложения чем щас описаны? Чартами? Если да то helmfile/helmweave
источник

AL

Aleksey Lazarev in Kubernetes — русскоговорящее сообщество
Andrey Panov
А как зайти браузером на ClusterIP сервиса? Я так понял что kubectl proxy только api сервер делает доступным!?
мне нужно просто по быстренькому посмотреть на опубликованный сервис, без публикования его в ингрессе.
Или можно как-то на Под браузером зайти? Браузером в данном случае это с моей локальной машины.
Можно и стем что ты написал
/v1/namespaces/NAMESPACE/services/http:SERVICENAME:SERVICEPORT/proxy/URLINPOD
источник

AL

Aleksey Lazarev in Kubernetes — русскоговорящее сообщество
Dmitry Sergeev
потому что не надо. штука нужна в основном для дебага вероятно. Используется редко
Да и не какой сложности не представляет однострочником на баш обвернуть как выше предложили
Можно вообще  kubectl rollout restart deployment - он все деплойменты рубанет)
источник

AL

Aleksey Lazarev in Kubernetes — русскоговорящее сообщество
Vasilyev Sergey
Есть приложение состоящее из 11 отдельных или не очень частей (сервисов) - 1 монолит и куча сервисов-сателитов.
Каждый сателит-сервис живет в своей репе, но при этом, каждая версия такого сателит-сервиса может "правильно" работать только с определенными версиями монолита и некоторых других сервисов.
вАпросы:
* Как это все релизить?
* Как в любую минуту понять где и какой сервис задепплоен(стейт-файл???)

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

Вот думаю, может уже есть что-то готовое?
Матрица совместимости - а еще лучше  тупо тегировать одинаково
источник

D

Diamon in Kubernetes — русскоговорящее сообщество
Sergey Monakhov
helmfile? или "патченный" хелмфайл https://github.com/zhilyaev/helmwave ,в argocd вроде тоже можно апп описать, но я не уверен
А  то думал когда всплывёт)
источник

AL

Aleksey Lazarev in Kubernetes — русскоговорящее сообщество
George Gaál
Фу, больше Хельм
А че это тебе хельм не нраится
источник

4

4c74356b41 in Kubernetes — русскоговорящее сообщество
а чем он нравится должен, блевотина
источник

SM

Sergey Monakhov in Kubernetes — русскоговорящее сообщество
Diamon
А  то думал когда всплывёт)
классная штука, спс
источник

AL

Aleksey Lazarev in Kubernetes — русскоговорящее сообщество
4c74356b41
а чем он нравится должен, блевотина
А что не блевотина
источник

AL

Aleksey Lazarev in Kubernetes — русскоговорящее сообщество
меня уже от чего угодно воротит
источник