не очень понимаю конечную цель

но теоретически можно выдать разрабам неймспейс и ограничить доступ через ABAC

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

Деплой ветки в неймспейс, туда применяется конфигурация из ветки. Но это пока теория, на на практике не дошло.

сикреты хранятся отдельно, в самом к8с, стандартными средствами подставляются в конфигурацию

можно все без кубернетеса сделать

зачем опять велосипед придумывать

нормально настроить дженкинс

или fabric8

или любой другой cicd

зачем разработчикам знать что то про кубернетис?

Затем, чтобы инфраструктуру тюнинговать

разработчикам?

это например как

они же не шарят

это работа админа или девопс

Значит никто ещё не делал деплой на поддомены feature-*.dev.blablabla.com + удаление их через Х дней отсутствия активности?

дженкинс все это делает

это должно решаться уровнем выше кубернетес

иначе разработчик на кошмарит такого, что век на разгребешь

ну либо у вас особенные разработчики

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

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

мы делаем

через хельм

хельм это менеджер пакетов. а остальное на чем реализовано?

грубо говоря, что вместо дженкинса и ему подобных

CI конечно есть

хельм может хорошо шаблонизировать для разных сред

а дальше уже ваши фантазии на CI и конфигурации чартов

кубернетес это бекенд для CI, эти все задачи - задачи CI

Ок, ещё раз попробую) Может я просто неправильно как-то описал кейс. Дано: 1. Есть набор реп, некоторые из них с одной веткой master, некоторые из них имеют ветки master, stage, develop. Некоторые ещё могут иметь ветки вида feature-425 (опционально). 2. Конфигурация K8s также в отдельной репе с ветками. 3. Некая абстрактная CI, которая может реагировать на git push. Задача: 1. При деплое новой ветки, по заданным правилам разворачивать новый namespace и экземпляр сервисов. Правила включают имя поддомена и, опционально, - время жизни при отсутствии доступа (5 дней для feature-веток или бесконечно) и HTTP Basic Auth. 2. Например, если пушим в git ветку feature-425, то проверяем по каждой репе её наличие. Если есть - разворачиваем исходники оттуда, если нет - то из ветки develop. 3. Также можем запушить ветку feature-425 в репу с конфигурацией кубера (или удалить её из репы). В этом случае он обновит для заданного домена конфиг. 4. Выкатка в production будет заключаться в git merge веток develop => stage и затем stage => master для всех реп.

^^ ну вот бери дженкинс и настраивай) все это уже давно придумано и работает

Есть пруф-ссылки?)

сами флоу придумываем, какие ссылки)

есть слайдов тонна, ссылки-то вряд-ли.

кубернетес тут вообще не причём, он тут как оркестратор виртуалок

на груви dsl наверно можно закодить обернув git ... в try .. except а в целом кубернетес тут не при делах

настройка сервиса это докер файл обычный

вот простой флоу - в Ci клонируешь код, клонируешь конфигурации для куба, если будет конфигурации в виде хельм чарта, то твои параметры для разных сред записываешь в соответсвующие файлы - Билдишь проект - пушишь в регистри - создаешь неймспейс например по номеру в трекере - поднимаешь окружение … - тригеришься на удалении ветки из VCS и удаляешь неймспейс

сам кубернетес настраивать - ну это точно не разработчиков задача

ну или так, да

да и неймспейсы тут имхо лишнее совсем

удобно

только права выдавать полные приходится выдавать для CI, что не хотелось бы, хотя надо попробовать их динамически создавать если РБАК заюзать

namespace нужен когда больше десятка юзеров и нет договорённости по неймингу

а когда один cicd то неймспейс лишняя сущность

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

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

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

Что и случается когда несколько веток могут быть сразу активны

ну то есть лень настроить дженкинс, настроим кубернетис)

несогласен

ну плодить сущности без необходимости тоже идея так себе.

потом когда-нибудь придётся удалять домен 15 уровня

Дженкинсово дело настроить 1 неймспейс, а какой именно это будет неймспейс - зависит от ветки. Пихать всё в один не вижу смысла

например в проекте, есть кластер редисов, мемкешей, можно будет создавать деплойменты и префиксировать его например по номеру таска. а можно запрефиксировать только главное приложение(по которому заходим в приложение), а остальные имена будут дефолтные redis-cluster, memcache-cluster и т.п.

конфиг для приложения тоже менять не придется

согласен, тут от ТЗ зависит многое

а в твоем варианте его генерить придется

Менять неймспейс проще, чем конфиги

CI в опенстек например, работает без неймспейсов, а там больше ста компонентов

@DenisIzmaylov на следующем митапе наши вроде хотели рассказать про хельм немного

всё разделение по логике на уровне дженкинса и его неймспейсов

100 компонентов * Х версий параллельно?

да

но у них ещё есть зуул некий

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

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

всё друг другу пишут тексты и CI неделю в коме

тикеты*

ну не делай создание на каждый коммит, привяжись к трекеру, как в статус “ААА” перевели, создавай окружение

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

ты в праве выбрать на что тригерить, а на что не нужно

это больше организационный вопрос

прелесть неймспейсов еще и в лимитировании ресурсов

а в проде тоже неймспейсы?

ну там их не так много как в QA, деве

по проектам или группе проектов

ну вот ещё одна будет проблема рано или поздно, CI зелёный, а в проде не пашет.

у нас в любом случае окружение отличатся будет, в бою много сервисов работают вне куба, так что идентичности мы в любом случае не добъемся