（译）大闹 KubeCon：Istio 已成 Cloud Native 新宠？

Posted 2021-04-13 伪架构师

这是非比寻常的一年。

过去几年里，Kubernetes 已经成为云计算领域中最重要的开源项目，2018 年的北美 Kubecon 吸引了 8000 多人聚集在西雅图，比去年的奥斯丁多出了一倍多。但是不少公司都推出了基于 Istio 的托管服务，容器编排项目在本次 KubeCon 上的热度大受影响。

随着 Kubernetes 的成熟，云原生的注意力开始转向了服务网格

Google 计划周二在 KubeCon 上宣布，服务网格技术的标志性产品——Istio，现已在谷歌云上提供了测试版的托管服务，VMware 和 F5 也在本周介绍了各自的 Istio 托管服务，波特兰的 Twistlock 在周一宣布，该公司的旗舰产品已经提供了对 Istio 的支持。

Istio 是一个由 Google、IBM 和 Lyft 合作开发的开源项目，为开发微服务应用)的公司提供帮助，来应对微服务架构所引发的网络复杂性问题。它能够控制构成应用的服务之间的流量，还增强了微服务的安全性和可见性。

微服务让公司可以将服务拆分成为更小的更专门的代码，这些拆分出来的单元能够根据需求进行独立的调整和更新。过去的单体应用的代码是一个大的整体，这种架构对很多类型的应来说都是好的；但如果按照现代分布式应用的要求进行快速更新的话，这种应用就存在很大风险了。

Jennifer Lin 是 Google 云的工程主管，她说“我们很多银行客户说，希望能够更快的开发移动版的银行应用，但也不想让安全和监控方面的功能滞后实现”。

去年十一月的一个采访中，Google 的 Urs Hölzle 说，Istio 可能会比 Kubernetes 本身更加重要。一个月后，奥斯丁的 KubeCon 2017 上就可以清晰的觉察到，在 Kubernetes 成为容器编排界的实施标准之后，服务网格正在成为下一个重要领域。

Lin 说：“从我们的客户和合作伙伴获知，正在开发的应用，90% 都是以容器化微服务的方式实现的”。

但是，尽管谷歌和 IBM 希望 Istio 能成为服务网格世界中的 Kubernetes，包括一些顶级公司在内的开发和运维人员都对 Istio 这种自上而下的方法提出了抱怨——又是一个事实标准。

Istio 是一个控制平面，它建立在数据面的基础之上——正如 Kubernetes 是 Docker 容器的控制面一样。Istio 和 Envoy 有着紧密的联系，这个来自 Lyft 的数据平面是一个 CNCF 成员项目，其中已经包含了一些用于管理服务网格的方法。

去年，两个前 Twitter 工程师建立了 Buoyant，这个创业公司的 Linkerd 数据平面也是 CNCF 成员，还是 KubeCon 的赞助商。Solo.io在本周破土而出，其 Gloo 产品获得了 Redpoint Ventures 和 True Ventures的 1100 万美元投资，该产品也是在 Envoy 的基础上运行的，用于协调微服务之间以及其它云原生工具之间的流量。

HashiCorp 的 Consul 产品也刚刚获得了一亿美元的投入，用于推进服务网格方面的技术工作。AWS 这只巨兽，也在 re:Invent 2018 会议上发布了基于 Envoy 的服务网格产品。

Istio 的优势是，它可以管理用户选择的任何数据平面用于完成微服务之间的连接，包括 Envoy、Linkerd 或者其它，对于使用 Kubernetes 进行容器管理的用户来说，Istio 是个非常友好的产品。然而在 KubeCon 的鸡尾酒会上给人一种感觉，多数企业计算客户仍然在追赶云计算时代，微服务还为时尚早。

正如 2015 年的 Kubernetes，像 Google 这样的大型网络运营商在提供分布式微服务时所面临的问题，并不是随处可见的，因此 Istio 的优势可能还要几年才能得以显现。但是如果更多公司开支考虑跨供应商的多云方案，Istio 可能因为在这一进程中起到重要作用而得以加速推广。

另外一个 AWS 或者微软这样的主流云供应商，如果提供了托管 Istio 服务来和 Google 对抗，就意味着服务网格时代真的到来了。这两个公有云巨头在 2017 年刚刚开始提供托管的 Kubernetes 服务，代表着这一项目已经打败众多对手，并且成为这方面的实际标准。

推广 Istio 是对公司推动的开源项目的市场能力的一个有趣测试，这一主题还会保持热度，如果可能的话，注册一个 IstioCon 商标吧。