Reflection/Introspection

[dtornow]

Hello,

Are there any discussions/plans to add an introspection/reflection API to SMI? Currently, Service Mesh Resources exist in an "implicit context" of a Service Mesh. To identify/pinpoint a Service Mesh Instance one has to "hunt for clues".

For example, Service Mesh Hub scans for K8s Resources:

• To detect an Istio instance (Specifically scanning for a Deployment with a Container with a name that includes "istiod")
• To detect a Linkerd instance (Specifically scanning for a Deployment with a Container with a name that includes "linkerd-io/controller")

Any thoughts on adding a Service Mesh Resource that should be created by the respective (SMI-compatible) Service Mesh Instance to make its presence discoverable?

This concept could further be extended to Services and Workloads

[grampelberg]

Hmm, what problem are you trying to solve?

[dtornow]

I would like to be able to discover Service Mesh Instances as well as the Services and Workloads the Service Mesh Instances know about on an SMI-level.

Service Mesh Hub implements Mesh, Service, and Workload discovery but it hunts for Service Mesh Implementation specific clues.

tl;dr

Problem: Discover Service Mesh Instances, Services, and Workloads via SMI

[grampelberg]

So, services and workloads are discoverable via. Kubernetes. Why would we need to see those through SMI?

I assume by "service mesh instances" you're interested in knowing what's been installed on the cluster?

[dtornow]

I assume by "service mesh instances" you're interested in knowing what's been installed on the cluster?

Yes. For example, I can install two Istio instances on the same cluster.

So, services and workloads are discoverable via. Kubernetes. Why would we need to see those through SMI?

Individual Service Mesh implementations have individual rules which K8s Services and K8s Workloads they consider.

For example, Istio may restrict the Namespace to discover both Services and Workloads.

For another example, Linkerd skips Workloads if unexpected errors occur.

tl;dr

A Service Mesh Implementations/Instances decides which Services and Workloads to include. Could we extend SMI to discover what the Service Mesh discovered?

[grampelberg]

Hmm, services are going to be extremely hard as a single service can have multiple meshes behind it. Workloads seem to make sense, I'm not sure what the right solution there is though.

I guess I don't have anything against some way to know what implementations are running globally on a cluster. We'll need to figure out what benefit it gets the implementers though so that it is valuable enough for them to implement.

Either way, I think we should flesh out a common status for the resources.

[dtornow]

Hmm, services are going to be extremely hard as a single service can have multiple meshes behind it.

At first glance, I don't expect much trouble here: I two Service Mesh Instances consider the same K8s Service, it'll still show up as two distinct Mesh Services belonging to two distinct Service Mesh Instances

We could take a page from Service Mesh Hub's playbook, SMH defines a Cluster, Mesh, MeshService and MeshWorkload CRD. Seems like a good starting point.

I see value add in both single as well as multi cluster scenarios, but yes, we do need to list the benefits.

Either way, I think we should flesh out a common status for the resources.

Didn't totally get that