转载

云容器云引擎：容器化微服务，Istio占C位出道

在精彩的软件容器世界中，当新项目涌现并解决你认为早已解决的问题时，这感觉就像地面在你的脚下不断地移动。在许多情况下，这些问题很久以前被解决，但现在的云原生架构正在推动着更大规模的应用程序部署，这就需要新的工具和方法。

微服务就是一个很好地例子。在此模型下，典型的应用程序或服务将被分解成可以独立部署的功能模块，这些功能模块能彼此分开扩展和维护，并且链接在一起时可以提供应用或服务的全部功能。

当使用容器来开发微服务时，后一块可能是棘手的。当它们可能散布在服务器节点集群中时，并且在它们的实例不断弹出时，随后被更新版本替换而下线时，该如何将所有组件部分链接起来？在面向服务的架构中（SOA），微服务可以被视为进化的继承者，这种任务类似于企业服务总线（EBS）所处理的任务，所以需要的是一种基于云原生版本的EBS。

这是一个相对新的开源项目Istio旨在填补的工作。它被正式的描述为服务网格，因为它的其中一部分分布在由容器管理的基础架构中，并且它开始着手于满足服务发现，负载均衡，消息路由，遥测和监控，以及必不可少的安全等需求。

Istio源自于谷歌和IBM之间的合作，实际上包含了一些现有的组件，特别是由乘车服务公司Lyft开发的组件。它以某一种形式存在了至少一年，最终在七月底达到1.0版本的里程碑，这意味着它终于被认为足够成熟，可以作为生产的一部分基础架构运作。

IBM研究员兼IBM云计算首席技术官Jason McGee告诉The Next Platform，云原生态系统已基本确定容器作为打包和运行的核心结构，而Kubernetes则作为管理容器的编排系统。但McGee解释说，还有第三块拼图还没有落地，这就是Istio的设计点。

“你如何管理在容器平台上运行的应用程序或服务之间的交互？”McGee问道。 “如果你正在构建微服务，或者你有一组应用程序，那么应用程序之间的通信会产生一大堆有趣的问题。你如何了解谁与谁之间进行对话，如何收集有关应用程序之间通信的数据，如何保护控制哪些服务可以相互通信的通信，以及如何使应用程序安全，尤其是我们今天拥有更多种的动态或分布式架构应用程序，你在公有云的何处能安放高质量的组件？”

McGee说他在IBM的团队几年前已经开始研究这个问题了，当时他遇到了谷歌的同行并发现他们正走在同一条道路上，但IBM主要关注流量路由，版本控制和A/B测试方面，谷歌则专注于安全和遥测。两家公司决定合并各自的努力，结果就是Istio的产生。

Istio由以下组件组成：

Envoy，被描述为边车代理，它作为代理部署在每个微服务实例旁边;

Mixer，它是一个核心组件，用于通过Envoy代理实施策略，并从中收集遥测指标;

Pilot，负责配置代理;

Citadel，是负责颁发证书的集中组件，它也有自己在每个节点的代理。

Envoy是由Lyft开发的组件，被McGee描述为“一种非常轻量的L4到L7的智能路由器”，它捕获来自与其配对的微服务的所有传入和传出通信，作为一种流量的控制方式，执行策略和收集遥测。Pilot是IBM提供的主要组件，可作为部署在基础架构中的所有Envoy代理的控制平面。

“如果你想象在一个服务网格中，你可能有一百个微服务，如果每个都有多个实例，你可能有数百或数千个这些智能路由器，你需要一种方法对它们进行全部编程，所以Istio引入了这个称为Pilot的东西。可以把它想象成程序员，所有这些路由器的控制平面。所以你有一个地方可以通过它来编程这个服务网络，然后围绕数据收集进行遥测，围绕安全进行证书管理，但从根本上说你可以利用这个智能路由层和这个控制平面来管理它。”McGee解释道。

Istio还有自己的API，允许用户将其插入现有的后端系统，例如用于日志记录和遥测。

