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

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

服务网格定义

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

但随着微服务数量的不断增长，服务网格很大可能就变成了如下的样子：

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

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

Istio的工作原理

Istio的组件分为以下两种功能组：

• 控制平面：是一系列管理配置和监测数据平面的Istio服务。

• 数据平面：由应用Pod中的Istio代理sidecar组成。这些代理会处理服务网格中微服务之间的网络连接，从控制平面接收微服务的路由和策略规则，并向控制平面报告连接被处理的结果。

整个工作流程如下图：

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的能力与优劣势说明：

应用迁移

迁移现有应用程序到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无疑将变得前途光明，并且拥有更丰富的文档生态和功能，去不断改善自身的可管理性。

原文链接：https://www.stackrox.com/post/2019/06/getting-started-with-istio-service-mesh-what-is-it-and-what-does-it-do/

Kubernetes入门与实战培训

Kubernetes入门与实战培训将于2019年11月22日在北京开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等等，点击下方图片或者阅读原文链接查看详情。