28.云原生之服务网格ServiceMesh和istio_云原生 service mesh

云原生专栏大纲

Service Mesh介绍

Service Mesh（服务网格）是一种用于处理微服务间通信的架构模式。它提供了一种透明且可配置的方式来管理服务之间的网络通信，以解决微服务架构中的一些常见问题。
在传统的微服务架构中，服务之间的通信通常通过HTTP或RPC进行，而这些通信通常需要显式地在代码中编写和管理。这导致了一些挑战，如服务发现、负载均衡、故障恢复、安全性和可观测性等方面的复杂性。
Service Mesh通过在微服务之间插入一个专用的代理（称为Sidecar），来解决这些问题。该代理与每个微服务实例一起部署，并负责处理网络通信。Service Mesh通常使用开源项目（如Istio、Linkerd和Consul）来实现。
Service Mesh提供了以下核心功能：

1. 服务发现和服务注册：Service Mesh可以自动发现和注册微服务的实例，使它们可以相互通信，而无需手动配置。
2. 负载均衡：Service Mesh可以在多个微服务实例之间分配负载，以实现负载均衡，从而提高可用性和性能。
3. 故障恢复：Service Mesh可以监测微服务的健康状态，并在出现故障时自动进行故障恢复，例如自动重试请求或切换到备用服务。
4. 安全性：Service Mesh提供了一系列安全功能，如流量加密、身份验证和访问控制，以确保微服务之间的通信是安全的。
5. 可观测性：Service Mesh可以收集和分析微服务的运行时数据，例如请求流量、延迟和错误率等，以帮助监控和故障排除。

通过引入Service Mesh，开发人员可以将关注点从网络通信细节转移到业务逻辑上。它提供了一种解耦的方式来处理微服务间的通信，并提供了一些强大的功能来提高可靠性、安全性和可观察性。
以下是几个常见的开源项目，用于实现服务网格：

为什么要使用ServiceMesh？

先说说小编实际感受：

1. 公司项目上百个以上，缺乏周边服务治理，如监控报警日志等。服务挨个集成成本大
2. 上k8s，只用于系统部署，中间件、Jenkins等都单独部署在k8s外，组件没统一管理
3. 历史遗漏系统太多，技术人员技术参差不齐，在项目中集成周边服务治理组件不太现实
4. 基于上诉问题，需将服务治理组件下沉到基础设施中，istio刚好能解决这些问题

微服务，又叫微服务架构，是一种软件架构方式。它将应用构建成一系列按业务领域划分模块的、小的自治服务。

传统微服务架构面临的挑战：

传统微服务基础设施如服务注册与发现，在工程中需引入三方SDK，代码入侵高，当周边服务治理组件越多，依赖越复杂，技术绑定过紧，语音支持受限、难以维护

思考：上述架构问题，基础设施和业务系统深度耦合，如何剥离？当将基础设施SDK从左下图工程中剥离出到右图，基础设施SDK成为单独的服务，与原来服务如何通信成了一个问题。

因此基础设施SDK既要剥离，也要与原来服务逻辑上为一体，使用与原来一样透明无感，演化出如下边车架构及ServiceMesh架构风格：

Istio介绍

Istio是一个开源的服务网格平台，用于管理和连接微服务应用程序。它提供了一组强大的功能，以增强微服务架构的可观察性、可靠性和安全性。
以下是Istio的一些关键特性：

1. 服务间通信管理：Istio通过在微服务之间插入Sidecar代理，实现了对服务间通信的全面控制。这些代理负责处理流量路由、负载均衡、故障恢复、熔断、限流等功能，无需修改应用程序代码。
2. 流量控制和策略：Istio允许您定义和应用细粒度的流量控制策略，例如基于服务版本、用户ID、请求头等的路由规则。它还支持故障注入、熔断和限流等功能，以确保服务的可靠性和稳定性。
3. 可观察性和监控：Istio提供了丰富的监控和可观察性功能，可以收集和展示服务间的请求流量、延迟、错误率等指标。它还支持分布式追踪，可以帮助您了解整个请求链路的性能和行为。
4. 安全性和身份验证：Istio提供了流量加密和身份验证功能，以确保服务间通信的安全性。它支持基于TLS的加密通信，并集成了多种身份验证机制，如基于令牌的访问控制和JWT验证。
5. 配置和策略管理：Istio提供了一种集中化的方式来管理微服务的配置和策略。您可以定义和应用全局的配置规则，以及针对特定服务或版本的配置。这样可以简化配置管理，并提供更大的灵活性。
6. 多集群支持：Istio支持多集群部署，可以在不同的Kubernetes集群之间实现服务网格的扩展。它提供了跨集群的流量路由和通信管理功能，使得在多个集群中部署和管理微服务变得更加容易。

