入门了解Service Mesh + Istio？从本文开始

诸如容器、Kubernetes等云原生架构和技术的成熟推进了服务网格架构的极速增加以及普遍采用。尽管云原生环境能够为企业带来一系列好处，可是其复杂性也对负责开发维护这类系统的人员，如软件开发人员、网络运维人员、基础架构工程师以及CIO、CTO等带来了重大挑战。

服务网格框架可以为跨不一样云原生环境的应用程序整合一致的服务和网络管理能力，它还极大地加快了DevOps实践的进程，正缘于此，服务网格近年来可谓是发展迅猛。云原生普及的加快，要求拥有云原生应用程序的工程团队必须熟悉服务网格功能，以判断该技术未来是否能为企业提供价值。

什么是服务网格？

服务网格能够链接、保护、控制以及监控在编排平台上的服务。“服务网格”这一术语自己用于分布式应用程序中服务之间的一组搭接网络链接，也适用于管理该组链接服务的一系列工具。若是你有两个经过网络链接进行交互的微服务，那就意味着你有了一个服务网格。下图是一个十分简单的示例，一个网格和两个服务：

更有可能的是，因为在环境中微服务的数量会继续增加，你的服务网格会以下图所示：

随着云环境扩展到混合云和多云部署，开发人员将会使用微服务来加速开发而且确保在多个容器和分布式云资源中的的可移植性。随着微服务生态系统的复杂性增加，咱们须要高效且智能地管理它，而且深刻了解微服务如何交互以及保护微服务之间的通讯。

什么是Istio？

若是你已经据说了服务网格，那么你必定顺带据说了Istio。Istio是一个开源的服务网格，它能够部署在已有的云原生应用程序上。它还具备相似于平台的功能——能够将集成到日志平台、遥测或策略系统中。策略集成使得Istio在建立一个统一的方法来保护、链接以及监控既定环境中的微服务中扮演一个安全工具的角色。当泛指“Istio服务网格”时，一般是指Istio中的一系列工具，而特指“某个Istio 服务网格”时则代表由Istio安装管理的指定应用程序集群。Istio的许多CRD容许对应用程序网络层的行为进行编程配置（经过使用Kubernetes API），其中应用程序是相互依赖的微服务集。Istio在某种程度上能够称为当今云原生堆栈中服务网格的同义词，由于它的功能最丰富、最标准化。

我是否须要一个服务网格？

尽管服务网格的采用率可能会持续快速增加，特别是当功能设置和相似Istio的管理工具进一步完善以后，但并非每一个云原生环境都须要服务网格。因此你如何知道一个服务是否适合你的企业或者环境呢？若是你须要解决下面所描述的一个或多个需求或问题的方案，那么你应该考虑部署一个服务网格：

• 你在基于分布式微服务的应用程序中遇到性能问题
• 你须要为全部微服务收集并交付一致的请求和链接指标
• 你想直接默认在线加密设置，而无需直接管理TLS证书
• 你须要比Kubernetes网络策略提供的更细粒度的解决方案进行服务到服务的控制
• 你想使用金丝雀发布和应用程序API多版本支持进行自动release
• 你想无需修改应用程序就能够添加用户的身份验证和受权认证信息

另外一方面，若是在你的堆栈中不须要服务网格，那么你须要作一些权衡。考虑到这些环境的复杂性，部署一个服务网格（包括Istio）须要大量的迁移工做和运维成本。若是你的微服务部署数量不会增加，或者若是有其余解决方案能够知足你内部的HTTP请求路由的需求，或者若是你已经有了一个可管理且高效的解决方案能够解决上述的关键需求，那么此刻服务网格对你来讲真的不是一个最佳选择。

可是若是服务网格继续极速被普遍采用，为支持它而开发的功能生态系统将会继续扩展。这种增加将提高可管理性和功能性，以便未来DevOps团队能够更加轻松地访问更强大的服务网格工具，而没必要担忧将新的基础架构层部署到云原生堆栈中而出现棘手的问题或花费很高的成本。

Istio工做原理

Istio组件被分为两部分——控制平面和数据平面。控制平面是指管理配置和监控数据平面的服务。数据平面由做为sidecar由在应用程序pod中的智能代理（proxy）组成，这是Kubernetes对象模型中最小的可部署对象。这些Istio proxy有助于控制和监控微服务间的网络链接。从控制平面接收路由和策略规则，而后数据平面报告回链接处理遥测。

