Позволяет ли правила istio иметь пересечения внутри подмножеств (например, для одного регулярного выражения службы: ^(1|2|3|4|5)$ и для другого ^(1|3|5|7|9|)$)?
Согласно istio документация:
Правила маршрутизации оцениваются в последовательном порядке сверху вниз , причем первое правило в определении виртуальной службы имеет наивысший приоритет. В этом случае вы хотите, чтобы все, что не соответствует первому правилу маршрутизации, go назначению по умолчанию, указанному во втором правиле. Из-за этого второе правило не имеет условий соответствия и просто направляет traffi c в подмножество v3.
- route:
- destination:
host: reviews
subset: v3
Мы рекомендуем предоставить стандартное правило «без условий» или основанное на весе правило (описано ниже) аналогично последнему правилу в каждой виртуальной службе, чтобы гарантировать, что трафик c к виртуальной службе всегда имеет хотя бы один соответствующий маршрут.
Правила маршрутизации оцениваются по порядку. Таким образом, первое совпадение будет всегда выбрано.
regex: ^(1|2|3|9|10)$ закончится в subset: s-03
regex: ^(4|5|6|7|8|)$ закончится в subset: s-04
Нет совпадений в конечном итоге в subset: s-05, поскольку regex: ^(1|3|5|7|9|)$ уже покрыто subset: s-03 и subset: s-04.
Обратите внимание, что вы можете установить subset: s-05 в качестве совпадения по умолчанию с «без условий».
Однако Вы можете использовать «вес», чтобы распределить трафик c между соответствующими правилами.
И с небольшим творческим потенциалом (путем разделения пересекающихся групп на уникальные подмножества) Мы можем получить следующую конфигурацию:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-route
namespace: my-service
spec:
hosts:
- "service.cluster.local"
http:
- match:
- headers:
specific-id:
regex: ^(1|3|9)$
route:
- destination:
host: "service.cluster.local"
subset: s-03
weight: 50
- destination:
host: "service.cluster.local"
subset: s-05
weight: 50
- match:
- headers:
specific-id:
regex: ^(2|10)$
route:
- destination:
host: "service.cluster.local"
subset: s-03
- match:
- headers:
specific-id:
regex: ^(5|7)$
route:
- destination:
host: "service.cluster.local"
subset: s-04
weight: 50
- destination:
host: "service.cluster.local"
subset: s-05
weight: 50
- match:
- headers:
specific-id:
regex: ^(4|6|8|)$
route:
- destination:
host: "service.cluster.local"
subset: s-04
Таким образом Вы можете иметь:
subset: s-03, что соответствует regex: ^(1|3|9)$ OR ^(2|10)$
subset: s-04, что соответствует regex: ^(5|7)$ OR ^(4|6|8|)$
subset: s-05, что соответствует regex: ^(1|3|9)$ OR ^(5|7)$
Где traffi c для регулярного выражения:
^(1|3|9)$ делится равномерно между subset: s-03 и subset: s-05.
^(5|7)$ делится поровну между subset: s-04 и subset: s-05.
Когда после внедрения новой схемы с новыми правилами ее применяет istio? Гарантирует ли istio, что оно не будет применено (чтобы не удалять старые правила) до того, как все мои новые экземпляры будут готовы для traffi c?
Istio использует посланника для маршрутизации и Документация Envoy содержит следующее утверждение:
Обнаружение службы и динамическая конфигурация c: Envoy дополнительно использует многоуровневый набор dynamici c API конфигурации для централизованного управления. Слои предоставляют Посланнику динамические c обновления о: хостах внутри внутреннего кластера, самих внутренних кластерах, HTTP-маршрутизации, прослушивающих сокетах и материалах cryptographi c. Для более простого развертывания обнаружение хоста бэкэнда может быть выполнено через разрешение DNS (или даже полностью пропущено ), с дополнительными слоями, замененными на файлы конфигурации stati c.
Поэтому, как только объект istio изменяет конфигурацию посланника Dynami c, он вносит свои изменения в прокси посланника. Да, посланник позаботится о том, чтобы новые экземпляры были готовы к трафику c, и изящно истощит старый траффи c, прежде чем завершить работу.
Дополнительная информация: Конфигурация времени выполнения , Горячий перезапуск
Надеюсь, это поможет.