A
Прибей каждому сервис лейблами, заодно получишь айпишник пермантный)
Size: a a a
2019 May 03
A
Но вообще глянь может правило нейминга и на поды распространяется? Расскажешь
A
If you know that the plain MongoDB protocol is used, without encryption, you can specify the protocol as MONGOand let the Istio proxy produceMongoDB related statistics
A
Я бы наверно не рискнул запихивать базы в меш. Только описал бы подключение к ним через serviceentry
ZO
Я бы наверно не рискнул запихивать базы в меш. Только описал бы подключение к ним через serviceentry
Вот с этого момента подробнее. У меня сервисы вне меша, но внутри k8s
GG
Я бы наверно не рискнул запихивать базы в меш. Только описал бы подключение к ним через serviceentry
Сервис энтри - это подразумевается примитив куба или истио ?
ZO
Сервис энтри - это подразумевается примитив куба или истио ?
Это вроде истио часть. Но как работает пока не совсем понял
GG
И ещё вопрос - если я делаю цепочку ingress->alias service (чтоб прокинуть из оригинального неймспейса в istio-system)->istio-ingress-controller->pod как мне сделать так, чтоб хедер x-forwarded-for не терялся?
А зачем так сложно ?
GG
Почему не сразу в истио засунуть ?
GG
Да, если начисто делать - для каждого сервиса свой кастом гейтвей и балансер, но по сути только сервис уберётся
именно так
2019 May 17
ВС
Всем привет! Подскажите, может кто-то уже делал такое? Наша безопасность выдвинула требование, что Namespace'ы должны быть строго изолированы друг от друга, а трафик между ними должен ходить через шлюзы ingress/egress и при этом обязательно через mTLS с выписанными сторонним CA сертификатами. Добавлю ещё, что в каждом NameSpace у нас уже установлены отдельные ingress/egress.
2019 May 23
