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.
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
- Spec v0.6.0
| Test # | Spec | Test Type | Test Description |
|---|---|---|---|
| TA - 1.1.1 | Traffic Access | Presence | Assert the presence of CRDs for Traffic Targets |
| TA - 1.1.2 | Traffic Access | Presence | Create service accounts for each service |
| TA - 1.2.3 | Traffic Access | Assertion | Assert that traffic is blocked by default |
| TA - 1.2.4 | Traffic Access | Target Access | Apply Traffic Target CRDs to enable traffic access by a service |
| TA - 1.2.5 | Traffic Access | Assertion | Assert that traffic is allowed for the said services |
| TA - 1.2.6 | Traffic Access | Target Block | Apply Traffic Target CRDs to block traffic to a service |
| TA - 1.2.7 | Traffic Access | Assertion | Assert that traffic is blocked for the said services |
| TS - 1.1.1 | Traffic Split | Presence | Asserts if the TrafficSplit CRD exists |
| TS - 1.1.2 | Traffic Split | Presence | Deploy the app and assert that it is deployed |
| TS - 1.2.3 | Traffic Split | Random Split | Custom 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.4 | Traffic Split | Single Split 1 | Configure a TrafficSplit CRD such that all traffic to `app-svc` is sent to only `app-b` and none to `app-c` |
| TS - 1.2.5 | Traffic Split | Assertion | Assert that traffic sent to `app-svc` is sent to only `app-b` |
| TS - 1.2.6 | Traffic Split | Single Split 2 | Configure a TrafficSplit CRD such that all traffic to `app-svc` is sent to only `app-c` and none to `app-b` |
| TS - 1.2.7 | Traffic Split | Assertion | Assert that traffic sent to `app-svc` is sent to only `app-c` |
| TS - 1.2.8 | Traffic Split | Partial Split 1 | Configure 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.9 | Traffic Split | Assertion | Assert that traffic sent to `app-svc` is sent to `app-b` (75%) and `app-c` (25%) |
| TS - 1.2.10 | Traffic Split | Partial Split 2 | Configure 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.11 | Traffic Split | Assertion | Assert that traffic sent to `app-svc` is sent to `app-c` (75%) and `app-b` (25%) |
| TSC - 1.1.1 | Traffic Spec | Presence | Assert that HTTPRouteGroup CRD exists |
| TSC - 1.1.2 | Traffic Spec | Presence | Create Service Account for each service |
| TSC - 1.2.3 | Traffic Spec | Target Spec 1 | Configure 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.4 | Traffic Spec | Assertion | Assert that traffic is is only allowed in ‘service-b:PORT/metrics’ port |
| TSC - 1.2.5 | Traffic Spec | Target Spec 2 | Configures 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.6 | Traffic Spec | Assertion | Assert that traffic with only GET HTTP Method is allowed from `service-a` to `service-b:PORT/*` |
