AS
раньше была проблема, нихрена не стартует пока сайдкар не стартанул, сейчас чет работает без этих проблем, ну и хрен с ним )
Size: a a a
2020 December 28
DS
раньше была проблема, нихрена не стартует пока сайдкар не стартанул, сейчас чет работает без этих проблем, ну и хрен с ним )
в целом можно выкрутиться имея какой-то отдельный сервис, который направляет твои запросы куда надо, пока не поднялся sidecar. А направлять эти запросы через iptables правило, которое добавляется на этапе initCointainers. А потом sidecar поднимается и делает всё как надо. Может быть они так и делают?
ИК
в целом можно выкрутиться имея какой-то отдельный сервис, который направляет твои запросы куда надо, пока не поднялся sidecar. А направлять эти запросы через iptables правило, которое добавляется на этапе initCointainers. А потом sidecar поднимается и делает всё как надо. Может быть они так и делают?
они предлагают либо не лезть в сеть из инит-контейнера, либо добавлять IP-адреса в исключения
DS
они предлагают либо не лезть в сеть из инит-контейнера, либо добавлять IP-адреса в исключения
хм. Жаль
2020 December 29
VB
Привет!
Собрал кластер на калике с включенным инкапсулированием IPIP, потом выключил.
Удалил обьекты калики, перезапустил ее вроде. Вижу конфигмапа изменилась,
tcpdump показывает чистый ipv4 между мастером и нодой.
Но в контейнеры продолжает пропихиваться туннель IPIP.
Как правильно перегружать калику при изменении манифеста ?
Докер почему продолджает юзать IPIP ?
Спасибо.
Собрал кластер на калике с включенным инкапсулированием IPIP, потом выключил.
Удалил обьекты калики, перезапустил ее вроде. Вижу конфигмапа изменилась,
tcpdump показывает чистый ipv4 между мастером и нодой.
Но в контейнеры продолжает пропихиваться туннель IPIP.
Как правильно перегружать калику при изменении манифеста ?
Докер почему продолджает юзать IPIP ?
Спасибо.
GG
Потому что нат ?
GG
Ты точно уверен, что это туннель ?
VB
ната пару ведер в iptables же должно быть
L
Тебе надо почитать доку калики в районе слова crosssubnet
VB
Ты точно уверен, что это туннель ?
VB
спасибо, гляну. сабнеты мне не надо пересекать
VB
Похоже не во всех местах (или не втом выключил)
calicoctl get ippool default-ipv4-ippool -o yam
calicoctl get ippool default-ipv4-ippool -o yam
a
Всем привет, есть вопрос про организацию деплоймента отдельных бранчей в Kubernetes с разным набором env-переменных для каждого бранча - с помощью чего и как вы это делаете?
Когда деплой идёт по тэгам или из одной ветки (master) - тут все просто, можно положить файл .env нужный в репу и менять при необходимости, а секреты создать заранее. А вот когда хочется в разных ветках тестить интеграцию с другими API зависимыми и тоже переключать на версию из бранча - тут встаёт вопрос управления этим добром - как это лучше провернуть? Как вы указываете такие эндпоинты под каждый бранч отдельно?
Когда деплой идёт по тэгам или из одной ветки (master) - тут все просто, можно положить файл .env нужный в репу и менять при необходимости, а секреты создать заранее. А вот когда хочется в разных ветках тестить интеграцию с другими API зависимыми и тоже переключать на версию из бранча - тут встаёт вопрос управления этим добром - как это лучше провернуть? Как вы указываете такие эндпоинты под каждый бранч отдельно?
как в итоге решили вопрос?
ps: всё обсуждение по этому вопросу прочитал, но вдруг удалось найти подходящий инструмент
ps: всё обсуждение по этому вопросу прочитал, но вдруг удалось найти подходящий инструмент
AL
как в итоге решили вопрос?
ps: всё обсуждение по этому вопросу прочитал, но вдруг удалось найти подходящий инструмент
ps: всё обсуждение по этому вопросу прочитал, но вдруг удалось найти подходящий инструмент
В итоге сделал так: в Helm передаётся название бранча на CI/CD pipeline. Это название используется в нескольких местах: 1)ингресс-контроллере для указания имени хоста: аля abc-123.service или master.service. 2) для префиксования всех сущностей кубера для этой ветки (abc-123-service, abc-123-deployment) 3) для указания пути в Vaulte - проверяю в CD есть ли конфиг специфичный для ветки, если есть - подключается он, иначе конфиг для мастера
AL
как в итоге решили вопрос?
ps: всё обсуждение по этому вопросу прочитал, но вдруг удалось найти подходящий инструмент
ps: всё обсуждение по этому вопросу прочитал, но вдруг удалось найти подходящий инструмент
Готового ничего не находилось, если вдруг кто найдёт или знает что-то, будет интересно тоже почитать. Пока же решение есть на хелме+Vaulte рабочее
a
В итоге сделал так: в Helm передаётся название бранча на CI/CD pipeline. Это название используется в нескольких местах: 1)ингресс-контроллере для указания имени хоста: аля abc-123.service или master.service. 2) для префиксования всех сущностей кубера для этой ветки (abc-123-service, abc-123-deployment) 3) для указания пути в Vaulte - проверяю в CD есть ли конфиг специфичный для ветки, если есть - подключается он, иначе конфиг для мастера
хмм... интересно
спасибо!
спасибо!
I
Я чет не понимаю, я что то делаю или это норма, кубеспрей должен ставить ingress-nginx controller же?
I
ingress_nginx_enabled: true стоит
L
ingress_nginx_enabled: true стоит
если стоит, то тогда поставит
I
но не поставилось