Istio服务网格入门:定义和功能


我相信任何对Kubernetes和云原生生态系统感兴趣的人都听过Istio。但清楚Istio是什么?它能和不能做什么?以及它是否是你所需要的技术?这些问题,对于很多人都可能有点难度。因此,希望本文可以帮助你对Istio有一个更清晰的理解。

服务网格定义

“服务网格”既可以应用于分布式应用程序中,服务之间的重叠网络,也可以应用于管理服务间连接的工具集。我们假定有两个通过网络连接的存在交互的微服务和一个服务网格。那它们的关系就如下图所示:
图片_1.jpg

但随着微服务数量的不断增长,服务网格很大可能就变成了如下的样子:
图片_2.jpg

随着微服务生态系统复杂性的不断增长,就越发需要对它进行更加有效和智能地管理,能够深入地洞悉微服务是如何交互的,并确保微服务之间的通信安全。Istio就可以提供上述所需的全部功能。

我们常说的“Istio服务网格”通常指的是Istio工具集,它往常是一个Istio安装所生成的应用程序集群。Istio的CRD可以支持对应用网络层的行为进行编程配置(使用Kubernetes API),这里面所说的应用就是一组相互依赖的微服务。

Istio的工作原理

Istio的组件分为以下两种功能组:
  • 控制平面:是一系列管理配置和监测数据平面的Istio服务。
  • 数据平面:由应用Pod中的Istio代理sidecar组成。这些代理会处理服务网格中微服务之间的网络连接,从控制平面接收微服务的路由和策略规则,并向控制平面报告连接被处理的结果。


整个工作流程如下图:
图片_3.jpg

Istio服务网格往往是通过在所属的Kubernetes中,通过资源创建和配置实现的。Istio需要创建数十个Kubernetes自定义的资源定义,然后映射到其功能的各个方面,从而实现Istio的运行部署。

数据平面

服务网格的数据平面由Envoy服务代理驱动,并与Istio的一些扩展功能共同构建而成。Istio代理运行在每个Kubernetes Pod中的sidecar容器里,服务于Istio服务网格中的应用程序。默认情况下,代理会拦截所有Pod服务端口的传入流量和来自同一Pod中其他容器的TCP流量。在大多数情况下,代理与微服务应用运行在相同的Pod中,不需要对应用程序代码做任何更改,只是少量调整应用程序的Kubernetes部署和服务资源规范即可。而且,代理所在容器的配置是由Istio控制平面中的服务进行动态管理的。

控制平面

在Kubernetes集群内,一个标准的Istio V1.1安装包会包括如下服务:
  • 领航服务:对Istio网络中的自定义资源,编排传输管理规范配置,并注入到 Istio代理的sidecar容器中。
  • 双责任的混合服务:它处理遥测记录传导,充当一个请求指标的清算空间,这些请求指标由代理sidecar产生,并被送到指定的后端。同时,还充当权威策略的执行者。如果集群的策略检查被打开(在Istio 1.1中默认关闭),代理sidecars将连接到混合服务去确认连接是否被允许,不过,开起这个策略后,执行过程会带来轻微的性能开销。
  • Citadel服务:Istio的PKI服务(公开密钥匙体系),在服务网格中为每个微服务提供客户端TLS证书的生成、轮换、撤销以及端到端的验证服务。
  • Galley控制器:是Kubernetes中大多数Istio自定义资源定义的的控制器。处理自定义资源的变更和向其他的Istio服务进行内容分发。


Istio的能力和缺陷

Istio在每个应用程序Pod中都包含了动态可配置的代理,因此它能够提供广泛的网络连接处理和控制功能。但是这些功能所需要的代价是陡峭的学习曲线和重度的配置负载。下表为Istio的能力与优劣势说明:
图片5.jpg

应用迁移

迁移现有应用程序到Istio服务网格,会存在如下的常见问题:
  • Istio如何将用户提供的配置转换为Envoy的实际路由时,过程缺乏可视性。即便这些应用是Kubernetes原生的微服务也是一样的;
  • 需要理解Istio对部署和服务资源配置的需求;
  • mTLS开启时,需要解决Kubernetes预备性和活性探针断裂的问题;
  • 需要找到方法,让Istio可以管理孤儿服务(无集群IP的Kubernetes服务)或绕过正常的Kubernetes服务发现它们。


上面的这些问题,可能会让人有点悲观。但从另一个角度看,Istio正处于迅速发展的阶段。版本频繁发布,前景依然光明。与此同时,工作组人员非常投入,快速地响应着用户的反馈和需求。虽然并不是所有的用户需求变更都是技术上可行的或简单的,中间有许多问题是受制于Envoy代理的限制。而Envoy代理也同样处于快速迭代的过程,Istio也推动着Envoy做了很多方面的完善。

Istio的适用问题

虽然Istio的使用风潮在迅速传播,况且它的功能集和可管理性还在不断改进,但并不是每个Kubernetes集群都是真的需要它。我们认为,采用Istio的最大推动力可能是需要解决以下的一项或多项需求或问题:
  • 基于微服务分布式应用的性能问题;
  • 为所有微服务收集和提交一致的请求和连接的指标;
  • 在无需直接管理TLS证书的情况下,实现默认传输加密;
  • 相比普通的Kubernetes所提供的网络策略,具有更细粒度的服务对服务的控制解决方案;
  • 采用金丝雀发布和应用API多版本支持,实现自动应用发布;
  • 在不修改应用程序的情况下,添加用户身份验证和授权等。


另一方面,如果你不期望Kubernetes集群内所部署的微服务数量会增长,或者Nginx或HAProxy已经可以满足你的内部HTTP请求路由需要,又或者你对于以上的问题清单,已经有可控和更有效的解决方案的话,那么就可能没有必要去迁移和操作一套像Istio复杂的服务网格啦。如果你认为将需要满足前面所描述的任何一点,但也不是需要立即解决的话,Istio值得等待。随着时间的推移,Istio无疑将变得前途光明,并且拥有更丰富的文档生态和功能,去不断改善自身的可管理性。

原文链接: Getting started with Istio Service Mesh - What is it and what does it do?(翻译:易理林)

0 个评论

要回复文章请先登录注册