总之，Istio是一个功能强大的服务网格平台，提供了丰富的功能来简化和增强微服务应用程序的管理和通信。它可以帮助您解决微服务架构中的常见问题，并提供更好的可观察性、可靠性和安全性。

istio架构

Istio的架构主要由以下几个核心组件组成：

1. 数据平面（Data Plane）：数据平面由一组智能代理（Envoy）组成，被部署为 Sidecar。这些代理被插入到应用程序的服务之间负责协调和控制微服务之间的所有网络通信，用于转发和管理流量。数据平面代理负责处理所有进出服务的网络流量，并与控制平面进行通信。它们还收集和报告所有网格流量的遥测数据。
2. 控制平面（Control Plane）：管理并配置代理来进行流量路由。它包含了多个组件：
   • Pilot：负责服务发现、流量路由和负载均衡。它将服务的网络拓扑信息发送给数据平面代理，并配置它们的路由规则。
   • Citadel：提供服务间的身份和安全性。它负责生成和分发TLS证书，以确保服务之间的安全通信。
   • Galley：负责验证和转换用户定义的配置，并将其分发给数据平面代理。
   • Mixer：负责策略控制、遥测收集和访问控制。它可以执行各种策略检查，并收集应用程序的遥测数据。
3. 策略和配置（Policy and Configuration）：Istio提供了丰富的策略和配置选项，用于控制流量、安全性和可观察性。这些策略和配置可以通过控制平面的组件进行管理和分发。
4. 遥测（Telemetry）：Istio收集和展示应用程序的遥测数据，以帮助用户监视和调试应用程序。它可以收集关于流量、延迟、错误率等方面的数据，并将其展示在可视化的仪表

下面是对Istio的核心组件进行简要介绍的表格输出：

Envoy

Istio 使用 Envoy 代理的扩展版本。Envoy 是用 C++ 开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。Envoy 代理是唯一与数据平面流量交互的 Istio 组件。
Envoy 代理被部署为服务的 Sidecar，在逻辑上为服务增加了 Envoy 的许多内置特性，例如：

这种 Sidecar 部署允许 Istio 可以执行策略决策，并提取丰富的遥测数据， 接着将这些数据发送到监视系统以提供有关整个网格行为的信息。
Sidecar 代理模型还允许您向现有的部署添加 Istio 功能，而不需要重新设计架构或重写代码。
由 Envoy 代理启用的一些 Istio 的功能和任务包括：

• 流量控制功能：通过丰富的 HTTP、gRPC、WebSocket 和 TCP 流量路由规则来执行细粒度的流量控制。
• 网络弹性特性：重试设置、故障转移、熔断器和故障注入。
• 安全性和身份认证特性：执行安全性策略，并强制实行通过配置 API 定义的访问控制和速率限制。
• 基于 WebAssembly 的可插拔扩展模型，允许通过自定义策略执行和生成网格流量的遥测。

Istiod

Istiod是Istio服务网格的核心组件之一，它是Istio控制平面的主要部分。作为Istio的控制平面代理，Istiod负责管理和协调整个服务网格中的流量路由、安全策略和监控等功能。
以下是Istiod的主要功能和特点：

