如何查询Istio元数据交换缓存数据并在Envoy访问日志中记录元数据

Great questions regarding Istio's metadata-exchange extension integrated into Envoy—let's tackle each one clearly:

1. 有没有办法列出该扩展缓存中的现有数据？ #

Absolutely! The metadata-exchange cache is local to each Envoy proxy instance (each Istio sidecar), so you need to query the specific proxy's admin interface. Here's how to do it:

• You can run the curl command directly against the sidecar container without entering it:

  kubectl exec <target-pod-name> -c istio-proxy -- curl -s localhost:15000/cache_dump
  

• To filter specifically for metadata-exchange entries (if jq is available in the proxy container), use this command to narrow down the output:

  kubectl exec <target-pod-name> -c istio-proxy -- curl -s localhost:15000/cache_dump | jq '.cache_entries[] | select(.cache_name == "metadata_exchange")'
  

This will show all peer metadata stored in the cache, including pod names, namespaces, and other attributes exchanged via the x-envoy-peer-metadata header.

2. Envoy访问日志格式支持的DYNAMIC_METADATA是否与metadata-exchange扩展相关？ #

Yes, they’re directly connected! When the metadata-exchange extension collects peer metadata via the x-envoy-peer-metadata header, it stores that data in Envoy’s dynamic metadata under the istio.metadata_exchange namespace.

The DYNAMIC_METADATA access log formatter is exactly how you reference this stored metadata in your logs. Any data cached by the metadata-exchange extension is accessible through this formatter by specifying the correct namespace and field path.

3. 如何查询该扩展中的元数据并将其记录到Envoy访问日志中，例如除DOWNSTREAM_REMOTE_ADDRESS外，输出下游Pod名称？ #

You can customize Istio’s access log format to include metadata from the metadata-exchange extension with these steps:

1. Confirm metadata-exchange is enabled (it’s default in recent Istio versions, so no extra setup is needed unless you explicitly disabled it).

2. Update Istio’s mesh configuration to modify the access log format. Edit the istio ConfigMap in the istio-system namespace with a snippet like this:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: istio
     namespace: istio-system
   data:
     mesh: |
       # Keep existing mesh config settings...
       accessLogFormat: |
         [%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
         %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
         "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%"
         "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" 
         "DownstreamPod: %DYNAMIC_METADATA(istio.metadata_exchange:downstream_pod_name)%"
   

   The key part is using %DYNAMIC_METADATA(istio.metadata_exchange:<field-name>)% to pull the desired metadata fields—you can also add downstream_namespace or other available fields here.

3. Apply the configuration:

   kubectl apply -f <your-config-file>.yaml
   

4. Roll out changes to ensure sidecars pick up the new log format:

   kubectl rollout restart deployment <your-application-deployment-name>
   

Once applied, your Envoy access logs will include the downstream pod name alongside your existing log fields.

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