经过建立Kubernetes资源来配置Istio服务网格。此外，有许多Kubernetes CRD能够映射到Istio各类功能上。接下来，咱们会讨论更多关于控制和数据平面的做用，但在此以前咱们先了解关于Istio的潜在能力，以及它的不足。

潜力与不足

Istio经过其可动态配置代理的网格提供了一系列用于处理和控制网络链接的特性。但这些功能配置繁重而且拥有陡峭的学习曲线。而且有时把已有的应用程序迁移到Istio架构时依旧会出现一些常见的问题，尽管这些架构已是Kubernetes原生的微服务。

此外，Istio缺少对如何将用户提供的配置转换为Envoy路由的了解。Envoy是做为服务网格中服务的入站和出站流量的中介开发的一种高性能的代理，是由来自共享出行服务公司Lyft的开发人员建立的，能够用于从单体架构转变为服务网格架构。其余在使用中的问题还包括部署和服务资源配置要求所需的学习曲线、在打开mTLS时中断Kubernetes readiness和liveness探针以及使用没有ClusterIP的Kubernetes服务或绕开Kubernetes服务发现流程的服务。

Istio的优点在于可让你在不修改微服务源代码的状况之下，很轻松地给微服务加上诸如负载均衡、身份验证、监控等等的功能。并且目前它正在快速发展迭代，频繁发布新版本，而且积极征求用户反馈。尽管目前Envoy还有不少局限，可是随着Istio持续发展，它也会积极开发和完善本身的功能。

配置控制平面

在Kubernetes集群中，一个典型的Istio部署应该包含如下服务：

Pilot，在Istio网络自定义资源中集合流量管理规范配置，并将该配置交付到istio-proxy sidecar。

Mixer，用于处理由proxy sidecar生成的请求指标的遥测，并将其发送到已配置完成的后端，并执行受权策略。若是开启了策略检查（Istio 1.1中默认关闭），proxy sidecar将会链接到Mixer以确认链接是被容许的。可是，这个方法会稍微增长网络延迟。

Citadel，这个是Istio的公钥基础设施（PKI）服务，它能够生成、轮换和吊销用于身份验证的客户端TLS证书。

Galley，它是大多数Istio CRD的Kubernetes controller，使用户能够更改自定义资源并将内容分配到其余Istio服务中。

数据平面

数据平面由Envoy服务代理提供支持，该代理使用Istio扩展构建。Proxy会拦截到pod服务端口的传入流量，并默认拦截来自pod其余容器的全部创出TCP流量。在大部分状况下，无需更改应用程序代码，仅对应用程序的Kubernetes部署和服务资源规范进行较小的更改，proxy sidecar 就能够在pod中运行。Proxy sidecar的配置由在Istio 控制面板中的服务进行动态管理。

最终，也许会在某个时间点你须要部署服务网格以确保你的云原生环境彻底正常运行并获得充分保护。所以，熟悉有关服务网格的基础只是将能够帮助你作出准确的判断——何时应该部署服务网格以及应该如何部署。若是你正在计划在Kubernetes和其余容器平台上进行扩展计划，那么你经过了解Istio的设计和功能以及它如何下降容器化微服务和云原生环境的固有复杂性，你能够知道Istio是一个功能强大且快速改进的解决方案而且正在积极加强弹性伸缩能力、安全性以及管理的简易性。

若是企业继续采用云原生和分布式架构，那么Istio的服务网格功能以及底层基础架构的网络控制和Kubernetes的安全实践将会极大程度解放DevOps团队在弹性伸缩和管理应用程序基础架构上的压力。

在10月9日GA的Rancher 2.3版本中，正式集成了Istio，极大简化了Istio的安装和配置。你只须要在UI中使用工具菜单，便可启动Istio。Rancher中现已内置支持：

• 用于流量和遥测可视化的Kiali仪表板
• 用于追踪的Jaeger
• 用于监控和可观察性的Prometheus和Grafana

若是你还想了解更多关于Rancher 2.3的新功能，欢迎参加咱们在下周六（10月26日）举办的技术沙龙，坐标深圳。届时将有Rancher Labs大中华区的研发经理现场介绍并demo Rancher 2.3的新功能，点击此处，赶忙报名啦！

欢迎添加小助手（wx：rancher2)，进官方技术群，了解更多Kubernetes使用攻略