我有一个概念性的问题。我不明白Istio和Service Mesh Interface是怎么结合在一起的。
服务网格接口的目标是有一个标准的方式来定义服务网格相关的功能(流量分割，指标收集等)。为了能够做到这一点，服务网格接口提供了不同的crd(例如:metrics.smi-spec.io)。
但是，Istio有自己的crd和API扩展。
我有点困惑。Istio是否在幕后使用服务网格接口提供的api(例如metrics.smi-spec.io) ?或者这两者之间有什么联系?
SMI引入了一组最小的规范，作为服务网格的基础。但尽管如此，他们还是避免将SMI描述为
"作为一个服务网格意味着什么程度，而不是一个一般有用的子集。">
工具(应该)实现这些规范(如console, link, istio, aws-appmesh)并不局限于这些"边界"。每个工具还可以实现其他规范，并进一步创建自己的crd。
由于SMI是一个相对较新的规范，因此目前没有足够的影响。但也有不同的利益反对SMI。为此，我们必须知道所有这些工具和规范的背后是谁。
Istio是Google &RH/IBM是幕后推手。然而，SMI是由微软领导的一项倡议。事实上的工具的供应商对他们的工具使用的原则的社会化并不满意，这是不足为奇的，因为它扩大了市场并支持了竞争。
所以是和否:根据SMI的规定(不但是)应该实现他们提供的接口。
但是目前它们都有自己的实现。例如，对于流量访问/分割等(由SMI定义)，istio有自己的crd创建，如VirtualServices,DestinationRules。
尽管如此，SMI还是提供了一个适配器(SMI -adapter-istio)来弥合它们的规范和istio实现之间的当前差距。
将所有这些压缩为几个字:SMI希望成为(或已经是)CNI规范并标准化服务网格景观。Istio是当前的事实标准，它对此并不满意。