vlambda博客
学习文章列表

## 前言

这篇文章属于纯理论，所含内容如下，按需阅读：

- `Istio概念、服务网格、流量管理、istio架构（Envoy、Sidecar 、Istiod）`

- `虚拟服务(VirtualService)、路由规则、目标规则(DestinationRule)`

- `网关(Gateway)、网络弹性和测试（超时、重试、熔断器、故障注入）`

## Istio是什么？

- Istio是一个开源的`服务网格`，透明的接入到`分布式服务`中。它也是一个平台，集成任何`日志、遥测和策略系统`的 API 接口。

- Istio 成功高效地运行`分布式微服务架构`，并提供`保护、连接和监控`微服务的统一方法。

- Istio 有助于降低 `DevOps` 压力、`开发团队`的压力。

#### 服务网格是什么？

- 组成`微服务网络`

- 实现`服务之间的交互`

#### 应用场景

- `服务发现、负载均衡、故障恢复、度量和监控`

- `A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证`

#### 为什么使用Istio？

服务网格是通过`sidecar`（边车）代理服务实现，`控制平面`主要是对`sidecar`的配置和管理，这包括：

- 为` HTTP、gRPC、WebSocket` 和 `TCP 流量`自动负载均衡。

- 通过丰富的`路由规则、重试、故障转移和故障注入`对流量行为进行细粒度控制。

- 可插拔的策略层和配置 API，支持`访问控制、速率限制和配额`。

- 集群内（包括集群的入口和出口）所有流量的`自动化度量、日志记录`和`追踪`。

- 在具有强大的基于`身份验证和授权`的集群中实现安全的服务间通信。

Istio还`支持扩展`，满足你部署需求！

## 流量管理介绍

- Istio流量路由规则可以很容易的`控制服务之间的流量`和`API调用`。能实现`A/B测试、金丝雀发布、`基于`流量百分比`发布。

- 开箱即用的`故障恢复`特性，有助于`增强应用的健壮性`，从而更好地应对被依赖的服务或网络发生故障的情况。

- Istio 的流量管理由`Envoy`代理服务提供。网格内服务`发送和接收的所有流量`都由` Envoy 代理`处理，让控制网格内的流量变得异常简单，不需要对服务做更改。

为了在网格中导流，Istio 需要知道 `endpoint 在哪和属于哪个服务`。为了定位到`service registry(服务注册中心)`，Istio 会连接到一个服务发现系统。例如，如果您在 Kubernetes 集群上安装了 Istio，那么它将自动检测该集群中的服务和 endpoint（端点）。

使用此服务注册中心，`Envoy 代理`可以将流量定向到相关服务。大多数基于`微服务的应用程序`，每个服务的工作负载都有多个实例来处理流量，称为`负载均衡池`。默认情况下，Envoy 代理基于轮询调度在服务的负载均衡池内分发流量，按顺序请求发送给池中每个成员，一旦所有服务实例均接收过一次请求后，重新回到第一个池成员。

这些 API 也使用 Kubernetes 的自定义资源定义（CRDs）来声明，可以`使用 YAML 进行配置`。

## istio架构

Istio 服务网格 逻辑上分为`数据平面`和`控制平面`

- **`数据平面`**：Envoy代理被部署为`sidecar`，负责`协调和控制微服务`之间的通信，收集和报告所有网格流量的遥测数据。

- **`控制平面`**：管理并配置`Envoy代理`

#### Envoy

- `C++ 开发`的高性能代理，用于协调服务网格中所有服务的`入站和出站流量`。Envoy 代理是`唯一与数据平面流量交互`的 Istio 组件。<br>

Envoy 代理被`部署为服务的 Sidecar`，在逻辑上为服务增加了 Envoy 的许多内置特性，例如：

- `动态服务发现`

- `负载均衡`

- `TLS 终端`

- `HTTP/2 与 gRPC 代理`

- `熔断器`

- `健康检查`

- `基于百分比流量分割的分阶段发布`

- `故障注入`

- `丰富的指标`

#### Sidecar

- 允许 Istio 可以执行`策略决策`，提取丰富的`遥测数据`，接着将这些数据发送到`监视系统`以提供整个网格行为的信息。

- Sidecar 代理还允许`向 Istio 添加功能`，不需要重新设计架构或重写代码。

#### Istiod

- Istiod 提供`服务发现、配置和证书`管理。

- Istiod 将`控制流量`的`高级路由规则`转换为 Envoy 特定的配置，并在运行时传播给 Sidecar。

- Istiod 安全通过内置的`身份和凭证`管理，实现了强大的`服务对服务和终端用户`认证。

- Istiod 充当证书`授权（CA）`，生成证书以允许在数据平面中进行` mTLS 通信`。

