How come each proxy know where and how to access istio-policy?

Our company is using consul, and we want to integrate Istio with consul. The official documents has walkthroughs for deploying pilot. But now we are trying to deploy Mixer, whose service name is like “istio-policy.consul.service”.

And I don’t know how to configure those proxies to use the new mixer. I know that each proxy get xDS from pilot. But how can the proxy know which cluster/endpoint is for mixer? is this statically configured in the envoy.yaml?

May I ask what the reason is for deploying the policy service under a different name would be, out of curiosity?

I’ve never attempted such a thing and am worried that there might be a hidden gotcha that I’m not thinking of at the moment.

I believe what you are looking for (initially) is the istio configmap that is installed when you install Istio:

But, with that, I’d be concerned about some of the hardcoded stuff in the yamls for the policy service (that might lead to funky metrics, etc.:

You’ll also want to update other artifacts:

Finally, I think that some of the grafana dashboards may make assumptions about the service name in queries, etc.

Hope that helps,

1 Like

Thanks very much for your reply.
Actually we are deploying mixer in a non-kube env. And the only indicates how to deploy pilot with consul, but no mixer. And we want to verify if other istio components can work outside the kubernetes cluster

OK. Unfortunately, I don’t have much experience trying to run a full setup outside of kubernetes. At best, I can probably help troubleshoot when things go wrong.

Best of luck,

1 Like

There are two obstacles to running mixer outside of kubernetes, I believe:

  • connectivity: Mixer is just another service. It has been configured to use EDS till recently, so it can benefit from pilot’s discovery mechanisms instead of DNS. Recently, telemetry switched to strict DNS mode for session affinity.
  • metadata discovery: Mixer has “kubernetesenv” adapter that runs prior to all else, and auto-populates k8s metadata from some primary keys. Similar thing needs to exist for other environments. The mechanism is fairly generic, so almost all knowledge about k8s is concentrated in this adapter.


1 Like