Support Service Mesh Interface

[xxx7xxxx]

Background

Service Mesh Interface (SMI) is a Kubernetes-native specification, it's great to implement it to easily integrate with Kubernetes mesh ecosystem. But it seems to be under active discussion and development[1] even it has released v0.6.0.

[1] https://github.com/servicemeshinterface/smi-spec/issues

[localvar]

There seems a gap between the concepts of SMI and Easemesh. Take the TrafficTarget in SMI as an example:

kind: TrafficTarget
metadata:
  name: path-specific
  namespace: default
spec:
  destination:
    kind: ServiceAccount
    name: service-a
    namespace: default
  rules:
  - ...
  sources:
  - kind: ServiceAccount
    name: service-b
    namespace: default

This configuration means traffic from all pods which have ServiceAccount service-b could be sent to all pods which have ServiceAccount service-a.

It defines traffic routes and I think it should be mapped to sidecar egress configuration in Easemesh. However, there are two issues:

• ServiceAccount is a concept of K8s, and there's not a concept in Easemesh to map a ServiceAccount to.
• the source & destination of TrafficTarget are PODs, but in Easemesh, they are services (Easemesh service, not K8s service)

[zhao-kun]

There are some features we need to align with SMI. So we will implement these missing features, before that, we will suspend the development of SMI support