Istio项目在公开发布14个月后，今天迎来了1.0发布版本。然而，该服务网格管理平台仍然缺少云计算巨头AWS和Azure的正式支持，而且其他云服务供应商仍然在致力于解决测试和易用性等方面的挑战。
Istio项目成立于去年，目的是为开发者提供对微服务的可见性，而不需要去改变应用代码。Istio平台位于网络层，作为微服务管理和维护的基础，这就允许了对应用开发管理的解耦。
1.0发布版本构建于最近的0.8发布版本之上（跳过了0.9版本），更新包括改进的基于角色的访问控制（RBACs）、改进的传输层安全协议、组件稳定化、新增的测试组件和更广泛的社区测试。
“我们希望这个发布能够让社区感到惊喜，而且我们感觉自己做到了。”Red Hat公司Istio项目的产品经理Brian Harrington说道。
Harrington指出，他们关注的领域是如何减少将Istio注入一个正在运行的系统导致的性能影响。这非常重要，因为容器在不受运行依赖的阻碍时，能够提供最高的效率。
“我们过去几个月持续致力于这个领域。”他解释道，而且他坚定地认为已经达到了预期。
Istio最初在Google、IBM和Lyft的支持下发布。Lyft捐赠了Envoy代理，该项目能够让网络对应用透明。此后，很多其它的云服务供应商也开始支持Istio项目，包括Red Hat和Cisco。
AWS和Azure目前尚未正式将Istio绑定到他们的云平台，但是这两家公司也都慢慢投入到Google引领的Kubernetes潮流。
“我认为服务网格仍然处于被企业广泛接受的早期阶段，但是如果那些主流的云服务商接受它，情况就会好很多。”IT分析咨询师Daniel Conde说道。
来自ESG的资深云分析师Edwin Yuen补充道，他认为更多的支持会对上述情况有所帮助，但不是必需的。
“我认为有Google的背书，以及现有的合作伙伴的力量，将足够维持Istio向前发展。”Yuen在邮件中讲道，“当然，如果AWS和Azure正式支持Istio，特别是有计划地做出贡献，将会对社区有很大的好处。但是我认为这对Istio在未来能否被广泛接受不是必需的。”
尽管Istio目前已经宣布生产可用，但Harrington声称Red Hat可能会继续进行测试，以确保其更平稳地在生产中落地。“这是我们通常对所有项目都会做的。”他解释道。
Google上周上线了一个较完善的Istio版本，尝试让这个平台更易于被接受和使用。
1 Istio适用于哪里？
Harrington承认，关于Istio适用于哪些云原生场景的问题，仍然存在一些困惑。他引用了云原生计算基金会（CNCF）当前的项目页面，Linkerd和Envoy也被列为和Istio类似的服务网格平台。
Harrington解释道，上述的两个项目都提供了服务网格的功能，但是应用开发者和集群管理者仍然需要为单个代理实例的配置进行编排。
这就是Istio能够帮助改进的地方，因为它可以作为控制面来管理服务网格。它可以管理Envoy Sidecar（以sidecar的形式和应用程序运行于同一个pod中），而且可以集成容器编排系统，例如Kubernetes和Apache Mesos等平台。
“通过流量劫持，Istio能够将一个服务的不同组件自动连接。”Harrington补充道。
Linkerd社区增加了对集成Istio的支持，使用户可以使用Istio和Linkerd一起工作，将Istio作为Linkerd实例间的控制面。
2 与Knative的关联
Istio也被用作最近公布的Knative项目的一个组成部分。在上周旧金山召开的Next大会上，Google公布了Knative项目。Knative是一系列开源组件的集合，它能够构建和部署跨云服务商提供的基于容器的无服务器架构的应用。
Knative作为一个Istio和Kubernetes之上的抽象层运行。它使用Istio作为安全套接层（SSL）和传输层安全性协议（TLS），尽管目前Istio存在局限：只支持每个集群一个单独的证书。
Craig Box是Google的Kubernetes和Istio项目的一位领导人员，他声称Knative目前依赖于Istio，但是该项目组也在寻求开发者的意见，以决定是否应该减少对Istio的依赖。
“我们可以自己实现一部分Istio的功能，或者也可以重度依赖Istio。”Box本周在科罗拉多州波尔得的Google办公室的一次演讲中解释道，“我们在寻求对此问题的反馈。”