1. 配置管理：Istiod负责管理和分发整个服务网格的配置信息，包括路由规则、目标规则、策略规则等。它通过与Pilot组件交互，将配置信息下发给数据平面的Envoy代理。
2. 流量管理：Istiod支持动态服务发现和负载均衡，可以自动发现和管理后端服务的实例，并根据配置的路由规则和负载均衡策略，智能地将流量路由到可用的服务节点。
3. 安全策略：Istiod集成了Istio的安全功能，包括服务间的身份认证、流量加密和访问控制。它通过与Citadel组件交互，管理和分发服务之间的TLS证书和密钥，确保服务之间的通信是安全的。
4. 监控和遥测：Istiod与Mixer组件紧密集成，可以收集和聚合服务网格中的遥测数据，如请求流量、延迟、错误率等。这些数据可以用于监控和分析服务的性能和可靠性。
5. 策略和故障注入：Istiod支持Istio中的策略规则和故障注入功能。它可以根据配置的策略规则，对流量进行控制和转发，实现灵活的访问控制和流量管理。同时，它还可以模拟故障情况，如延迟和错误响应，用于测试系统的容错能力和故障恢复策略。
6. 可扩展性和高可用性：Istiod具有良好的可扩展性和高可用性。它可以通过水平扩展来处理大规模的服务网格，并且支持多个Istiod实例的部署，以实现高可用性和故障转移。

总而言之，Istiod是Istio服务网格的核心组件，提供了配置管理、流量管理、安全策略、监控和遥测等功能，帮助用户实现可靠、安全和可观察的服务通信。

Istio 核心

官网参考：概念，官网文章很详细，此处小编只做总结。

1. 虚拟服务（Virtual Service）：
   虚拟服务定义了一组规则，用于将传入的请求路由到特定的目标服务。它可以基于请求的属性（如请求头、路径、权重等）进行路由，并允许进行流量拆分、负载均衡、超时设置等操作。通过虚拟服务，可以灵活地控制和管理服务之间的通信流量。
2. 目标规则（Destination Rule）：
   目标规则定义了对目标服务的一组规则，用于配置服务之间的通信行为。它可以指定服务的负载均衡策略、连接池设置、TLS设置等。目标规则允许您对服务进行细粒度的配置和管理，以满足性能、安全性和可靠性的需求。
3. Istio网关（Gateway）：
   Istio网关充当流量的入口和出口，用于将外部流量引入到服务网格中或将服务网格中的流量暴露给外部。它可以将外部请求路由到特定的虚拟服务，并提供负载均衡、TLS终止、流量控制等功能。Istio网关可以用于实现服务的边界控制和安全性。
4. 服务条目（Service Entry）：
   服务条目允许将外部服务或服务网格外部的服务引入到Istio中。它允许您定义对外部服务的访问规则，并将其视为Istio服务的一部分。通过服务条目，可以对外部服务进行流量管理、安全性配置和监控等操作。
5. 对等身份认证（Peer authentication）：
   对等身份认证用于确保在服务之间的通信中进行双向的身份验证和授权。它可以配置服务之间的TLS通信，并验证对等方的身份。通过对等身份认证，可以确保服务之间的通信是安全的，并防止未经授权的访问。
6. 授权策略（Authorization policies）：
   授权策略用于定义对服务的访问权限和控制规则。它可以基于请求的属性（如请求头、路径等）进行访问控制，并允许您定义允许或拒绝访问的规则。通过授权策略，可以对服务的访问进行细粒度的控制和保护。
   

流量管理

Istio 的流量路由规则可以让您很容易的控制服务之间的流量和 API 调用。 Istio 简化了服务级别属性的配置，比如熔断器、超时和重试，并且能轻松的设置重要的任务， 如 A/B 测试、金丝雀发布、基于流量百分比切分的分阶段发布等。它还提供了开箱即用的故障恢复特性， 有助于增强应用的健壮性，从而更好地应对被依赖的服务或网络发生故障的情况。
Istio 的流量管理模型源于和服务一起部署的 Envoy 代理。 网格内服务发送和接收的所有 data plane 流量都经由 Envoy 代理， 这让控制网格内的流量变得异常简单，而且不需要对服务做任何的更改。

流量管理包括以下功能：

• 动态服务发现、负载均衡、TLS 终端、HTTP/2 与 gRPC 代理、熔断器、健康检查、基于百分比流量分割的分阶段发布、故障注入、丰富的指标
  

