酷应用

Istio 1.0发布后，我们对项目核心成员做了一次采访

百家作者：聊聊架构 2018-09-10 09:21:04

作者 | Rags Srinivas

编辑 | 张卫滨

北京时间 7 月 31 日，Istio 正式发布了 1.0 版本，并表示已经可用于生产环境。该版本的主要新特性包括跨集群 mesh 支持、细粒度流量控制以及在一个 mesh 中增量推出 mutual TLS 的能力。

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

InfoQ 联系到了 IBM 的高级技术成员 Lin Sun，她同时还是 Istio 开源项目版本发布团队的参与者，讨论了 Istio 的总体情况以及 1.0 发布版本的具体情况。

Sun 介绍了 Istio 相关的多个话题，包括微服务、1.0 版本中的特性、服务网格（service mesh）、sidecar 代理、Istio 平台的路线图，以及它不仅能够与 Kubernetes 协作，还能与其他平台协作的能力。

InfoQ：Istio 是围绕服务网格构建的，你能为开发人员和架构师介绍一下这到底意味着什么吗？

Lin Sun：关于服务网格该如何连接、保护、控制和观察微服务的问题，我们给出的观点就是 Istio。微服务为新的云架构带来了巨大的收益，比如敏捷、速度以及灵活性。但是，它们的一个不足之处就是复杂性。

当用户从单体应用转移到容器和微服务架构时，它们要做的就是将这些大型的应用拆分为很多可移动的组成部分。同样的理念也可以用到基于微服务构建的新云应用上，唯一的区别在于这些不同的组成是完全从头开始构建的。但是，这种模型所面临的挑战依然是相同的。

同时管理这些不同的组成部分是很困难的，可能还会带来安全性方面的问题。Istio 是一种将控制权交还给开发人员的方法，能够确保微服务在处理故障的时候能够以一种预先定义的方式来进行相互之间的连接。这样的话，就能更容易地观察整个网络的微服务发生了什么状况，同时能够保护服务之间的通信，并确保策略得到了执行。

这不仅仅是 IBM 的观点。Istio 是一个开放的服务网格平台，目前贡献者超过了 200 人。Istio 是由 IBM、Google 和 Lyft 创建的，围绕着它成长起来了一个蓬勃发展的社区，包含其他的合作伙伴，如 Cisco、Redhat、Pivotal、Tigera 等。Istio 开放的架构和生态系统是它如此高效的原因之一，至于使用何种类型的服务，这里没有任何的厂商限制，它可以在任何云模型上运行，无论是公有云、私有云、内建云（on-premise）还是对它们进行组合均可以。

Istio 另外的一个好处就是它几乎不需要对应用程序进行任何修改。它并不关心你的服务是使用 Javscript、Go、Java、Python 还是其他语言编写的。一旦实现了这种方式，唯一需要的代码变更就是恰当地转发请求头信息，以便于利用分布式跟踪的功能。通用的任务都抽象出来了，比如负载均衡、路由、重试和 mTLS，并且它们会由 Istio 跨所有微服务以一致的方式进行解决，而不必关心它们是使用何种语言编写的。

InfoQ：你能简单描述 Istio 0.8 和 Istio 1.0 之间的差异吗，或者说 Istio 1.0 怎样在生产就绪方面做得更好？

Sun：从 Istio 0.8 到 1.0 版本，Istio 的很多重要特性从 Alpha 提升到了 Beta 阶段，或者从 Beta 提升到了 Stable 阶段。这些功能组成了 Istio 迄今最新和最稳定的版本，这是社区密切协作的结果，社区测试并强化了 Istio 对越来越庞大和复杂的微服务进行扩展和管理的功能。

例如，流量管理中的 HTTP1.1 / HTTP2 / gRPC / TCP 协议进入了 Stable 阶段。WebSockets 和 MongoDB 进入了 Beta 阶段，除此之外，还有流量控制、弹性、网关、TLS 终止以及网关中对 SNI 的支持。1.0 版本新增了对过滤器的支持，因此我们将该特性的状态设置为 Alpha。在开发很多特性的时候，IBM 将我们在为复杂企业迁移到云端所学习到的经验贡献了出来。与社区一道，我们为开发团队交付了将 Istio 用于生产环境时想要具备的功能，包括稳定性、安全性和控制。

你可能也注意到了，我们会首先将一个特性声明为 Alpha 状态，如果它在我们的测试、经验以及用户反馈中都相对稳定的话，我们会将其提升为 Beta 状态，然后会将其升级为 Stable 状态，该状态会包含多次的长期支持（Long Term Supported，LTS）版本发布。一旦某个特性达到 Beta 状态，我们就会建议用户使用它，但是需要当心一些。

随着 Istio 的很多特性达到 Stable 和 Beta 状态，Istio 1.0 就已经生产环境就绪了。我们的很多用户已经按照这种方式使用 Istio 了，比如 AutoTrader、Ebay 和 Namely 等等。在 IBM，我们内部在使用 Istio，我们的一些客户正在预生产环境（pre-production）使用 Istio。

Istio 1.0 其他很强大的特性包括：

