What Is Service Mesh Interface (SMI) and How Does It Standardize Kubernetes Meshes?

Design Focus

Kubernetes service mesh standard interface.

Support for the most common mesh use cases.

Compatibility for new vendors to join.

Foster an innovative ecosystem that advances mesh technology.

Specification Content

Traffic Specification

SMI defines a limited set of objects that describe traffic routing for HTTP and TCP services. The specification deliberately includes only the core features needed for broad compatibility across mesh implementations.

apiVersion: specs.smi-spec.io/v1alpha1
kind: HTTPRouteGroup
metadata:
  name: the-routes
matches:
- name: metrics
  pathRegex: "/metrics"
  methods:
  - GET
- name: health
  pathRegex: "/ping"
  methods: ["*"]
---
apiVersion: specs.smi-spec.io/v1alpha1
kind: TCPRoute
metadata:
  name: tcp-route

The HTTP portion lets you define exact paths, methods, and later will add support for headers and gRPC, enabling automatic generation from OpenAPI specifications and serving as a foundation for advanced features such as access control and rate limiting.

Access Control

SMI provides a simple access‑control CRD that restricts which service accounts can call a given service.

kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha1
metadata:
  name: path-specific
  namespace: default
destination:
  kind: ServiceAccount
  name: service-a
  namespace: default
  port: 8080
specs:
- kind: HTTPRouteGroup
  name: the-routes
  matches:
    - metrics
sources:
- kind: ServiceAccount
  name: prometheus
  namespace: default

By combining sources and destination, the mesh can enforce intra‑mesh access policies, though it currently does not cover Ingress/Egress traffic.

Traffic Split

Built on the traffic‑specification objects, the split definition allows weighted routing between multiple backend services.

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: foobar-rollout
spec:
  service: foobar
  backends:
  - service: foobar-v1
    weight: 1
  - service: foobar-v2
    weight: 0m

Typical workflow:

Deploy foobar-v1 with labels app: foobar and version: v1.

Create a Service foobar whose selector is app: foobar.

Define backend foobar-v1 with selector app:foobar and version: v1.

Clients reach the service via the FQDN foobar.

Adjusting the weight values in the backends list changes the traffic distribution.

Traffic Monitoring

SMI defines two metric object types— resource (e.g., Pod, Namespace, Node) and edge (directional traffic)—to feed monitoring systems such as Prometheus.

apiVersion: metrics.smi-spec.io/v1alpha1
kind: TrafficMetrics
resource:
  name: foo-775b9cbd88-ntxsl
  namespace: foobar
  kind: Pod
edge:
  direction: to
  resource:
    name: baz-577db7d977-lsk2q
    namespace: foobar
    kind: Pod
timestamp: 2019-04-08T22:25:55Z
window: 30s
metrics:
- name: p99_response_latency
  unit: seconds
  value: 10m
- name: p90_response_latency
  unit: seconds
  value: 10m
- name: p50_response_latency
  unit: seconds
  value: 10m
- name: success_count
  value: 100
- name: failure_count
  value: 100

These metrics support not only Prometheus dashboards but also service topology visualizations, cluster‑resource monitoring, and can power canary‑release strategies.

Participating Vendors

Solo.io – offers a broad portfolio including SuperGloo, Service Mesh Hub, remote debugging, chaos engineering, unikernels, and a micro‑service gateway.

Mesery and Kinvolk – recently published performance comparisons of Istio vs. Linkerd.

Canonical – the parent company of Ubuntu.

Kubecost – provides cost analysis for Kubernetes clusters.

Solo.io’s Service Mesh Hub and SuperGloo have announced SMI support.

According to GitHub contribution data, the top two contributors to the SMI spec are Buoyant and HashiCorp.

Service Mesh’s broad potential, combined with Istio’s shortcomings, has attracted many competitors with strong demand or related expertise. In addition to public‑cloud solutions from AWS and F5, and software alternatives like Consul and Kong, aggressive cross‑cloud players such as Solo.io have entered the arena. While the mesh wave sweeps the industry, the battle continues; in 2019 Istio remains pivotal—unless it reaches top‑tier project standards, the mesh landscape will likely fragment into multi‑pole, niche deployments.