随着微服务规模和复杂性的增长，服务网格越来越难以理解和管理。其中 Istio 提供了服务发现、负载均衡、故障恢复、指标收集和监控等完整的服务网格解决方案，降低了功能模块部署的复杂性，减轻了开发团队的压力。本文对 Istio 网格进行了初步的介绍，希望能激发大家对 Istio 网格的兴趣。
1 Istio 是什么
服务网格这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互，服务网格是用于处理服务间通信的专用基础设施层。它负责通过包含现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，服务网格通常通过一组轻量级网络代理来实现，这些代理与应用程序代码一起部署，而不需要感知应用程序本身。
随着微服务规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。
Istio 提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。在较高的层次上，Istio 有助于降低这些部署的复杂性，并减轻开发团队的压力。它是一个完全开源的服务网格，可以透明地分层到现有的分布式应用程序上。它也是一个平台，包括集成到任何日志记录平台、遥测或策略系统的 API。Istio 的多样化功能集使您能够成功高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。
通过两幅图来对比一下 Istio 在服务网格中的作用，未使用 Istio 的微服务之间的调用方式如下：
使用 Istio 管理的微服务之间的调用方式：
使用 Istio 的流量管理模型，本质上是将流量与基础设施扩容解耦，让运维人员可以通过 Pilot 指定流量遵循什么规则，而不是指定哪些 pod/VM 应该接收流量——Pilot 和 Envoy 代理会帮我们搞定。
2 Istio 架构
Istio 服务网格逻辑上分为数据平面和控制平面。
数据平面
数据平面由一组以 sidecar 方式部署的智能代理（Envoy）组成。这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。
数据平面的特点：
- 通常是按照无状态目标设计的，但实际上为了提高流量转发性能，需要缓存一些数据，因此无状态也是有争议的。
- 直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
- 对应用来说透明，即可以做到无感知部署。
控制平面
控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。
控制平面的特点：
- 不直接解析数据包。
- 与数据平面中的代理通信，下发策略和配置。
- 负责网络行为的可视化。
- 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。
Istio 的架构如图：
我们今天重点关注的是 Pilot 组件的基本实现。
3 Pilot 组件
Pilot 为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能。它将控制流量行为的高级路由规则转换为特定于 Envoy 的配置，并在运行时将它们传播到 sidecar。
Pilot 组件架构如下图：
Pilot 的架构，最下面一层是 Envoy 的 API，提供 Discovery Service 的 API，这个 API 的规则由 Envoy 约定，Pilot 实现 Envoy API Server，Envoy 和 Pilot 之间通过 gRPC 实现双向数据同步。Pilot 最上面一层称为 Platform Adapter，这一层不是 Kubernetes 调用 Pilot，而是 Pilot 通过调用 Kubernetes 来发现服务之间的关系，Pilot 通过在 Kubernetes 里面注册一个 Controller 来监听事件，从而获取 Service 和 Kubernetes 的 Endpoint 以及 Pod 的关系。Istio 通过 Kubernets CRD 来定义自己的领域模型，使大家可以无缝的从 Kubernets 的资源定义过度到 Pilot 的资源定义。
Pilot 组件主要包含两部分，pilot-agent 和 pilot-discovery，我们基于 Istio 官方的 bookinfo 应用，探索一下 pilot 组件。bookinfo 应用的架构如图所示：
pilot-agent
开启集群的 Sidecar 自动注入，以 productpage 服务为例，观察一下 Istio 对我们的应用容器到底做了了什么。
Istio 对 productpage 进行定制化之一：嵌入 proxy_init 作为 InitContainer, InitContainer 用于设置 iptables 规则，让出入流量都转由 Sidecar 进行处理, Istio-init 只用来设置 iptables 规则。
Istio 对 productpage 进行定制化之二：嵌入 proxy 容器作为 Sidecar，基于 Envoy 实现。
istio-proxy 容器的运行的进程包括 pilot-agent 和 envoy：
pilot-agent 的启动流程：
总结一下 pilot-agent 的作用：
- 生成 Envoy 的启动配置。
- 启动 envoy。
- 监控并管理 envoy 的运行状况，比如 envoy 出错时 pilot-agent 负责重启 envoy，或者 envoy 配置变更后 reload envoy。
pilot-discovery
pilot-discovery 负责从 k8s apiserver list/watch service、endpoint、pod、node 等获取资源信息，监听 istio 控制平面配置信息（如 VirtualService、DestinationRule 等）， 并将其翻译为 Envoy 可以直接理解的配置格式。
pilot 的架构下图所示：
pilot-discovery 的启动流程：
bootstrap.NerServer：
initConfigController：
initServiceControllers：
initDiscoveryService：
在 initDiscoveryService 阶段，注册了 Service(k8s services) 和 ServiceInstance(k8s endpoints) 的两个 eventHandler，在 k8s 资源发生变化时会触发更新 envoy 配置的操作，这里的实现留待后续详细分析。
通过以上的简单分析，我们对 pilot 组件有了一个初步认识，后续我们会进一步深入代码探讨具体的执行流程，并发现在大规模部署的生产环境中可能存在性能瓶颈。
4 TODO
- pilot 如何转换 k8s 的数据模型和 envoy 的数据模型
- pilot 的 gRPC 推送时机
- …
刚开始学习 Istio 相关组件，理解难免有偏颇，非常欢迎大家指正。
本文转载自公众号 360 云计算（ID：hulktalk）。
原文链接：
评论