Istio架构
Istio 服务网格从逻辑上分为数据平面和控制平面,因为Istio是Envoy的控制平面。
- 数据平面 由一组智能代理（Envoy ）组成，被部署为 Sidecar。这些代理负责协调和控制微服务之间的所有网络通信。它们还收集和报告所有网格流量的遥测数据。
- 控制平面 管理并配置代理来进行流量路由。 下图展示了组成每个平面的不同组件：
从完整意义上来讲,Istio服务网格逻辑上分为数据平面和控制平面。
目前Istio已经回归单体服务架构了
- 控制平面： 由多个组件组成完成控制机制,主要有
Pilot、Citadel、Galley,新版已经移除限流的组件Mixer。Pilot: 控制面的核心组件，负责对接 Envoy 数据面，也可以解析上层抽象出来的 lstio 配置，转换成数据面可以识别的 xDS 协议配置并分发到各个 Envoy。Galley: 为更好的解耦职责，它在 lstio 1.1 后由仅负责配置验证升级成了控制面的配置管理中心，可以对接不同注册中心，用于为服务网格提供配置输入能力。Citadel: 责服务网格里安全相关功能，为服务和用户提供认证和鉴权、管理凭据和 RBAC 等相关能力。Istiod: 新加入的istiod接手了很多很多的功能,简单的来说,istiod承担所有功能!
- 数据平面: 以
sidecar的形式与服务进程一起运行.
为什么要用到服务网格
不存在服务网格的业务
一般典型的基于kubernetes部署的应用有前端、后端、数据库,其应用的流量大致有两部分组成
- 客户端服务-服务端服务(基于服务内部通信,微服务场景),也就是
service-to-service,即东西向流量。 - 服务端服务需要开放给外部服务访问,通常服务前会带有
Ingress Gateway,其实IngressGateway与Istio的代理服务sidecar类似。以及网格内部的服务不止需要请求网格内部的服务,甚至可能需要请求网格之外的服务。例如：redis外置、MySQL外置等,出口流量一般通过EgressGatewy,即南北向流量。 如果没有用到服务网格,那么你可能会遇到以下问题 - 服务与服务之间的通信安全无法保证：如果运行在Kubernetes中的后端向位于不同节点的数据库进行发送请求,跨节点之间的请求如果通信数据不加密,就可能会被嗅探数据,因为当前网络为
0信任网络,通常的网络插件是支持节点到节点之间的数据加密的,但是从Pod内部流出到出口之间的流量依旧无法保证其安全性。 - 跟踪通信延迟异常困难：如果你想了解通信的节点过程何时发生的延迟,以及经过中间那些组件或者诊断问题并不是那么容易。
- 负载均衡的能力有限：一般来说是通过
ipvs,无法实现高级负载。例如流量切割、流量镜像、AB测试等等…
服务网格的功能
目前很多服务网格的特性上重叠性颇高,他们几乎都具有下列功能.
- Traffic Management(流量治理)
- 7层流量治理、动态路由、基于权重、流量镜像、熔断功能、限流、故障注入
- Securty(安全)
- 双向TLS加密、身份认证(SPIFFE)、授权
- Observability(可观测性)
- Metrics(指标)、Tracing(分布式跟踪)、Traffic(流量)
- Mesh(支持平台)
Istio是什么?
- 它是一个完全开源的服务网格，作为透明的一层接入到现有的分布式应用程序里。它也是一个平台，拥有可以集成任何日志、遥测和策略系统的 API 接口。Istio 多样化的特性使您能够成功且高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。
- 是Envoy Data Plane控制平面之一,拥有控制平面以及数据平面.
为什么要用Istio
通过负载均衡、服务间的身份验证、监控等方法，Istio 可以轻松地创建一个已经部署了服务的网络，而服务的代码只需很少 更改甚至无需更改。通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持，而代理会拦截微服务之间的所有网络通信，然后使用其控制平面的功能来配置和管理 Istio，这包括：
- 为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡,因为原生的
Kubernetes平台基于Service的服务发现是相对于简陋的,因为基于内核形态和dns以及iptables来进行服务发现,这些是远远满足不了高级需求的. - 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。
- 可插拔的策略层和配置 API，支持访问控制、速率限制和配额。
- 集群内（包括集群的入口和出口）所有流量的自动化度量、日志记录和追踪。
- 在具有强大的基于身份验证和授权的集群中实现安全的服务间通信。
