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

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

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

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

整个工作流程如下图：

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

在Kubernetes集群内，一个标准的Istio V1.1安装包会包括如下服务：

• 领航服务：对Istio网络中的自定义资源，编排传输管理规范配置，并注入到 Istio代理的sidecar容器中。

• 双责任的混合服务：它处理遥测记录传导，充当一个请求指标的清算空间，这些请求指标由代理sidecar产生，并被送到指定的后端。同时，还充当权威策略的执行者。如果集群的策略检查被打开（在Istio 1.1中默认关闭），代理sidecars将连接到混合服务去确认连接是否被允许，不过，开起这个策略后，执行过程会带来轻微的性能开销。

• Citadel服务：Istio的PKI服务（公开密钥匙体系），在服务网格中为每个微服务提供客户端TLS证书的生成、轮换、撤销以及端到端的验证服务。

• Galley控制器： 是Kubernetes中大多数Istio自定义资源定义的的控制器。 处理自定义资源的变更和向其他的Istio服务进行内容分发。

迁移现有应用程序到Istio服务网格，会存在如下的常见问题：

• Istio如何将用户提供的配置转换为Envoy的实际路由时，过程缺乏可视性。即便这些应用是Kubernetes原生的微服务也是一样的；

• 需要理解Istio对部署和服务资源配置的需求；

• mTLS开启时，需要解决Kubernetes预备性和活性探针断裂的问题；

• 需要找到方法，让Istio可以管理孤儿服务（无集群IP的Kubernetes服务）或绕过正常的Kubernetes服务发现它们。

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

虽然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/