Кастомайз всё же лучше как мне кажется, попробуйте!
- Делаете для ci шаблон делоя, сервиса, конфиг-мапы и тд. - Дальше в зафисимости от среды деплоя(можно папками разделить) главный(например dev). В нем описываете откуда секреты тянуть и тд. - Делаете папки с наименованиями стендов - Делаете там kustomization.yml и переопределяете то что нужно и отличается от dev
В целом по основному всё :)
Есть моменты, не спорю, когда helm может порешать. Но я их вижу только в рамках официальных чартов того же vault, например.
Предположу что должно всё должно работать с помощью ингресса который будет группу пользователей и/или региональную группу доставлять именно в под назначения. Иначе, как вы и сказали, нет гарантии что какая то группа будет попадать именно на 2.0
Ответа однозначного в силу отсутствия достаточного опыта по nginx не смогу дать, НО!
Во время настройки взаимосвязи nginx -> istio я получал ошибки от istio "426 Upgrade Required" . На просторах интернета нашел единственное подходящее объяснение где предлагалось добавлять proxy_cache_bypass $http_upgrade;
Однако сейчас, для того что бы сделать скрин ошибки и показать вам, я закоммитил эти строки в конфиге и не получил 426 ошибки.
Про server_name *.xxx.ru в таком ключе не экспериментировал. Если есть статейка на почитать буду благодарен.
> Istio сам разберётся какой запрос куда. Тут не очень понял. Как istio будет разбираться какой запрос куда если 3 инстанса kubernetes имеют не связныt с собой istio
Мы разрабатываем коробочное решение и в это коробочное решение входит вся инфраструктура (проще говоря мы передаём ВМ). По этому не трогаем "коробочную" инфру
Решение из статьи - быстрый выход из ситуации когда необходимо держать какое то множество пред-прод серверов в своей инфраструктуре с внешним доступом. Специфично но имеет место быть :)
Да, всё верно. Я как раз и описал в статье что это можно разделить. Как для быстрого решения конечно подойдет и монолитный конфиг, который в дальнейшем можно будет оптимизировать. В процессе эксплуатации такой системы я бы даже настоятельно советовал использовать подход с разделенными конфигами. Уже были прецеденты с участием неопытных админов когда были забыты закрывающие знаки.
"Но важно понимать что если у вас раздельные конфиги как в Ubuntu это так же будет работать. Главное поместить нужный код в нужные места ;)"
Кастомайз всё же лучше как мне кажется, попробуйте!
- Делаете для ci шаблон делоя, сервиса, конфиг-мапы и тд.
- Дальше в зафисимости от среды деплоя(можно папками разделить) главный(например dev). В нем описываете откуда секреты тянуть и тд.
- Делаете папки с наименованиями стендов
- Делаете там kustomization.yml и переопределяете то что нужно и отличается от dev
В целом по основному всё :)
Есть моменты, не спорю, когда helm может порешать. Но я их вижу только в рамках официальных чартов того же vault, например.
В описанном случае - нет.
Это три разных инстанса куба не связанные между собой ничем
Можно просто рестарт деплоймента сделать :)
И всё же интерсно. Как вы настроили unseal при рестарте? Использовали autounseal или отдельный под типа vault-unseal?
Нет, у нас вебсоккетов нет вообще нигде
Предположу что должно всё должно работать с помощью ингресса который будет группу пользователей и/или региональную группу доставлять именно в под назначения. Иначе, как вы и сказали, нет гарантии что какая то группа будет попадать именно на 2.0
Ответа однозначного в силу отсутствия достаточного опыта по nginx не смогу дать, НО!
Во время настройки взаимосвязи nginx -> istio я получал ошибки от istio "
426 Upgrade Required" . На просторах интернета нашел единственное подходящее объяснение где предлагалось добавлятьproxy_cache_bypass $http_upgrade;Однако сейчас, для того что бы сделать скрин ошибки и показать вам, я закоммитил эти строки в конфиге и не получил 426 ошибки.
Про server_name *.xxx.ru в таком ключе не экспериментировал. Если есть статейка на почитать буду благодарен.
> Istio сам разберётся какой запрос куда.
Тут не очень понял. Как istio будет разбираться какой запрос куда если 3 инстанса kubernetes имеют не связныt с собой istio
Объясню почему в этом случает так.
Мы разрабатываем коробочное решение и в это коробочное решение входит вся инфраструктура (проще говоря мы передаём ВМ). По этому не трогаем "коробочную" инфру
Решение из статьи - быстрый выход из ситуации когда необходимо держать какое то множество пред-прод серверов в своей инфраструктуре с внешним доступом. Специфично но имеет место быть :)
Да, всё верно. Я как раз и описал в статье что это можно разделить. Как для быстрого решения конечно подойдет и монолитный конфиг, который в дальнейшем можно будет оптимизировать.
В процессе эксплуатации такой системы я бы даже настоятельно советовал использовать подход с разделенными конфигами. Уже были прецеденты с участием неопытных админов когда были забыты закрывающие знаки.
"Но важно понимать что если у вас раздельные конфиги как в Ubuntu это так же будет работать. Главное поместить нужный код в нужные места ;)"