安全

将单一应用程序分解为微服务可提供各种好处，包括更好的灵活性、 可伸缩性以及服务复用的能力。但是，微服务也有特殊的安全需求：

• 为了抵御中间人攻击，需要流量加密。
• 为了提供灵活的服务访问控制，需要双向 TLS 和细粒度的访问策略。
• 要确定谁在什么时候做了什么，需要审计工具。

Istio 安全功能提供了强大的身份、强大的策略、透明的 TLS 加密、 认证/授权/审计（AAA）工具来保护您的服务和数据。Istio 安全的目标是：

• 默认安全：应用程序代码和基础设施无需更改
• 深度防御：与现有安全系统集成以提供多层防御
• 零信任网络：在不受信任的网络上构建安全解决方案

主要特点是可以实现零信任网络中的服务之间通讯加密。Istio 通过自动为服务之间的通信提供双向 TLS 加密来增强安全性，同时 Istio 还提供了强大的身份验证、授权和审计功能。

可观测性

Istio 为网格内所有的服务通信生成详细的遥测数据。这种遥测技术提供了服务行为的可观测性， 使运维人员能够排查故障、维护和优化应用程序，而不会给服务的开发人员带来任何额外的负担。 通过 Istio，运维人员可以全面了解到受监控的服务如何与其他服务以及 Istio 组件进行交互。
Istio 生成以下类型的遥测数据，以提供对整个服务网格的可观测性：

• 指标。Istio 基于 4 个监控的黄金标识（延迟、流量、错误、饱和）生成了一系列服务指标。 Istio 还为网格控制平面提供了更详细的指标。 除此以外还提供了一组默认的基于这些指标的网格监控仪表板。
• 分布式追踪。Istio 为每个服务生成分布式追踪 span， 运维人员可以理解网格内服务的依赖和调用流程。
• 访问日志。当流量流入网格中的服务时， Istio 可以生成每个请求的完整记录，包括源和目标的元数据。 此信息使运维人员能够将服务行为的审查控制到单个工作负载实例的级别。

Istio 支持 Jaeger、Zipkin、Skywalking 等链路追踪中间件，支持 Prometheus 收集指标数据，然后日志功能没有上面亮点，只是记录了请求的 HTTP 地址之类。Istio 的可观测性帮助我们了解应用程序的性能和行为，使得故障检测、性能分析和容量规划变得更加简单。

Istio 原理

Istio原理是拦截 Kubernetes 部署 Pod 的事件，然后从 Pod 中注入一个名为 Envoy 的容器（如下右图），进出 Pod 的流量会被 “劫持” 到 Envoy 进行处理。由于所有流量都被 Envoy “劫持” 了，所以 Istio 可以对流量进行分析例如收集请求信息，以及一系列的流量管理操作，也可以验证授权信息。当 Envoy 拦截流量并执行一系列操作之后，如果请求没问题，就会转发流量到业务应用的 Pod 中。

总结一下，istio劫持了pod的流量，根据istio相关CRD配置后完成了相关治理，再转发给目的pod，这样就多了一层转发，会导致系统响应速度会有所下降，但是增加的响应时间几乎可以忽略不计。

每个 Pod 都有一个 Envoy 负责拦截、处理和转发进出 Pod 的所有网络流量，这种方式被称为 Sidecar。
以下是 Istio Sidecar 的一些主要功能：

• 流量管理：Envoy 代理可以根据 Istio 配置的路由规则（如 VirtualService 和 DestinationRule）实现流量的转发、分割和镜像等功能。
• 安全通信：Envoy 代理负责在服务之间建立安全的双向 TLS 连接，确保服务间通信的安全性。
• 遥测数据收集：Envoy 代理可以收集关于网络流量的详细遥测数据（如延迟、成功率等），并将这些数据上报给 Istio 的遥测组件，以便进行监控和分析。
• 策略执行：Envoy 代理可以根据 Istio 配置的策略规则（如 RateLimit 和 AuthorizationPolicy）执行限流、访问控制等策略。

