support external control plane in Kiali

[Xunzhuo]

Hi forks,
Let me introduce a scenario which is normal in multi-cluster and external control plane:

Like what picture shows, when istiod is deployed as an external control plane, the control plane and data plane are separated in different clusters.

Take Control Plane B as an example, we should notice that CRDs and resources in Data Plane are transported from APIServerB2 to APIServerB1, and Istiod are pointed to APIServerB1 to get resources.

But for kiali, it is a bit complex, if I want to connect kiali to APIServerB1 for getting resources, kiali can not interact with Istiod, and if I connect kiali with APIServer1, the default inCluster APIServer, kiali can talk to istiod but can not get resources from dataplane.

As what I found from reading codes of kiali:

https://github.com/kiali/kiali/blob/master/kubernetes/istio.go#L50 kiali will get debug msg from istiod pods like health check to istiod pod status and querying some info from istiod apis.

GetProxyStatus https://github.com/kiali/kiali/blob/master/kubernetes/istio.go#L139

GetRegistryServices https://github.com/kiali/kiali/blob/master/kubernetes/istio.go#L139

GetRegistryEndpoints https://github.com/kiali/kiali/blob/master/kubernetes/istio.go#L158

GetRegistryConfiguration https://github.com/kiali/kiali/blob/master/kubernetes/istio.go#L158

Also, when getting cluster info, kiali will get istiod deployment to get info:
https://github.com/kiali/kiali/blob/master/business/mesh.go#L191

I do not know if I missed something, the codes I placed here are shown that kiali is interacting with istiod.

When creating client in https://github.com/kiali/kiali/blob/master/kubernetes/client.go#L108

I believe that kiali can support to connect remote apiserver, but still assuming that Istiod and resources/CRDs are in the same cluster.

To solve this problem, I think we should support kiali talks to two apiserver at the same time when enable external_control_plane in config?

• The apiserver where kiali can get resources and CRDs in data plane
• The other one apiserver where kiali can talk to istiod.

Or any other ideas to solve this scenario confilcts with kiali?

Maybe find a way to let kiali interact with istiod less? For example, we choose to directly send request to istiod service not by getting pods from apiserver and forward ports? https://github.com/kiali/kiali/blob/master/kubernetes/istio.go#L50

[lucasponce]

Hi @Xunzhuo,
I haven't prepared a detailed answer as it's a complex topic, but I'd like to thank you for taking the time to prepare a diagram and the investigation of the existing features.

Just wanted to mention that Kiali needs to talk with the "istiod" component as it's required for the Istio Registry and Proxy status, so any solution in this direction would need to keep talking with those components from a feature perspective.

(I'll prepare a more detailed comment in next days, but I wanted to ack and thanks for opening the discussion).

[Xunzhuo]

Yes, let us open this discussion and collect more ideas on this topic.:)

[gyanesh-mishra]

@lucasponce @Xunzhuo Any updates on this?

[jmazzitelli]

For the record, @lucasponce is no longer actively developing within the Kiali project. Though he is around to answer questions dealing with past work, he is not involved in the current work that is being done.

As for this particular topic, the Kiali team is actively working on multi-cluster features (see the github issues - there are epics currently in progress), but AFAIK nothing involved with Kiali accessing remote control planes. Kiali is assumed to be running in the same cluster as where the control plane (e.g. istiod) is, and this will be true for the multi-cluster support as well.

[jmazzitelli]

Note that there is now a feature that "disables" Kiali's istiod access which is documented here. @josunect did that work recently (see this). But when you turn off Kiali's access to istiod, Kiali will lose some functionality. And I believe this does not help in the case when Kiali needs to talk to a remote cluster - that is part of the multi-cluster work I mentioned in the previous comment.