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”