FYI: Adding Mesh UID for an initially-limited Telemetry use case

Environments
1

FYI: we are going to add a Mesh UID for the limited use case of aggregating telemetry for multiple meshes, and then being able to query it.

The initial implementation is to have a simple, opaque UID value. Future plans to support mesh federation, or to include mesh UID as a part of service/workload identity should be aware of this.

docs[dot]google[dot]com/document/d/1URXkFu2-cSg-g2fJin666M_QJvkumdn-C1NY9XkYgIM/edit

Sorry, my discuss account is too new and I can’t post a proper link. There’s a clickable link in the original proposal post:

2

There is a pr adding a uuid to the root ca used in each cluster, and we have a other cross-wg needs to identify the cluster.

It would be great to not add another uuid which will later require mappinga to the other uuids and further increase complexity…

3

Interesting. Would a multicluster setup always have the same root CA for all clusters? To aggregate telemetry we need to have the same UID for all clusters in a multicluster mesh, i.e. we’re not interested in identifying the cluster, but the mesh.

Is this the PR? https://github.com/istio/istio/pull/15859

4

How about a configurable name ? How do you even plan to sync up a uuid across multiple installs ?

Btw- keep in mind we plan to also support kustomize and simpler installs…

Having a mesh name - possibly corresponding to a domain name that is the base of all .svc. network names is already part of the networking setup for zero vpn.

Regarding certa - I would hope both the mesh name and the cluster name will be included in each cluster root or intermediate ca. We are planning to allow each cluster to have a separate root and merge them.

5

Update: Costin and I resolved this. The design doc is updated, and our conclusions are summarized at Proposal: adding Mesh UID for telemetry