如何在Istio入口网关同一端口80部署多Web应用并支持根路径访问

Got it, let's tackle this problem. The core issue here is that some of your apps only accept traffic on the root path /, but you can't use Host headers to distinguish them since they're browser-accessible. Here's the most straightforward solution that works without requiring any client-side changes:

Use Path Prefixes + URI Rewriting #

The idea is to map each app to a unique path prefix on the ingress gateway, then configure Istio to rewrite that prefix to the root path / before forwarding traffic to the target service. This way, users just need to visit ingress-gateway-id:80/app2/ (for example) to reach app2's root path, no Host header needed.

Example Virtual Service for app2 (Root-Path Only App) #

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: app2-vs
spec:
  gateways:
    - your-ingress-gateway-name  # Replace with your actual gateway name
  hosts:
    - "*"  # Matches all incoming requests since Host headers aren't usable
  http:
    - match:
        # Catch both the exact /app2 and the prefix /app2/ to cover all user access patterns
        - uri:
            exact: /app2
        - uri:
            prefix: /app2/
      rewrite:
        uri: "/"  # Rewrite the request path to root before sending to app2-service
      route:
        - destination:
            host: app2-service  # Your target service name
            port:
              number: 80  # Service's listening port

How This Works #

1. When a user visits ingress-gateway-id:80/app2 or ingress-gateway-id:80/app2/, Istio matches the URI rules in the Virtual Service.
2. The rewrite rule strips the /app2 prefix and sends the request as / to app2-service, which satisfies its requirement for root-path access.
3. For apps that handle non-root paths (like app1), you can keep your existing Virtual Service configuration—no changes needed there.

Alternative Options (If Path Prefixes Aren't Ideal) #

If for some reason you can't use path prefixes, you can route based on other HTTP request attributes:

• Query Parameters: Match requests with a specific query param (e.g., ?app=app2) and route to the corresponding service. This is less user-friendly but works if path prefixes aren't an option.
• Cookie Values: If users can be assigned a cookie (e.g., via an initial landing page), you can route based on cookie values. This requires extra setup but is useful for segmented user access.

Path prefixes are almost always the best choice here though—they're intuitive for users and require minimal configuration overhead.

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