Conformance and Diagnostics

Service Mesh Interface

Integrate and wrap your operational processes around a service mesh without fear of lock-in. SMI provides a standard interface for service meshes on Kubernetes and a basic feature set for the most common service mesh use cases.

Meshery is the official SMI Conformance Validator. Use Meshery's diagnostic tool to verify that your service mesh's behavior in an accessible and non-destructive manner.

SMI Table

Purpose and Overview

The scope of this initiative includes all service mesh projects participating in the Service Mesh Interface specification. It’s important to acknowledge that conformance consists of both capabilities and compliance status.

Project Goals

Provide users with a compatibility matrix identifying the SMI features that are supported per service mesh.

An easy-to-use, service mesh and SMI-specific tool to give service mesh projects and users a suite of repeatable conformance tests.

Project Objectives

Define what it means to be in conformance with the SMI specifications.

Define a set of conformance tests and what behavior is expected of a conforming service mesh implementation.

Built into each participating service mesh project’s release tooling.

Validating Conformance

Conformance to SMI specifications will be done through use of a service mesh’s workload. A sample application is used as the workload to test. To facilitate a common set of tests, a sample application has been developed for purposes of providing a consistent workload to apply SMI specs against. A deployment of the Learn Layer5 sample application being fitted to each service mesh.

Conformance Tests

for service mesh interoperability


Test #SpecTest TypeTest Description
TA - 1.1.1Traffic AccessPresenceAssert the presence of CRDs for Traffic Targets
TA - 1.1.2Traffic AccessPresence Create service accounts for each service
TA - 1.2.3Traffic AccessAssertionAssert that traffic is blocked by default
TA - 1.2.4Traffic AccessTarget AccessApply Traffic Target CRDs to enable traffic access by a service
TA - 1.2.5Traffic AccessAssertionAssert that traffic is allowed for the said services
TA - 1.2.6Traffic AccessTarget BlockApply Traffic Target CRDs to block traffic to a service
TA - 1.2.7Traffic AccessAssertionAssert that traffic is blocked for the said services
TS - 1.1.1Traffic SplitPresence Asserts if the TrafficSplit CRD exists
TS - 1.1.2Traffic SplitPresenceDeploy the app and assert that it is deployed
TS - 1.2.3Traffic SplitRandom SplitCustom test which verifies that if in default scenario the traffic to app-svc is split randomly between app-b and app-c
TS - 1.2.4Traffic SplitSingle Split 1Configure a TrafficSplit CRD such that all traffic to `app-svc` is sent to only `app-b` and none to `app-c`
TS - 1.2.5Traffic SplitAssertion Assert that traffic sent to `app-svc` is sent to only `app-b`
TS - 1.2.6Traffic SplitSingle Split 2Configure a TrafficSplit CRD such that all traffic to `app-svc` is sent to only `app-c` and none to `app-b`
TS - 1.2.7Traffic SplitAssertionAssert that traffic sent to `app-svc` is sent to only `app-c`
TS - 1.2.8Traffic SplitPartial Split 1Configure a TrafficSplit CRD such that all traffic to `app-svc` is split between the two such that `app-b` gets more traffic (75%) than `app-c` (25%)
TS - 1.2.9Traffic SplitAssertionAssert that traffic sent to `app-svc` is sent to `app-b` (75%) and `app-c` (25%)
TS - 1.2.10Traffic SplitPartial Split 2Configure a TrafficSplit CRD such that all traffic to `app-svc` is split between the two such that `app-c` gets more traffic (75%) than `app-b` (25%)
TS - 1.2.11Traffic SplitAssertionAssert that traffic sent to `app-svc` is sent to `app-c` (75%) and `app-b` (25%)
TSC - 1.1.1Traffic SpecPresenceAssert that HTTPRouteGroup CRD exists
TSC - 1.1.2Traffic SpecPresenceCreate Service Account for each service
TSC - 1.2.3Traffic SpecTarget Spec 1Configure HTTPRouteGroup such that traffic from `service-a` to only `service-b:PORT/metrics` (all HTTP methods) is allowed and all other requests are denied
TSC - 1.2.4Traffic SpecAssertionAssert that traffic is is only allowed in ‘service-b:PORT/metrics’ port
TSC - 1.2.5Traffic SpecTarget Spec 2Configures the above created HTTPRouteGroup such that traffic from `service-a` to `service-b:PORT/*` (only GET HTTP Method) is allowed and all other requests are denied
TSC - 1.2.6Traffic SpecAssertionAssert that traffic with only GET HTTP Method is allowed from `service-a` to `service-b:PORT/*`
Service Mesh Landscape

Checkout the current status of the support for SMI Conformance Tests of all service meshes in our landscape page.

MeshMap is here!

Discover a catalog of best practice cloud native patterns.

Layer5, the cloud native management company

An empowerer of engineers, Layer5 helps you extract more value from your infrastructure. Creator and maintainer of cloud native standards. Maker of Meshery, the cloud native manager.