根据谷歌的说法，Istio的监控功能使用户能够测量服务之间的实际流量，例如每秒请求数，错误率和延迟，还可以生成依赖关系图，以便用户可以看到服务之间如何相互影响。

Istio

通过其Envoy边车代理，Istio还可以在每个服务请求上使用双向TLS身份验证（mTLS），添加传输加密并使用户能够授权跨基础架构的每个请求。

Istio消除了开发人员担心实例之间的能否安全通信，解决了控制哪个实例可以与哪些实例进行通信，以及提供执行诸如金丝雀部署之类功能等需求。如果是发布新版本的特定微服务的代码，最初只更新实例的一部分，直到你对新代码运行可靠性感到满意，再更新其他部分。

应该注意的是，其他服务网格平台已经存在，例如开源端的Linkerd或Conduit，而微软有一项服务，被称之为Azure Service Fabric Mesh，目前作为其云平台上的技术预览。此外，服务网格代表了网络管道上方的抽象层，因此前提是已经为每个容器实例配置了网络接口，IP地址和其他网络属性。这通常意味着，无论何时创建新的容器实例，部署微服务还将需要一个单独的工具来自动配置网络。

然而，IBM希望Istio将成为云原生工具包的标准组成部分，正如Kubernetes那样，Kubernetes基于谷歌为自己的内部集群开发的Borg和Omega技术和其上面的容器层技术。

“从社区的角度来看，我的期望是Istio成为架构的默认部分，就像容器和Kubernetes已经成为云原生架构的默认部分一样。”McGee说。为此，IBM希望将Istio与其公有云所提供的Kubernetes托管服务以及其内部部署的IBM Cloud Private堆栈集成在一起。

“所以，你现在可以运行Istio，我们支持现在平台上运行Istio，但期望是在不久的将来，我们将Istio内嵌，所以每当使用我们的平台时，Istio组件就在那里，你可以利用它，并且不必负责部署和管理Istio本身，只需能够在应用程序中使用它。”McGee说。

谷歌已经添加对了Istio的支持，尽管只是将其标记为alpha版本，作为托管服务的一部分，该服务在其云平台上客户的Google Kubernetes Engine（GKE）集群中自动安装和维护。

Istio也获得了业内其他公司的支持，尤其是Red Hat，几年前它重新设计了OpenShift应用程序平台，以Docker容器和Kubernetes为基础。

Red Hat的Istio产品经理Brian Redbeard Harrington表示Red Hat打算将服务网格集成到OpenShift中，但Red Hat希望在正式使用前能看到一些粗糙点的改进，比如支持多租户技术。

“Istio现在的目标是他们所谓的软多租户技术，也就是说，我们希望在组织内部可以使用它，以便该组织内的两个不同的团队可以使用并信任它，只要没有一个组的行为过于恶意，他们就不会影响到彼此的服务。通过我们运行OpenShift Online的方式，我们让客户运行我们从未看过的代码，并且必须最后安排这两个客户并存，这是一个非常独特的多租户挑战。”Harrington解释道。

“我们需要对这个多租户有更高的信心; 我们需要对性能和稳定性有更高的信心。我们还没有看到任何搅局者，但我们已经看到了可提供很多价值的领域，包括在进行规模测试和一些自动化回归测试方面，我们还在社区层面贡献了一个名为Kiali的项目，可视化的给出了Istio的内部运作，这只是我们所提供的产品的一部分。”他补充道。

换句话说，Istio是另一种开源工具，可以为那些希望构建云原生应用程序基础架构的用户添加选项菜单。像Red Hat这样的供应商将把它融入他们经过测试和支持的企业平台产品中比如OpenShift，而其他供应商则希望自己混合搭配并构建它。

原文地址：

https://www.nextplatform.com/2018/08/15/istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices/

原文 http://www.cnblogs.com/huaweiyuncce/p/10045532.html

正文到此结束