## 虚拟服务(VirtualService)

- 配置`请求流量`到服务,基于`连通性和服务发现`能力。

- 每个虚拟服务包含`一组路由规则`。可以实现`负载均衡`、基于`不同版本流量百分比`路由。

#### 为什么使用虚拟服务？

虚拟服务在增强 Istio 流量管理方面，发挥着至关重要的作用，通过对`客户端请求与真实响应请求`的`目标工作负载`进行解耦来实现。

基于不同服务版本的`流量百分比`路由，实现`A/B 测试、金丝雀发布`。

#### 栗子

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: reviewsspec: hosts: - reviews http: - match: - headers: end-user: exact: jason route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v3

#### hosts字段

#### 路由规则

- `http` 字段包含虚拟服务的`路由规则`，用来描述`匹配条件和路由行为`，它们把 `HTTP/1.1、HTTP2 和 gRPC `等流量发送到` hosts `字段指定的目标

#### 匹配条件

示例中的第一个路由规则有一个条件，因此以 `match` 字段开始。在本例中，您希望此路由应用于来自` ”jason“ 用户`的所有请求，所以使用 `headers`、`end-user` 和 `exact` 字段选择适当的请求。

- match: - headers: end-user: exact: jason

#### Destination

route:- destination: host: reviews subset: v2

destination 片段还指定了 Kubernetes 服务的子集，将符合此规则条件的请求转入其中，本例中子集名称是 v2。

#### 路由规则优先级

路由规则按`从上到下`的顺序选择，虚拟服务中定义的`第一条规则有最高优先级`，不满足第一个路由规则的流量`均流向一个默认的目标`。

本例中：第二条规则没有 match 条件，直接将流量导向 v3 子集。

- route: - destination: host: reviews subset: v3

#### 路由规则的更多内容

可以在流量端口、header 字段、URI 等内容上设置匹配条件

匹配条件：

## 目标规则(DestinationRule)

应用场景：整个目的地服务或特定服务子集时定制 Envoy 的流量策略，负载均衡模型、TLS 安全模式或熔断器设置。

apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: my-destination-rulespec: host: my-svc trafficPolicy: loadBalancer: simple: RANDOM # 随机负载均衡器 subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 trafficPolicy: loadBalancer: simple: ROUND_ROBIN # 轮询负载均衡器 - name: v3 labels: version: v3

每个子集都是基于一个或多个 `labels` 定义的，标签应用于kubernetes集群中deployment控制器metadata字段来识别不同版本。

#### 负载均衡选项 

Istio 默认使用轮询的负载均衡策略，Istio 同时支持如下的负载均衡模型，可以在 `DestinationRule` 中为指定：

- 随机：请求以随机的方式转到池中的实例。

- 权重：请求根据指定的百分比转到实例。

- 最少请求：请求被转到最少被访问的实例。

## 网关(Gateway)

- 管理入站和出站流量，网关配置网格边界的独立 Envoy 代理，而不是服务工作负载的 sidecar 代理。

- Istio 网关可以配置 4-6 层的负载均衡属性，如对外暴露的端口、TLS 设置等

- 网关主要用于管理进入的流量

- Istio 提供了预先配置的网关代理（`istio-ingressgateway` 和 `istio-egressgateway`）

#### 栗子

apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata: name: ext-host-gwyspec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 443 name: https protocol: HTTPS hosts: - ext-host.example.com tls: mode: SIMPLE serverCertificate: /tmp/tls.crt privateKey: /tmp/tls.key

这个网关配置让 HTTPS 流量从 `ext-host.example.com` 通过 443 端口流入网格，但没有为请求指定任何路由规则。为想要工作的网关指定路由，您必须把网关绑定到虚拟服务上。

如下面的示例所示，使用虚拟服务的 `gateways` 字段进行设置：

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: virtual-svcspec: hosts: - ext-host.example.com gateways: - ext-host-gwy

然后就可以为出口流量配置带有路由规则的虚拟服务。

## Sidecar

默认情况下，Istio 让每个 Envoy 代理都可以访问和它关联工作负载的所有端口的请求，然后转发到对应的工作负载。

可以使用 sidecar配置做：

- `微调 `Envoy 代理接受的`端口和协议集`。

- `限制 `Envoy 代理可以`访问的服务集合`。

在较庞大的应用程序中`限制 sidecar 可达性`，配置每个代理能访问网格中的任意服务，可能会因为`高内存使用量`而影响网格的性能。

可以指定将 sidecar 配置应用于特定命名空间中的所有工作负载，或者使用 `workloadSelector` 选择特定的工作负载