由于 Pod 是通过 Envoy 暴露端口的，所有进出口流量都需要经过 Envoy 的检查，所以很容易判断访问来源，如果请求方不是在 Istio 中的服务，那么 Envoy 便会拒绝访问。

在 Istio 中，Envoy 这一块称为数据平面，而负责管理集群的 istiod 组件称为控制平面。

istio资源和k8s资源扭转关系

istio-ingressgateway

istio-ingressgateway （Istio Ingress Gateway ）类似 Kubernetes 的 Ingress ，是 Istio 控制外部流量进入 Kubernetes 的入口组件，istio-ingressgateway 作为一个入口点，允许从服务网格外部访问服务网格内部的服务，起到了类似 nginx、apisix 等入口网关的作用。
Istio Ingress Gateway 的主要包括以下作用：

• 接收集群外部的流量，并根据 Istio 的配置将请求路由到适当的内部服务（起到网关的作用）。
• 提供负载均衡和流量控制功能，包括请求路由、重试、超时、熔断等（流量治理）。
• 支持 TLS 配置，以便在流量进入服务网格之前进行加密（给域名配置证书）。
• 支持双向 TLS 身份验证，以提高服务网格的安全性（服务间通讯）。
• 提供 Metrics、Tracing 和 Logging 收集，以便更好地观察和监控流量（需要自己安装对应的组件）。

istio-ingressgateway 本身包含 Kubernetes Service 、Pod，通过暴露节点端口，外部可以通过节点端口将流量打入 istio-ingressgateway 的 Pod。

流量经过 Istio 分析后，流量通过负载均衡转发到其中一个 Pod。

Istio-Gateway

istio-ingressgateway 并不能直接转发流量到 Pod，它还需要进行一些配置。我们要为 productpage 创建一个站点，绑定对应的域名，这样外部访问 istio-ingressgateway 的端口时，istio-ingressgateway 才知道该将流量转发给谁。在 Istio 中，定义这种绑定关系的资源叫 Gateway。

VirtualService

虽然有了 Istio Gateway，但是我们还不能直接通过网关访问到前面部署的微服务，我们还需要创建 Istio VirtualService 将 Istio Gateway 跟对应的 Kubernetes Service 绑定起来，然后流量才能正式流向 Pod。

请一定要注意这里，流量实际并不会经过 Service 中，但是 VirtualService 需要通过 Service 来发现 Pod。

这里类似 nginx 配置反向代理，配置监听之后，还需要指向将请求映射到哪个地址。

server {
    listen      80;
    server_name example.org www.example.org;
    #...
}

location /some/path/ {
    proxy_pass http://A:9080;
}
1
2
3
4
5
6
7
8
9

VirtualService 的主要目标是为服务提供稳定的入口地址，并通过配置一系列的路由规则来控制流量在网格内的行为。

就以最简单的路由区配来说，Kubernetes Service 是不支持路由规则的，而 Istio 可以通过指定路由后缀中；Service 不支持流量分析，负载均衡只有轮询。而 Istio 利用 Service 来发现 Pod，然后直接将流量转发到 Pod 中，可以实现各种功能。

VirtualService 可以用于实现以下功能：

1. 请求路由：将请求路由到特定的服务或版本，例如将请求分发到不同版本的服务，以实现灰度发布或金丝雀发布。
2. 请求重试：为失败的请求配置重试策略，以提高服务的可用性。
3. 请求超时：设置请求的超时时间，以便在特定时间内没有得到响应时中断请求。
4. 请求镜像：将请求的副本发送到另一个服务，用于测试新版本的服务，而不影响实际的生产流量。
5. 流量分割：将流量按照特定的比例分发到不同的服务或版本，以实现流量控制。

DestinationRule

Istio VistualService 中可以限制外部能够访问的路由地址，而 DestinationRule 则可以配置访问的 Pod 策略。可以为 Istio VistualService 绑定一个 Istio DestinationRule，通过 DestinationRule 我们还可以定义版本子集等，通过更加丰富的策略转发流量。将流量转发到指定的版本。

参考内容：
Introduction · istio 服务网格入门与实践
istio资源介绍以及和kubernetes资源扭转关系