Istio v1.0服务网格发布，各特性已生产就绪

于7月23日在旧金山举行的 谷歌Cloud Next 2018大会 宣布了Istio v1.0服务网格的发布日程表。期间，我们看到，这个开源平台的 1.0正式版 旨在简化“已部署服务网络的创建，借助负载均衡、服务到服务的身份验证、监控等，而不需要修改任何服务代码”。该版本的主要新特性包括跨集群mesh支持、细粒度流量控制以及在一个mesh中增量推出mutual TLS的能力。

Istio是一个开源平台，可以有效 充当Envoy代理数据平面的控制平面 。虽然看上去是谷歌在主导这个项目，但许多其他的组织也在积极贡献，包括Lyft（ Envoy代理 的创建者）、IBM、Pivotal、思科、红帽和VMware。

Istio 控制平面的架构 包括用于控制和使用策略的Mixer、用于流量管理的Pilot和用于身份和证书管理的Citadel。通过使用 sidecar模式 ，Envoy数据平面和包含在mesh中的服务部署在一起。然后，所有服务到服务的通信都是通过Envoy sidecars拦截，控制平面指定的策略在这里执行，遥测数据在这里收集。

Istio架构（图片来自 Istio文档 ）

Istio 1.0的发布公告 指出，该版本比 之前的0.8版本 增加了多项新特性，此外，Istio团队已经“把许多已有的特性标记为Beta，表明它们已经生产就绪”（虽然在这个语境中，Twitter上的人们对于“beta”的意思还存在一些 争议 ）。目前，把Istio安装到Kubernetes集群的推荐方法是通过官方的 Helm chart ，虽然文档中还提供了 其他选项 。对于使用 Docker 和 HashiCorp Consul 的系统，也有安装指南（虽然未经测试，但也有一份HashiCorp Nomad安装指南）。

现在，多个Kubernetes集群可以 加到一个mesh中 了，这促成了“跨集群通信和一致性策略执行”。该特性处于Beta阶段，安装说明提醒说，“生产环境可能需要额外的步骤或者更复杂的部署选项。”还有一个打开的问题（ Istio issue #4822 ），重启控制平面集群中的任何Istio服务pod都会导致远程集群连接断开。

Networking API是本次发布中的另外一个Beta特性，它可以对通过mesh的流量进行细粒度的控制。文档指出，使用 Gateways 显式建模入口和出口关注点使操作人员可以“控制网络拓扑，满足网络边缘的安全访问要求”。

现在，mutual TLS（mTLS）可以在一个mesh中 增量推出 ，而不要求所有Istio托管的服务一次性升级。Istio身份验证策略提供了“PERMISSIVE”模式，可以克服有些服务没有Envoy sidecar支持mTLS通信的问题。一旦启用这个模式，服务就可以接收HTTP和mutual TLS流量了。迁移完成后，为了保证mesh中所有通信都使用TLS，需要删除PERMISSIVE模式。

Istio Mixer现在支持 进程外适配器 ，使得开发人员可以创建“gRPC适配器”或者“暴露gRPC接口的后端”，提供mixer功能，如日志、监控、定额、ACL控制等。发布说明指出，虽然进程外适配器特性目前还在积极开发中，但在未来的版本中，它会成为扩展Mixer的默认方式，简化适配器的构建。

控制服务访问的 身份验证策略 现在完全在Envoy本地判断，提升了性能和可靠性。虽然文档中没有详细说明，但据推测，这里对集中式的Mixer和每个服务的Envoy代理之间的数据最终一致性做了一些权衡。关于这一点，文档“ Mixer和SPOF迷思 ”提供了更多的见解。

发布说明还指出，整个Istio社区都在性能和可靠性上付出了巨大的努力，包括连续回归测试、大规模环境模拟及完成Bug修复。这些测试的其他结果会“在未来几周内详细分享”。

官方博客“ Istio 1.0发布 ”指出，多个组织在探索Istio的使用，包括eBay、Auto Trader UK、Descartes Labs、HP FitStation、JUSPAY、Namely、PubNub和Trulia。谷歌在公告中指出，“至少有十几家公司在生产环境中运行Istio，其中有几家在GCP上运行”，其中还援引了Auto Trader UK基础设施交付负责人 Karl Stoney 探讨Istio如何帮助他们加速向容器和公有云迁移的一段话：

Auto Trader UK不仅从私有云迁移到了公有云，还从虚拟机迁移到了Kubernetes。Istio提供的控制和可视化水平帮助我们极大降低了这项艰巨任务的风险。

在7月23日的谷歌Cloud Next大会上，谷歌还宣布了 Managed Istio的Alpha版本 。这是开源Istio的一个部署，作为云服务平台的一部分，可以在Kubernetes引擎集群上自动安装和升级。Pivotal也在他们的Cloud Foundry平台中 添加了Istio支持 ，也已提供mTLS支持，入口、额外的服务到服务支持以及应用程序安全策略也将很快提供。Pivotal Istio博客也谈到“重要的抽象”和“最好的技术是人看不到的技术”，并提醒开发人员，在构建旨在为交付业务价值提供支持的软件和平台时要避免弄错重点：

开发人员可能会很自然地尝试同时使用Istio和Kubernetes，但是，这种额外的操作负担是要付出代价的。除非你的核心业务是构建和出售平台，否则就是在浪费时间和金钱。你最优秀、最聪明的工程师应该增加独一无二的业务价值，而不是把开源组件连接起来。

还有其他一些公司在为Istio生态系统做贡献。可观测性提供商Datadog、SolarWinds、Sysdig、Google Stackdriver和Amazon CloudWatch已经编写了插件把Istio集成到他们的产品。Tigera、Cilium和Styra已经构建了策略执行和网络功能扩展。红帽还构建了一个基于Web的UI驱动工具 Kiali ，实现服务网格管理和可观测性。 Cloud Foundry 正基于Istio构建其下一代流量路由栈，最近宣布的Knative无服务器项目也在做同样的事，而Apigee宣布，他们计划在其 API管理解决方案 中使用它。

要了解有关 Istio 1.0的更多信息，请查看项目网站上的 发布说明 。

查看英文原文： Istio v1.0 Service Mesh Released with Features “Ready for Production Use”