例如，下面的 sidecar 配置将 `bookinfo` 命名空间中的所有服务配置为，仅能访问运行在相同命名空间和 Istio 控制平面中的服务：

apiVersion: networking.istio.io/v1alpha3kind: Sidecarmetadata: name: default namespace: bookinfospec: egress: - hosts: - "./*" - "istio-system/*"

## 网络弹性和测试

除了网格导流外，Istio 还提供了`故障恢复和故障注入`功能，您可以在运行时动态配置这些功能。使用这些特性可以让您的应用程序`运行稳定`，确保服务网格能够`容忍故障节点`，并防止局部故障级联影响到其他节点。

#### 超时

超时是 `Envoy 代理`等待来自`给服务答复`的时间，确保服务不会因为等待答复而`无限期的挂起`。HTTP 请求的`默认超时时间`是` 15 秒`，这意味着如果服务在 15 秒内没有响应，调用将失败。

为了找到`最佳超时设置`，Istio 允许使用虚拟服务，按服务轻松地动态调整超时，而不必修改您的业务代码。

栗子：

一个虚拟服务，对 ratings 服务的 v1 子集的调用，指定 `10 秒超时`时间

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: ratingsspec: hosts: - ratings http: - route: - destination: host: ratings subset: v1 timeout: 10s

#### 重试

服务为初始`调用失败`，`Envoy 代理`尝试连接服务的`最大次数`。确保调用不会因为`临时过载`的服务或网络等问题而永久失败。

重试之间的`间隔（25ms+）`是可变的，HTTP 请求的默认重试行为是在返回错误之前`重试两次`。

应用场景：与超时一样，Istio 默认的重试行为在延迟方面可能不适合您的应用程序需求（对失败的服务进行过多的重试会降低速度）或可用性。

#### 栗子

配置了在初始`调用失败`后,最多`重试 3 次`来连接到服务子集，每个重试都有 2 秒的超时。

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: ratingsspec: hosts: - ratings http: - route: - destination: host: ratings subset: v1 retries: attempts: 3 perTryTimeout: 2s

#### 熔断器

熔断器中，设置一个对服务中`单个主机调用的限制`，例如并发连接的数量或对该主机`调用失败的次数`。一旦限制被触发，熔断器就会`“跳闸”`并停止连接到该主机。

作用：使用`熔断模式`可以快速失败而不必让客户端尝试连接到`过载或有故障`的主机。

#### 栗子：

将 v1 子集的`reviews`服务工作负载的并发连接数限制为 100：

apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: reviewsspec: host: reviews subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: tcp: maxConnections: 100

#### 故障注入

是什么：可以使用 Istio 的`故障注入`机制来为整个应用程序`测试故障恢复能力`。

为什么使用：故障注入是一种将错误引入系统以确保系统能够承受并从`错误条件`中恢复的测试方法。

作用：使用故障注入特别有用，能确保`故障恢复策略`不至于不兼容或者太严格，这会导致关键服务不可用。

可以注入两种故障，都使用虚拟服务配置：

- `延迟`：延迟是时间故障。它们模拟增加的网络延迟或一个超载的上游服务。

- `终止`：终止是崩溃失败。他们模仿上游服务的失败。终止通常以 HTTP 错误码或 TCP 连接失败的形式出现。

#### 栗子：

千分之一访问`ratings` 服务的请求，配置了一个 5 秒的延迟：

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: ratingsspec: hosts: - ratings http: - fault: delay: percentage: value: 0.1 fixedDelay: 5s route: - destination: host: ratings subset: v1

#### 和您的应用程序一起运行

`Istio 故障恢复`功能对应用程序来说是`完全透明`的。在返回响应之前，应用程序不知道 Envoy sidecar 代理是否正在`处理被调用服务的故障`。这意味着，如果在应用程序代码中设置了故障恢复策略，那么您需要记住这两个策略都是独立工作的，否则会发生冲突。

例如，假设您设置了两个超时，一个在虚拟服务中配置，另一个在应用程序中配置。`应用程序为服务`的 API 调用设置了 2 秒超时。而您在`虚拟服务`中配置了一个 3 秒超时和重试。在这种情况下，应用程序的超时会先生效，因此 Envoy 的超时和重试尝试会失效。

虽然 Istio 故障恢复特性提高了网格中服务的`可靠性和可用性`，但应用程序必须处理故障或错误并采取适当的回退操作。例如，当负载均衡中的所有实例都失败时，Envoy 返回一个`HTTP 503`代码。应用程序必须实现回退逻辑来处理`HTTP 503`错误代码。

## 总结

这篇花费了不少精力，还望博友们支持支持新人！！！

后期会发布一篇实际操作，期待大家持续关注！！！