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

Круто, спасибо.

Ну кстати nginx тоже может подобное вроде -  https://docs.nginx.com/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/
Только уточни, можно ли там несколько virtualserver для одного урла и есть ли там мерж конфигурации, в этом случае все будет сильно проще.

Хотя.. чет мне думается это специфично для платной версии, так что возможно не вариант. Траефик в бесплатной так умеет.

Около года +-. Это нововведения второй версии вроде. Я не трекал точно.

Выглядит не так класненько как у траефика, энинвей

Так, кажется, имеет смысл и на их меш посмотреть

А вот он платный:)

Трейсинг то мне всё равно нужен остаётся

Ох уж эти get pricing. А ты не знаешь хотя бы примерные цены?

Вообще там поддержка трейсинга в бесплатной версии прокси. И если всё будет через них ходить - то возможно мне и так хватит.

@Onlinehead это было продуктивно, спасибо.

Ну да, возможно. Istio просто позволит вообще все через себя протащить, то есть межсервисный трейсинг тоже будет. Вообще, можешь пойти и с Istio, только с декларативной схемой, когда приложение просто с собой притаскивает свой объект для роутинга. У тебя тогда ничего не потеряется, хелсчеки будут работать и сносить приложение будет просто - достаточно вынести все объекты включая объект для роутинга (virtual service). Тем более истио их умеет мержить, так что должно быть норм:
When a second and subsequent VirtualService for an existing host is applied, istio-pilot will merge the additional route rules into the existing configuration of the host. There are, however, several caveats with this feature that must be considered carefully when using it.

Although the order of evaluation for rules in any given source VirtualService will be retained, the cross-resource order is UNDEFINED. In other words, there is no guaranteed order of evaluation for rules across the fragment configurations, so it will only have predictable behavior if there are no conflicting rules or order dependency between rules across fragments.
There should only be one “catch-all” rule (i.e., a rule that matches any request path or header) in the fragments. All such “catch-all” rules will be moved to the end of the list in the merged configuration, but since they catch all requests, whichever is applied first will essentially override and disable any others.
A VirtualService can only be fragmented this way if it is bound to a gateway. Host merging is not supported in sidecars.
A DestinationRule can also be fragmented with similar merge semantic and restrictions.

There should only be one definition of any given subset across multiple destination rules for the same host. If there is more than one with the same name, the first definition is used and any following duplicates are discarded. No merging of subset content is supported.
There should only be one top-level trafficPolicy for the same host. When top-level traffic policies are defined in multiple destination rules, the first one will be used. Any following top-level trafficPolicy configuration is discarded.
Unlike virtual service merging, destination rule merging works in both sidecars and gateways.

Да пожалуйста. Надеюсь хоть одна команда в мире сделает меньше херни и будет меньше страдать вследствие нашего разговора:)

А что дает трейсинг в истио? Только видишь что откуда то куда то не дошел трафик? Или можно ему сыпать трейсы, как в Jaeger?

end-to-end спаны твоих реквестов. Сыпятся они по-прежнему в джагер

Ну не только в джагер, но в него тоже можно, да)

Основная плюшка для меня - это то, что не нужно инструментировать каждый свой сервис

Угу. По сути это сайд-эффект от того, что весь трафик ходит через энвой в роли прокси а энвой сам по себе дофига чего умеет, в том числе в трейсинг.