如何不修改原有VirtualService路由规则实现所有流量覆盖转发至维护容器

Istio 的 VirtualService 路由优先级并非仅由创建时间决定，你可以通过显式配置规则优先级、无侵入覆盖原有路由，完全不需要修改存量业务配置。以下是实测可行的方案，优先推荐第一种：

方案1：高优先级专属维护VirtualService（最优方案） #

VirtualService 支持通过 priority 字段显式指定规则优先级，数值越小优先级越高，默认创建的VirtualService优先级为100。你只需要单独创建一个维护专用的VirtualService，设置优先级为0（远高于默认值），匹配全路径流量路由到维护nginx服务即可。维护结束后直接删除该VirtualService，流量自动恢复到原有规则，全程无需修改任何存量业务配置。
参考配置示例：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: maintenance-override
spec:
  hosts:
  - "你的业务对外域名" # 需和原有业务VirtualService的hosts完全一致
  priority: 0
  http:
  - match:
    - uri:
        prefix: "/"
    route:
    - destination:
        host: <维护nginx的ClusterIP服务名>
        port:
          number: 80

操作流程：

• 开启维护：执行 kubectl apply -f maintenance-override.yaml
• 结束维护：执行 kubectl delete virtualservice maintenance-override

方案2：Gateway绑定切换 #

如果不想新增VirtualService，也可以临时修改对外Gateway的关联规则：

1. 先把维护专用的VirtualService绑定到对外Gateway
2. 解绑原有业务VirtualService和Gateway的关联
   维护结束后恢复绑定关系即可，该方案也不会修改原有路由的匹配规则，仅调整Gateway的绑定关系。

方案3：DestinationRule权重切换 #

如果允许对存量配置做临时修改，可以给业务服务对应的DestinationRule新增维护子集，临时把原有业务VirtualService的路由权重100%切换到维护子集，维护结束后切回即可。该方案需要修改存量DestinationRule，仅适用于你能接受改动原有配置的场景。

验证建议 #

配置完维护规则后可以先执行curl测试业务域名，确认返回的是维护页面后再正式开启维护窗口，避免规则不生效影响用户访问。

内容的提问来源于stack exchange，提问作者Russ