虚拟服务中对 SNI 路由的支持，这样的话就允许用户基于 SNI 主机的值配置流量路由；
进程外的 mixer 适配器，允许开发人员编写 mixer 适配器时无需向核心 Istio mixer 组件提交 pull request (PR)。开发人员可以按照自己的进度构建和发布自己的 mixer 适配器；
在 envoy sidecar 代理中完成了很多的策略检查，提升了性能和可靠性。例如，在将 RBAC 规则用到你的微服务的时候，不再需要 mixer 了；
除了认证策略，还有一个新的“permissive”模型，能够更容易地转换为 mutual TLS。在转换过程中，你将会处于“permissive”模式，一旦转换完全完成，就能强制执行安全性。

InfoQ：sidecar 代理模式是 Istio 的核心理念。它主要是为了采集 pods 的遥测数据（telemetry）还是有更大的用途?

Sun：收集遥测数据仅仅是 sidecar 模式能够完成的众多任务之一。Envoy 是我们默认的代理实现，它会处理通用的任务，比如跨所有语言的负载均衡、路由以及重试一致性。

Envoy 基于目标端口捕获所有的传入流量以及所有的传出流量，并发送遥测数据给 Istio，这是 Mixer 的一个子组件。它还能够执行策略检查，例如限速、RBAC 或其他基于属性的策略检查，这些策略可以是本地的，也可以是使用 Istio-policy 的组件。最后，Envoy 还能处理网格内微服务之间的安全通信，这是通过检查身份、认证以及 mutual TLS 启用时的 key 来实现的。

InfoQ：Istio 并不仅仅适用于 Kubernetes，对吧？它能够与其他的平台协作吗，如 Cloud Foundry、OpenShift 等？

Sun：Istio 的创建和运行都是开放式的，这是 Istio 非常棒的一点。你几乎可以在任何地方运行 Istio，不管是 Kubernetes 集群、虚拟机还是在 Cloud Foundry 环境中。Istio 可以运行在任何通过了 Kubernetes v1.9 和 CNCF 一致性认证的环境中。我们可以在任何的 Kubernetes 1.9 集群中运行 Istio，包括在 IBM Cloud Kubernetes 服务中，以及其他的云平台中。

如果你看一下安装文档的话，我们提供了跨不同环境搭建 Istio 的指南。来自虚拟机的服务也可以作为 Istio 网格的一部分参与进来。

Istio 还嵌入到了 Cloud Foundry 中，Cloud Foundry 团队也在为 Istio 积极地做着贡献。

InfoQ：除了 bookinfo 样例之外，你还能为开发人员和架构师提供一些 Istio 的学习资源吗？

Sun：Bookinfo 是一个非常棒的样例，它是为云原生微服务编写的，在 istio.io 上，我们使用它来展现 Istio 的各种特性。另外，还有很多其他非常好的资源，包括：

在 Istio.io 上的各种 Istio 博客、任务和样例；
Katacoda 的 Istio 和 Kubernetes 起步教程；
IBM 扩展了 Kubernetes 的 Guestbook 样例，包含了如何将其与机器学习和其他服务进行集成；
IBM Cloud 同时还维护了一个 Istio 资源的页面。

其他的一些社区成员（比如 Redhat 和 Google）也发布了各种博客、任务和样例，能够帮助你们开始学习 Istio。

InfoQ：你能介绍一下 Istio 1.0 之后的路线图以及与 Kubernetes、Knative 和其他社区协作的计划吗？

Sun：从 IBM 的角度来说，我们一直关注让 Istio 在 IBM Cloud 中更易于搭建和使用。Istio 是 BM Cloud 战略的核心组件。除此之外，我们专注于跨集群提供联邦 Istio 服务网格功能，跨越公有的 IBM Cloud Kubernetes 服务和内建的 IBM Cloud 私有环境，提供统一的微服务体验。

从更广的社区视角来看，IBM 和 Istio 的贡献者会发布 1.0 和 1.1 的补丁，目标是让 Istio 更易于使用，从而扩大它的采用范围。这包括按需采用 Istio 某些组成部分的能力、继续改进其性能和扩展性并积极构建关键的特性，如路由 API 的改进、每个节点运行 mixer 的能力以及 Istio 跨多个环境的能力。我们还关注于不断增长的非平面网络（non-flat）下多集群的支持，在这种网络中，pods 不能跨多个 Kubernetes 集群进行路由。

Istio 在与 Kubernetes 社区密切合作，社区会继续选择 Kubernetes 作为其首选平台。我们很高兴地看到其他的开放项目，如 Knative 和 Fission 也在使用 Istio，它们具备让 Istio 未来更容易消费和使用的潜力。

TensorFlow、MXNet、Caffe2、PyTorch...... 深度学习框架多种多样，如何选择？我该用哪一个？已有的深度学习框架仍不满足我的需求，我该如何改造它来满足我的需求？这些框架如何与 Docker、Kubernetes 等相结合，打造深度学习大平台？

AICon 全球人工智能与机器学习技术大会上，老师木将作为出品人，与大家一起探讨 AI 工具和框架选型，以及 AI 平台搭建，企业如何基于已有大数据基础设施引入人工智能平台，有哪些难点，需要注意哪些事情等，还将讨论如何构建一个专门的人工智能团队，并为团队成员配备必要的知识和技能，以便让他们能够正确应用 AI 技术。

目前大会 6 折最低价火热售票进行中，感兴趣的小伙伴识别下图二维码或点击“阅读原文”即可报名，团购更优惠，详情咨询：18514549229（同微信），也欢迎留言发表更多关于 AI& 机器学习技术发展的看法。