Istio部署Envoy Filter后出现503服务不可用问题求助

Alright, let's tackle that 503 error you're facing when using Istio's envoy.ext_authz filter to call your external authorization service. Since direct curl requests to your authservice work fine, the issue is almost certainly related to how Envoy is configured to connect or interact with the service. Here's a step-by-step breakdown to resolve this:

1. Verify Your Envoy Filter Has the Correct Structure #

First, check if your Envoy Filter is properly structured to inject the ext_authz filter into the right place in Envoy's HTTP filter chain. Your current snippet is missing critical parts like the workloadSelector (to target the right pods) and configPatches (to position the filter correctly). A complete, valid Envoy Filter should look like this:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ext-authz-filter
  namespace: default # Match the namespace of your target service
spec:
  # Target the pods that need authorization checks
  workloadSelector:
    labels:
      app: your-target-app # Replace with your app's label
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        portNumber: 8080 # Match your service's port
        filterChain:
          filter:
            name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.ext_authz
        typed_config:
          "@type": type.googleapis.com/udpa.type.v1.TypedStruct
          type_url: type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
          value:
            http_service:
              server_uri:
                uri: http://authservice.default.svc.cluster.local:8080
                cluster: outbound|8080||authservice.default.svc.cluster.local
                timeout: 5s
              authorization_request:
                allowed_headers:
                  patterns:
                  - exact: "authorization"
            # Optional: Allow traffic if auth service is unreachable (for testing)
            # failure_mode_allow: false

2. Validate the Envoy Cluster Exists #

The cluster value in your filter must match exactly the cluster name Envoy uses to reach your authservice. To confirm this cluster exists:

• Run this command to list all clusters in your target pod's sidecar:

  istioctl pc clusters <your-target-pod-name> -n <your-namespace> | grep authservice
  

• If you don't see outbound|8080||authservice.default.svc.cluster.local in the output, double-check:
  • Your authservice's Kubernetes service name, namespace, and port (8080) are correct.
  • The DestinationRule for authservice (if any) doesn't have typos or invalid subsets.

3. Check Authservice Health and Reachability #

Even if curl works, Envoy might see the authservice as unhealthy:

• Verify your authservice has valid liveness/readiness probes configured. Istio will exclude unhealthy endpoints from its load balancing pool, causing 503s.
• From your target pod's sidecar container, test connectivity to the authservice directly:

  kubectl exec -it <your-target-pod-name> -c istio-proxy -n <your-namespace> -- curl http://authservice.default.svc.cluster.local:8080
  

  If this fails, you have a network policy or DNS issue blocking traffic between pods.

4. Inspect Envoy Logs for Detailed Errors #

The most reliable way to pinpoint the issue is to check the sidecar logs:

• Get the Istio proxy logs for your target pod:

  kubectl logs <your-target-pod-name> -c istio-proxy -n <your-namespace> | grep -i ext_authz
  

• Look for errors like:
  • cluster not found: Your cluster name is incorrect.
  • connection refused: Envoy can't reach the authservice's port.
  • timeout: The authservice is slow to respond (increase the timeout value in the filter if needed).

5. Adjust Failure Mode (Temporary Test) #

By default, envoy.ext_authz blocks traffic if it can't reach the authservice. To confirm this is the root cause, temporarily set failure_mode_allow: true in the filter's config. If the 503 goes away, you know the problem is Envoy's inability to connect to the authservice, and you can focus on fixing that connectivity issue.

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