Why deploy mixer as two services: istio-policy and istio-telemtry?

1

Both istio-policy and istio-telemetry are based on mixer. And the two deployments run mixer almost in the same way /usr/local/bin/mixs server --address unix:///sock/mixer.socket --configStoreURL=k8s:// --configDefaultNamespace=istio-system --trace_zipkin_url=http://zipkin:9411/api/v1/spans. So I have two problems:

  1. How can the mixer process know what role should they run?
  2. Why deploy mixer as two deployment?
2
  1. The default installation comes as separate deployment with istio-policy and istio-telemetry for the following reasons (AFAIK):
  • Be sure that each API ( Check for policy and Report for Telemetry) will not have a side-effect on the other as it will the the case when both API will be running on the same container.
  • Provide the ability to scale up/down each components separately depending on the use case and real production circumstances. For example, define two different autscale strategy.
  • Provide the ability to change configuration separately. For example, define different service accounts, resources quota…

2.Istio uses service label to distinguished between the two services:
Policy pods are labeled with istio-mixer-type=policy and Telemetry with istio-mixer-type=telemetry.

kubectl get svc -n istio-system -o wide | grep mixer
istio-policy             ClusterIP      172.30.75.164    <none>        9091/TCP,15004/TCP,9093/TCP                                                                                               35d       istio-mixer-type=policy,istio=mixer
istio-telemetry          ClusterIP      172.30.123.110   <none>        9091/TCP,15004/TCP,9093/TCP,42422/TCP                                                                                     35d       istio-mixer-type=telemetry,istio=mixer

You could of course use the same instance for both Policy and Telemetry but personally I never tried that.

1 Like