istio vs服务网格接口
我会有一个概念上的问题。我无法弄清楚ISTIO和服务网格接口如何汇总在一起。
服务网格接口的目标是具有定义服务网格相关功能的标准方法（流量拆分，指标收集等）。为此，服务网格接口提供了不同的CRD（例如：Metrics.smi-spec.io）。
但是，ISTIO有自己的CRD和API扩展。
我有点困惑。 iStio是否在服务网格接口提供的API下使用API（例如Metrics.smi-spec.io）？还是这两个之间的联系是什么？
I would have a conceptual question. I can not figure it out how Istio and Service Mesh Interface come together.
Service Mesh Interface' goal is to have a standard way of defining service mesh related features (traffic split, metrics collection, etc..). To able to to this, Service Mesh Interface provides different CRDs (for example: metrics.smi-spec.io).
However, Istio has its own CRDs and API extensions.
I am confused a bit. Is Istio using under the hood the APIs (for example the metrics.smi-spec.io) provided by the Service Mesh Interface? Or what is the connection between these two?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
SMI将最小的规范作为服务网格的基础。但是尽管如此
通常有用的 由于
对SMI的兴趣也不同。
SMI是一个相对较新的规范，因此 Google＆amp; RH/IBM背后是Microsoft领导的一项倡议。 因此，
是的：根据SMI的说法（不过），
但是他们当前有自己的实现
VirtualServices，destinationrules。尽管如此，SMI还是提供了一个适配器（SMI-ADAPTER-ISTIO），以弥合其规范和ISTIOS实现之间的当前差距。
将所有内容压缩为几个单词：SMI希望成为（或已经是）CNI规格并标准化服务网格景观。 ISTIO是当前的事实上的标准，对此不满意。
SMI brings in a minimal set of specification as a foundation of a service mesh. But despite that they abstain from describing SMI as
Tools (which should be) implementing these specs (like console, linkerd, istio, aws-appmesh) are not limited to stay in these "boundaries". Every tool may also implement other specs and furthermore create its own CRDs.
Since SMI is a relatively new specification there is currently not enough impact. But there are also different interests against SMI. For this we have to know who is behind all these tools and specs.
Istio is the current de facto standard for service meshes with Google & RH/IBM behind it. SMI however is an initiative led by Microsoft. It is hardly surprising that vendors of a de facto tool are not happy with a socialization of the principles their tool uses, since it broadens the market and supports competition.
So yes and no: according to SMI istio (does not but) should implement their provided interfaces.
But currently they have their own implementations. E.g. for traffic access/split etc. (defined by SMI) istio has its own CRD-creations like
VirtualServices,DestinationRules.Nonetheless SMI provides an adapter (smi-adapter-istio) to bridge the current gap between their specification and istios implementation.
To compress all that into a few words: SMI wants to become (or already is) a CNI spec and standardize the service mesh landscape. Istio is the current de facto standard and is not happy with that.