# 大闹 KubeCon：Istio 已成 Cloud Native 新宠？

原文：[Crashing KubeCon: Has Istio become the new cloud-native darling?](https://www.geekwire.com/2018/kubecon-week-istio-become-new-cloud-native-darling/)

作者：[Tom Krazit](https://twitter.com/tomkrazit)

这是非比寻常的一年。

过去几年里，Kubernetes 已经成为云计算领域中最重要的开源项目，[2018 年的北美 Kubecon](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/) 吸引了 8000 多人聚集在西雅图，比去年的[奥斯丁](https://www.geekwire.com/2017/kubernetes-2018-going-gets-good-good-get-boring/)多出了一倍多。但是不少公司都推出了基于 Istio 的托管服务，容器编排项目在本次 [KubeCon](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/) 上的热度大受影响。

> [随着 Kubernetes 的成熟，云原生的注意力开始转向了服务网格](https://www.geekwire.com/2017/kubernetes-matures-cloud-native-movement-turns-attention-service-mesh/)

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

[Istio 是一个由 Google、IBM 和 Lyft 合作开发的开源项目](https://www.geekwire.com/2017/ibm-google-lyft-team-open-source-project-control-microservices/)，为开发[微服务应用]((https://www.geekwire.com/2018/google-doubles-service-mesh-hybrid-cloud-kicks-off-big-cloud-event/))的公司提供帮助，来应对微服务架构所引发的网络复杂性问题。它能够控制构成应用的服务之间的流量，还增强了微服务的安全性和可见性。

[微服务让公司可以将服务拆分](https://www.geekwire.com/2017/seattles-pitchbook-making-multiyear-infrastructure-shift-microservices-speed-kills/)成为更小的更专门的代码，这些拆分出来的单元能够根据需求进行独立的调整和更新。过去的单体应用的代码是一个大的整体，这种架构对很多类型的应来说都是好的；但如果按照现代分布式应用的要求进行快速更新的话，这种应用就存在很大风险了。

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

去年十一月的一个采访中，Google 的 [Urs Hölzle 说](https://www.geekwire.com/2017/googles-urs-holzle-still-thinks-cloud-revenue-will-catch-ad-revenue-maybe-not-2020/)，Istio 可能会比 Kubernetes 本身更加重要。一个月后，奥斯丁的 KubeCon 2017 上就可以清晰的觉察到，在 Kubernetes 成为容器编排界的实施标准之后，[服务网格正在成为下一个重要领域](https://www.geekwire.com/2017/kubernetes-matures-cloud-native-movement-turns-attention-service-mesh/)。

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

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

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

去年，两个前 Twitter 工程师建立了 Buoyant，这个创业公司的 Linkerd 数据平面也是 CNCF 成员，还是 KubeCon 的赞助商。[Solo.io](https://techcrunch.com/2018/12/10/solo-io-raises-11m-to-help-enterprises-adopt-cloud-native-technologies/)在本周破土而出，其 Gloo 产品获得了 Redpoint Ventures 和 True Ventures的 1100 万美元投资，该产品也是在 Envoy 的基础上运行的，用于协调微服务之间以及其它云原生工具之间的流量。

HashiCorp 的 Consul 产品也刚刚获得了一亿美元的投入，用于推进服务网格方面的技术工作。AWS 这只巨兽，也在 re:Invent 2018 会议上[发布了基于 Envoy 的服务网格产品](https://aws.amazon.com/blogs/compute/introducing-aws-app-mesh-service-mesh-for-microservices-on-aws/)。

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

正如 [2015 年的 Kubernetes](https://techcrunch.com/2015/07/21/as-kubernetes-hits-1-0-google-donates-technology-to-newly-formed-cloud-native-computing-foundation-with-ibm-intel-twitter-and-others/)，像 Google 这样的大型网络运营商在提供分布式微服务时所面临的问题，并不是随处可见的，因此 Istio 的优势可能还要几年才能得以显现。但是如果更多公司开支考虑[跨供应商的多云方案](https://www.geekwire.com/2018/travel-giant-sabre-bets-big-multicloud-signing-new-deal-microsoft-azure-weeks-new-deal-amazon-web-services/)，Istio 可能因为在这一进程中起到重要作用而得以加速推广。

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

推广 Istio 是对公司推动的开源项目的市场能力的一个有趣测试，[这一主题还会保持热度](https://www.geekwire.com/2018/open-source-companies-considering-closed-approach/)，如果可能的话，注册一个 IstioCon 商标吧。