Pull to refresh
45
-1
Андрей Половов @driusha

Пользователь

Send message

Так вот есть какое-то ограничение что если я один сервис добавляю в мешь, что другой сервис который не в мешь не сможет до него достучаться.

Такого ограничения нет. Если у вас не включен MutualTLS в режиме STRICT, то поды смогут друг с другом общаться.

Приходилось ли кому интегрировать мешь в существующую систему? Не верю что нет подхода по-проще.

Приходилось, всё просто, убеждаемся, что mtls в режиме PERMISSIVE (по умолчанию) или DISABLED и потихонечку, по очереди включаем.

Не понял проблемы. Это же прекрасно, что при удалении VS всё возвращается "как было" :).
Стандартная сеть сама по себе, а поверх неё работает истио. С точки зрения куба ничего не меняется, поды общаются друг с другом и всё.

Можно и зачастую это самый вменяемый способ собрать гео-распределённый кластер.
Настроить мультикластер (или федерацию) в ванильном истио достаточно сложно, но возможно. В энтерпрайз-версии Декхауса есть решение для автоматизации этого процесса.
https://deckhouse.ru/documentation/v1/modules/110-istio/#федерация-и-мультикластер

Очень сложно разобраться, почему Pod не может заскедулиться на ноду. В эвентах скедулер пишет про то, что на пятнадцати нодах не хватает CPU, хотя он бы на эти ноды и так не попал из-за nodeSelector.
В обозримой перспективе — нет. Мы только релизнулись, дайте оглядеться :).
> Подскажи, пожалуйста, я же верно понимаю, что с указанием automountServiceAccountToken mTLS в Istio работать не будет?
Не только mTLS, вообще сайдкар не запустится (я лично не тестил, но вот issue).
> У вас нет никакой информации о потреблении ресурсов istio-proxy во время нагрузочных тестов.
Не увидели ничего примечательного и непредсказуемого. Можно верить официальным замерам.
Из публично-понятных:

И ещё ряд улучшайзеров и примочек в основном для мониторинга, о которых в рамках одного камента не расскажешь.
Это оригинальное утверждение:
Kubernetes provides a mechanism called Network Policies that can be used to enforce layer-3 segmentation for applications that are deployed on the platform.
Понимая, что прикладная ценность задачи из сабжа может быть неочевидной, я начал статью с параграфа «зачем это может понадобиться?». Приведу пару кейсов:
  • Дать доступ на скачивание документа Х только Пете, остальным запретить. При этом контроль доступа лежит в недрах приложения, а не в конфигах AWS (работает принцип IaC).
  • У вас сайт, которому требуется ресайзить картинки и клеить вотермерки на лету, а оригиналы картинок лежат в закрытом S3 (вы не хотите, чтобы оригиналы достались кому-то на стороне). При этом вы не хотите получать большие счета за реквесты к S3 и кешируете картинки у себя.

Совершенно верно, если ваш бакет публичный, то можно не заморачиваться с аутентификацией и использовать любой CDN.
Если же перед вашим приложением стоит задача разграничить права доступа к файлам, например, «разрешить скачивать файлы только из локалки» или «разрешить Пете скачивать документ Х, а остальным запретить», то с кастомным прокси это сделать проще всего.
Также, помимо проксирования, nginx позволяет обрабатывать файлы на лету, например, ресайзить картинки или накладывать вотермарки. Соответственно, если вы не хотите, чтобы оригиналы картинок ушли в сеть, то решение из статьи вам поможет.

Information

Rating
Does not participate
Location
Россия
Works in
Registered
Activity