上一篇 通过介绍互联网架构的演进过程，让大家对 Service Mesh 有了初步的认识。但大家可能都会有以下几个疑问：
- 什么是 Istio ？
- Kubernetes 和 Istio 是什么关系呢？
- 为什么需要 Istio ?
- Istio 的核心功能有哪些？
- Istio 有哪些特性？
- Istio 的架构是什么样的？
Istio
Istio
Istio 是一个由 Google，IBM 和 Lyft 团队合作开发的开源 Service Mesh 框架。Istio 作为云原生时代下承 Kubernetes、上接 Serverless 架构的重要基础设施层，提供了基于微服务应用程序复杂性的解决方案。
Istio 作为透明的一层部署到现有的分布式应用程序里。它也是一个平台，拥有可以集成任何日志、遥测和策略系统的 API 接口。Istio 的多样化的特性使您能够高效地运行分布式微服务架构，并提供统一的方式来连接、保护、控制和观察服务。Istio 有助于降低部署的复杂性，并减轻开发团队的压力。
Kubernetes 和 Istio
Kubernetes 提供了部署、升级和有限的运行流量管理能力，但并不具备熔断、限流降级、调用链追踪等能力。Kubernetes 的本质是通过声明式配置对应用进行生命周期管理，其强项在于容器的调度和编排，而 Istio 的本质是提供应用间的流量和安全以及可观察性等。Istio 很好地补齐了 Kubernetes 在微服务治理上的诸多能力，为 Kubernetes 提供更好的应用和服务管理。因此，Istio 与 Kubernetes 是极为互补的。
Istio
为什么需要 Istio
微服务体系带给我们很有好处，但也带来一些问题：
- 服务发现
- 负载均衡
- 故障恢复
- 指标
- 监控
- A / B 测试
- 金丝雀发布
- 熔断
- 限速
- 调用链追踪
- 访问控制
- 端到端认证
- …
大家可成想过，要实现这些，需要花多少精力，对业务的入侵性又有多少？
Istio 通过负载平衡，服务到服务的身份验证，监控等功能，可以轻松创建已部署服务的网络，而服务的代码只需很少更改甚至无需更改。 Istio 通过在整个环境中部署特殊的 Sidecar 代理来支持服务，以拦截微服务之间的所有网络通信，然后使用 “控制平面” 功能配置和管理 Istio，其中包括：
-
HTTP、gRPC、WebSocket 和 TCP 通信的自动负载均衡。
gRPC — 可在任何环境中运行的开源高性能 RPC 框架
-
通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。
-
可插拔的策略层和配置 API，支持访问控制、速率限制和配额。
-
集群内（包括集群的入口和出口）所有流量的自动度量，日志和跟踪。
集群入口-允许入站连接到达集群服务的一组规则。 集群出口-允许出站连接到达集群服务的一组规则。
-
具备强大的基于身份的验证和授权，确保群集中服务之间的通信安全。
Istio 为可扩展性而设计，可以满足不同的部署需求。
借助 Istio 可以轻松地处理微服务体系带来的一系列问题，让我们更专注于业务本身。
Istio 的核心功能
连接（Connect）
智能控制服务之间的流量和 API 调用，进行一系列测试，并通过灰度发布逐步升级。
安全（Secure）
通过托管身份验证、授权和服务之间通信加密，自动为服务通信提供安全保障。
控制（Control）
应用并确保执行流量控制策略，使得资源在客户侧的公平分配。
遥测（Observe）
对服务进行多样化、自动化的追踪、监控以及记录日志，以便实时了解服务运行状态。
Istio
Istio 特性
Istio 以统一的方式提供了许多跨服务网络的关键功能：
流量管理
Istio 简单的规则配置和流量路由允许您控制服务之间的流量和 API 调用过程。Istio 简化了服务级属性（如熔断器、超时和重试）的配置，并且让它轻而易举的执行重要的任务（如 A/B 测试、金丝雀发布和按流量百分比划分的分阶段发布）。
有了更好的对流量的可视性和开箱即用的故障恢复特性，您就可以在问题产生之前捕获它们，无论面对什么情况都可以使调用更可靠，网络更健壮。
安全
Istio 的安全特性解放了开发人员，使其只需要专注于应用程序级别的安全。Istio 提供了底层的安全通信通道，并为大规模的服务通信管理认证、授权和加密。有了 Istio，服务通信在默认情况下就是受保护的，可以让您在跨不同协议和运行时的情况下实施一致的策略——而所有这些都只需要很少甚至不需要修改应用程序。
Istio 是独立于平台的，可以与 Kubernetes（或基础设施）的网络策略一起使用。但它更强大，能够在网络和应用层面保护pod 到 pod 或者服务到服务之间的通信。
策略
Istio 允许您为应用程序配置自定义的策略并在运行时执行规则，例如：
- 速率限制能动态的限制访问服务的流量
- Denials、白名单和黑名单用来限制对服务的访问
- Header 的重写和重定向
- Istio 还容许你创建自己的策略适配器来添加诸如自定义的授权行为。
可观察性
Istio 健壮的追踪、监控和日志特性让您能够深入的了解服务网格部署。通过 Istio 的监控能力，可以真正的了解到服务的性能是如何影响上游和下游的；而它的定制 Dashboard 提供了对所有服务性能的可视化能力，并让您看到它如何影响其他进程。
Istio 的 Mixer 组件负责策略控制和遥测数据收集。它提供了后端抽象和中介，将一部分 Istio 与后端的基础设施实现细节隔离开来，并为运维人员提供了对网格与后端基础实施之间交互的细粒度控制。
所有这些特性都使您能够更有效地设置、监控和加强服务的 SLO。当然，底线是您可以快速有效地检测到并修复出现的问题。
Istio 架构
注：今后的文章采用的 Istio 为目前最新的 1.5 版本。该版本已经去掉了 Mixer 组件。
Istio 服务网格从逻辑上分为数据平面和控制平面。
- 数据平面由一组智能代理（Envoy）组成，被部署为 sidecar。这些代理协调和控制所有的微服务之间的所有网络通信。同时，它们也收集和遥测所有网格的流量。
- 控制平面管理并配置代理来进行流量路由。
Istio 中的流量分为数据平面流量和控制平面流量。数据平面流量是指工作负载的业务逻辑发送和接收的消息。控制平面流量是指在 Istio 组件之间发送的配置和控制消息用来编排网格的行为。Istio 中的流量管理特指数据平面流量。
Envoy
Istio 使用 Envoy 代理的扩展版本。Envoy 是用 C++ 开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。Envoy 代理是唯一与数据平面流量交互的 Istio 组件。
Envoy 代理被部署为服务的 sidecar，在逻辑上为服务增加了 Envoy 的许多内置特性，例如:
- 动态服务发现
- 负载均衡
- TLS 终端
- HTTP/2 与 gRPC 代理
- 熔断器
- 健康检查
- 基于百分比流量分割的分阶段发布
- 故障注入
- 丰富的指标
这种 sidecar 部署允许 Istio 提取大量关于流量行为的信号作为属性。反之，Istio 可以使用这些属性来执行决策，并将它们发送到监控系统，以提供整个网格的行为信息。
sidecar 代理模型还允许您向现有的部署添加 Istio 功能，而不需要重新设计架构或重写代码。
由 Envoy 代理启用的一些 Istio 的功能和任务包括:
- 流量控制功能：通过丰富的 HTTP、gRPC、WebSocket 和 TCP 流量路由规则来执行细粒度的流量控制。
- 网络弹性特性：重试设置、故障转移、熔断器和故障注入。
- 安全性和身份验证特性：执行安全性策略以及通过配置 API 定义的访问控制和速率限制。
Pilot
Pilot 为 Envoy sidecar 提供服务发现、用于智能路由的流量管理功能（例如，A/B 测试、金丝雀发布等）以及弹性功能（超时、重试、熔断器等）。
Pilot 将控制流量行为的高级路由规则转换为特定于环境的配置，并在运行时将它们传播到 sidecar。Pilot 将特定于平台的服务发现机制抽象出来，并将它们合成为任何符合 Envoy API 的 sidecar 都可以使用的标准格式。
下图展示了平台适配器和 Envoy 代理如何交互。
- 平台启动一个服务的新实例，该实例通知其平台适配器。
- 平台适配器使用 Pilot 抽象模型注册实例。
- Pilot 将流量规则和配置派发给 Envoy 代理，来传达此次更改。
这种松耦合允许 Istio 在 Kubernetes、Consul 或 Nomad 等多种环境中运行，同时维护相同的 operator 接口来进行流量管理。
您可以使用 Istio 的流量管理 API 来指示 Pilot 优化 Envoy 配置，以便对服务网格中的流量进行更细粒度地控制。
Citadel
Citadel 通过内置的身份和证书管理，可以支持强大的服务到服务以及最终用户的身份验证。您可以使用 Citadel 来升级服务网格中的未加密流量。使用 Citadel，operator 可以执行基于服务身份的策略，而不是相对不稳定的 3 层或 4 层网络标识。从 0.5 版开始，您可以使用 Istio 的授权特性来控制谁可以访问您的服务。
Galley
Galley 是 Istio 的配置验证、提取、处理和分发组件。它负责将其余的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节隔离开来。
小结
本文通过问题式的方式介绍了 Istio 这个 Service Mesh 网红，希望能帮助到大家。
以下是我个人的一些理解：
- Kubernetes 关注 Pod，Istio 关注 Service。
- Istio 是个平台，而 Envoy 是非常重要的一个组件，因为许多事情其实是它在做，Istio 更多的是充当适配和规则转发的角色。这也正是 Service Mesh 是 sidecar 模式导致的。因此，Istio 选择了 Envoy 这种用 C++ 开发的高性能代理。在 Service Mesh 世界里，得 sidecar 者得天下。
- 如果部署服务时，遇到配置派发不成功，应该先检查 Galley 组件是否正常，因为 Galley 负责了配置验证。
- 通过架构的描述可知，Istio 在性能与架构的选择中，选择了优先架构。
这些理解供大家参考，也欢迎大家留言讨论，咱们下一篇见。
网友评论