The Service Mesh Interface was a CNCF specification defining a standard set of Kubernetes custom resources for traffic policy, telemetry and traffic management across service meshes. It is archived — the project stopped work rather than graduating.
Service Mesh Interface (SMI)
Service Mesh Interface (SMI) was an attempt to give Kubernetes a single, mesh-agnostic way to express traffic policy. Instead of learning Istio’s CRDs, then Linkerd’s, then Consul’s, an operator would write SMI resources and each mesh would implement them. It is archived, and that is the most useful thing about it as a catalog entry: it is a documented case of a standard that had a sensible design, a real sponsor and a CNCF home, and still did not take.
- Traffic specs, splits, targets and metrics - Four CRD groups covering routing, weighted shifting, access policy and a common telemetry surface.
- Kubernetes-native - Expressed as custom resources with OpenAPI schemas, so it was machine-readable and
kubectl-shaped from the start. - Implemented by several meshes - Linkerd, Open Service Mesh and others shipped adapters.
- Archived - The project is no longer maintained; the Gateway API absorbed much of the intent.
For anyone thinking about standards strategy, SMI is the cautionary half of the story. It was a lowest-common-denominator interface over implementations that were competing on exactly the features the interface could not express, so adopting it meant giving up the reason you picked your mesh. That is a different failure mode from the ones measured in the OpenAPI and AsyncAPI reports — not a spec nobody publishes, but a spec whose ceiling was set below what its adopters needed.
