基于Consul的Istio-Envoy配置咨询：手动服务网格搭建优化

Nice work getting the basic sidecar flow up with static Envoy configs! Integrating Consul here will let you move away from manual config updates and add dynamic service discovery, health-aware routing, and more to your service mesh. Here's a step-by-step breakdown to make this happen:

1. Deploy a Consul Cluster (Start with Single Node for Testing) #

First, add a Consul service to your Docker Compose setup. This will act as your service registry and dynamic config provider. Here's a minimal configuration snippet:

services:
  consul:
    image: consul:1.15.4
    command: agent -server -bootstrap-expect=1 -client=0.0.0.0 -ui
    ports:
      - "8500:8500" # HTTP UI/API port
      - "8600:8600/udp" # DNS resolution port
      - "8502:8502" # gRPC xDS port for Envoy
    volumes:
      - consul-data:/consul/data

Once up, you can verify the cluster via http://localhost:8500 to access the Consul UI.

2. Register ServiceA and ServiceB with Consul #

You need to make your services discoverable by Consul. The easiest way (for your current setup) is to add a self-registration step to each service's startup command in Docker Compose:

Example for ServiceB: #

serviceB:
  # Your existing service configuration here
  environment:
    - CONSUL_HTTP_ADDR=http://consul:8500
  command: >
    sh -c "
      # Register service with Consul before starting the app
      curl -X PUT -d '{
        \"ID\": \"serviceB-1\",
        \"Name\": \"serviceB\",
        \"Address\": \"serviceB\",
        \"Port\": 80,
        \"Check\": {
          \"HTTP\": \"http://serviceB:80/health\",
          \"Interval\": \"10s\"
        }
      }' http://consul:8500/v1/agent/service/register &&
      # Launch your actual service binary
      ./your-service-binary
    "

Repeat this pattern for ServiceA, ensuring both services show up as healthy in the Consul UI once deployed.

3. Update Envoy Sidecar Configs to Use Consul xDS #

Replace your static Envoy resources with dynamic configs pulled from Consul. This lets Envoy automatically pick up service address changes, health status, and routing rules.

Example ServiceA Envoy Config: #

static_resources:
  listeners:
    - address:
        socket_address:
          address: 0.0.0.0
          port_value: 80
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                codec_type: AUTO
                stat_prefix: ingress_http
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: serviceA
                      domains: ["*"]
                      routes:
                        - match:
                            prefix: "/"
                          route:
                            cluster: serviceB # Cluster will be fetched dynamically from Consul
                http_filters:
                  - name: envoy.filters.http.router
                    typed_config: {}
dynamic_resources:
  lds_config:
    resource_api_version: V3
    api_config_source:
      api_type: GRPC
      transport_api_version: V3
      grpc_services:
        - envoy_grpc:
            cluster_name: consul_xds
  cds_config:
    resource_api_version: V3
    api_config_source:
      api_type: GRPC
      transport_api_version: V3
      grpc_services:
        - envoy_grpc:
            cluster_name: consul_xds
clusters:
  - name: consul_xds
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: consul_xds
      endpoints:
        - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: consul
                    port_value: 8502

Key changes here:

• dynamic_resources configures Envoy to pull Listener Discovery Service (LDS) and Cluster Discovery Service (CDS) data from Consul via gRPC
• The consul_xds cluster points directly to Consul's xDS port
• Your original static cluster reference now pulls live service data from Consul

4. Define Routing Rules in Consul #

Instead of hardcoding routes in Envoy, you can define service-level routing rules directly in Consul. These rules are pushed to Envoy automatically via xDS.

Example Route for ServiceA → ServiceB: #

curl -X PUT -d '{
  "Kind": "service-router",
  "Name": "serviceB-router",
  "Service": "serviceA",
  "Routes": [
    {
      "Match": {
        "HTTP": {
          "PathPrefix": "/"
        }
      },
      "Destination": {
        "Service": "serviceB"
      }
    }
  ]
}' http://consul:8500/v1/config

This rule tells Consul to route all traffic coming into ServiceA to ServiceB—no need to update Envoy configs manually.

5. Validate the Flow #

1. Start all services (Consul + ServiceA + ServiceB + their Envoys)
2. Check the Consul UI to confirm both services are registered and passing health checks
3. Send a request to ServiceA as before—traffic should still route to ServiceB, but now Envoy is using dynamic data from Consul
4. Test resilience: Stop one instance of ServiceB, and confirm Envoy automatically stops sending traffic to the unhealthy instance

Quick Notes for Production #

• Deploy a multi-node Consul cluster for high availability
• Enable Consul ACLs to restrict service registration and config access
• Use Istio's official Envoy images to ensure compatibility with Consul's xDS implementation

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