Multicluster metrics

[dwradcliffe]

I’m testing the multicluster mesh (multiple control plane configuration) and noticed that requests leaving the origin cluster mesh are tagged as destination_workload:unknown and request entering the destination cluster mesh are tagged with source_workload:unknown. (As well as all the source/destination tags.)

Is there some way to get the real source/destination to pass across the gateway?

[douglas-reid]

Can you post which version of Istio you are testing with? And can you confirm the config for your kubernetesenv adapter?

[dwradcliffe]

Testing with 1.1.0-snapshot.6.

The kubernetesenv adapter is unchanged from the generated config:

apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  name: kubernetesenv
  namespace: istio-system
  labels:
    app: mixer
    chart: mixer
spec:
  compiledAdapter: kubernetesenv
  params: 

(Hopefully that’s what you were looking for?)

Also, cluster local services show up as expected in the tags.

[douglas-reid]

Can you try adding the multicluster config params to that spec?

istio/istio/blob/c7827fca38b5dd9b58550252883952c3f326c341/mixer/adapter/kubernetesenv/config/config.proto#L83

[douglas-reid]

Ah, wait… you specified multiple control plane configuration, corrrect?

If you aren’t configuring API Server access to all API Servers in your multi-cluster setup, then each adapter is not going to be able to lookup information on workloads outside of its own cluster. That means labels on pods, and deployment info, etc. I think we can improve on that in the future, but there isn’t a good way to easily workaround that at the moment.

[dwradcliffe]

@douglas-reid

you specified multiple control plane configuration, corrrect?

Yes.

@douglas-reid

If you aren’t configuring API Server access to all API Servers in your multi-cluster setup, then each adapter is not going to be able to lookup information on workloads outside of its own cluster. That means labels on pods, and deployment info, etc.

This is what I was guessing from understanding the architecture.

@douglas-reid

I think we can improve on that in the future, but there isn’t a good way to easily workaround that at the moment.

What’s the best way to move forward with this? I’d love to see this area improved. As it stands now, the multiple control plane configuration handles the communication ok but it’s missing a lot of what the mesh can provide.

[douglas-reid]

@dwradcliffe

What’s the best way to move forward with this? I’d love to see this area improved. As it stands now, the multiple control plane configuration handles the communication ok but it’s missing a lot of what the mesh can provide.

Raise an issue at the P&T WG meeting and follow-up with an issue in Github. Improving multi-cluster support, in all of its different flavors, is definitely an area that we’d like to focus on post-1.1. We should coordinate with the environments folks a bit too, to properly prioritize.