istio架构设计及核心特性

Posted on Edited on

要想企业级使用istio，必须要了解其架构和核心实现原理，在出现问题时候才能快速定位问题……

在istio的架构上逻辑上分为一个数据平面和一个控制平面……

目前三种服务模式

  1. 集中式代理

    比如nginx反向代理，负载均衡

  2. 嵌入式代理

    基于SpringCloud中Eureka-client.jar，nacos discovery.jar等

    语言绑定，java

    需要开发维护，比如eureka中的重试机制

  3. 主机独立进程代理

    沉淀到底层，sidecar模式

本文档内容基于Istio1.8版本

Architecture

​ https://www.processon.com/view/link/5fe9a983e401fd549c95380d

概念

在istio的架构上逻辑上分为一个数据平面和一个控制平面

  • 数据平面

    有一组部署为边车的智能代理(Envoy)组成，这些代理控制着微服务之间的所有网络通信，它们还收集和报告所有网状流量的遥测数据

  • 控制平面

    负责管理和配置代理服务器路由流量

  • Envoy

    Istio使用的是Envoy代理的扩展版本。Envoy是一个用C++开发的高性能代理，用于调解服务网中所有服务的所有入站和出站流量。Envoy代理是唯一与数据平面流量交互的Istio组件；Envoy代理是作为服务的边车部署的，通过Envoy的许多内置功能逻辑上增强了服务的功能。如

    动态服务发现
    负载均衡
    TLS终止
    HTTP/2和gRPC代理
    断路器
    健康检查
    按百分比划分流量
    故障注入
    丰富的指标
    这种sidecar部署允许Istio执行策略决策，并提取丰富的遥测数据，这些数据可以发送到监控系统，以提供有关整个网格内行为的信息。

    Envoy代理启用的一些istio功能和任务包括：

    流量控制功能：通过丰富的设置路由规则对http、gRPC、WebSocket和TCP流量实施精细的流量控制。

    网络弹性功能：设置重试、故障切换、路由器、故障注入。

    安全和认证功能：执行安全策略，并通过配置API定义访问控制和速率限制

    基于WebAssembly的可插拔扩展模型，允许自定义策略执行和网格流量的遥测生成

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

    Istiod将控制流量行为的高级路由规则转换成Envoy特有识别的配置，并在运行时将其传给sidecars。Pilot将特定与平台的服务发现机制抽象出来，并将其合成标准格式，可以使任何符合Envoy API的边车都可以使用

    Istio可以支持多种环境的服务发现如kubernetes或者VMs等

    可以使用Istio的流量管理的API来命令Istiod完善Envoy配置，以便于对服务网格中的流量进行更细粒度的控制

    Istiod的安全性通过内置的身份和凭证管理实现强大的服务到服务和终端用户的认证。您可以使用Istio升级服务网格中未加密的流量，使用Istio操作者可以基于服务身份而不是相对不稳定的3层或4层网络标识符来执行策略，此外还可以使用Istio的授权功能来控制水可以访问您的服务。

    Istiod作为一个证书授权机构（CA）并生成证书，为了允许在数据平面上进行安全的mTLS通信

  • 南北流量管理/东西流量管理

    使用Ingress将Kubernetes中应用暴露成对外提供的服务，针对这个对外暴露的服务可以实现灰度发布，流量管理等，我们把这种流量管理称之为南北流向的流量管理，也就是入口请求到集群服务的流量管理

    Istio是侧重于集群内服务之间的东西向流量管理，或者称之为服务网格之间的流量管理

应用特性

流量管理

istio的流量路由规则可以让你轻松的控制服务之间的流量和API的调用，Istio简化了服务级属性的配置，如断路器，超时和重试，并使其易于设置重要的任务如A/B测试、金丝雀服务发布的推出和基于百分比流量分割推出，它还提供了开箱即用的故障恢复功能，有助于使你 的应用更健壮，以应对以来服务或网络的失败故障。

Istio的流量管理模型依赖于与您的服务一起部署Envoy代理，您的Mesh服务发送和接受的所有流量（数据平面流量）都通过Envoy进行代理，因此可以轻松引导和控制mesh周围的流量，而无需对您的服务进行任何的更改

Istio为了填充自己的服务注册表，Istio会连接到一个服务发现系统，如果你在kubernetes集群上安装了Istio，那么Istio会自动检测到该集群中的服务和端点，利用这个服务注册表，Envoy代理就可以将流量引导到相关服务。大多数基于微服务的应用都有每个服务工作负载的多个实例来处理服务流量，这个被称作负载均衡池，默认情况下，Envoy代理使用循环模式在每个服务的负载均衡池中分配流量。

虽然istio的基本服务发现和负载均衡提供了一个可行的服务网状结构，但着远远不是Istio能做的全部，比如有时候你可能还希望对网格流量进行更精细的控制如：

​ 将特定的比例的流量引导到新版本的服务，作为A/B测试的一部分

​ 或者对特定服务实例子集的流量应用不同的负载均衡策略

​ 对进入或流出网格的流量应用特殊规则

这些操作都可以通过使用Istio的流量管理API向Istio添加对应的流量配置来完成所有这些工作；API使用Kubernetes自定义资源CRD来指定，你可以使用YAML来配置

这些资源如下：

  • Virtual services
  • Destination rules
  • Gateways
  • Service entries
  • Sidecars

Virtual services

​ 虚拟服务和目标规则是Istio流量路由功能的关键的构件，通过虚拟服务，可以在istio和平台提供的基本的连接和发现的基础上，配置如何将请求路由到Istio服务网格内的服务；每个虚拟服务有一组路由规则组成，这些规则按顺序进行评估，让Istio将每个给定的请求匹配到虚拟服务的网格中的特定的实际目的地。

​ 在没有虚拟服务的情况下，Envoy会在所有服务实例之间使用循环负载均衡来分配流量，如介绍中所述。你可以通过你对工作负载的了解来改进这种行为。例如，一些人可能代表不同的版本。这在 A/B 测试中很有用，您可能希望根据不同服务版本的百分比来配置流量路由，或者将内部用户的流量引导到特定的实例集。

​ 通过虚拟服务，您可以为一个或多个主机名指定流量行为。您可以在虚拟服务中使用路由规则，告诉 Envoy 如何将虚拟服务的流量发送到适当的目的地。路由目的地可以是同一服务的版本或完全不同的服务。

​ 一个典型的用例是将流量发送到服务的不同版本，指定为服务子集。客户端将请求发送到虚拟服务主机，就像它是一个单一实体一样，然后Envoy根据虚拟服务规则将流量路由到不同的版本：例如，”20%的呼叫转到新版本 “或 “这些用户的呼叫转到版本2”。例如，这允许你创建一个金丝雀式的推广，你可以逐渐增加发送到新服务版本的流量比例。流量路由与实例部署完全分离，这意味着实施新服务版本的实例数量可以根据流量负载进行伸缩，而完全不用参考流量路由。相比之下，像Kubernetes这样的容器编排平台只支持基于实例扩展的流量分配，这很快就会变得复杂。

​ 通过一个虚拟服务来解决多个应用服务。例如，如果您的网状结构使用Kubernetes，您可以配置一个虚拟服务来处理特定命名空间中的所有服务。将单个虚拟服务映射到多个 “真正的 “服务，在促进将一个单体应用转化为由不同微服务构建的复合服务方面特别有用。

例子1：

请求中包含特定用户来路由到不同版本的服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

​ http 部分包含虚拟服务的路由规则，描述了将 HTTP/1.1、HTTP2 和 gRPC 流量发送到 hosts 字段中指定的目的地的匹配条件和操作（您还可以使用 tcp 和 tls 部分来配置 TCP 和 unterminated TLS 流量的路由规则）。一个路由规则由你希望流量到达的目的地和零个或多个匹配条件组成

​ 路由部分的目的地字段指定了符合此条件的流量的实际目的地。与虚拟服务的主机不同，目的地的主机必须是存在于 Istio 服务注册表中的真实目的地，否则 Envoy 将不知道将流量发送到哪里。这可以是一个带有代理的网状服务，也可以是一个使用服务条目添加的非网状服务

​ 目标部分还指定了你想让符合这个规则条件的请求转到这个Kubernetes服务的哪个子集，你将在下面的目的规则部分看到如何定义服务子集。

​ 路由规则从上到下按顺序评估，虚拟服务定义中的第一条规则被赋予最高优先级。在这种情况下，你希望任何不匹配第一条路由规则的东西都会转到第二个规则中指定的默认目的地。正因为如此，第二条规则没有匹配条件，只是将流量引导到v3子集。

​ 建议提供一个默认的 “无条件 “或基于权重的规则（如下所述）作为每个虚拟服务中的最后一条规则，以确保流向虚拟服务的流量总是至少有一条匹配的路由。

例子2:

还可以设置匹配条件：流量端口，header域，urls，如下面例子虚拟服务就是将流量根据url的不同来分配到不同的两个独立服务

对于一些匹配条件，您还可以选择使用精确值、前缀或regex来选择它们

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - bookinfo.com
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    - destination:
        host: reviews
  - match:
    - uri:
        prefix: /ratings
    route:
    - destination:
        host: ratings

除了使用匹配条件外，您还可以按百分比 “权重 “分配流量。这对A/B测试和金丝雀部署很有用。

1
2
3
4
5
6
7
8
9
10
11
12
13
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75
    - destination:
        host: reviews
        subset: v2
      weight: 25

还可以使用路由规则对流量执行一些操作：

  • 添加和删除头信息

  • 重写url

  • 对调用的目的地设置重试策略

具体写法see the HTTPRoute reference

Destination rules

除了虚拟服务，目标规则也是Istio流量路由功能的一个关键部分。您可以将虚拟服务视为将流量路由到给定目的地的方式，然后使用目的地规则来配置该目的地的流量。目的地规则是在评估了虚拟服务路由规则后应用的，因此它们适用于流量的 “真实 “目的地。

特别是，您可以使用目标规则来指定命名的服务子集，例如按版本对所有给定服务的实例进行分组。然后，您可以在虚拟服务的路由规则中使用这些服务子集来控制流向您的服务的不同实例的流量。

目标规则还允许您在调用整个目标服务或特定服务子集时自定义 Envoy 的流量策略，例如您首选的负载平衡模式、TLS 安全模式或断路器设置。您可以在目的地规则参考中查看目的地规则选项的完整列表。

  • 负载均衡选项 (Load balancing options)

    默认情况下，Istio使用的是循环负载均衡策略，实例池中的每个服务实例都会依次获得请求。Istio还支持以下模式，您可以在目标规则中指定对特定服务或服务子集的请求。

    (1)Random 随机模式

    (2)Weighted 加权模式将请求转发到池中的实例。根据特定百分比将请求转发到池中的实例。

    (3)Least request:最少请求，将请求转发给请求数量最少的实例

​ 详细的选项参考See the Envoy load balancing documentation

列子：my-svc目标服务配置了单个不同子集，具有不同的负载均衡策略

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  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

​ 除了定义子集之外，这个目标规则既有针对这个目标中所有子集的默认流量策略，也有仅针对该子集的子集特定策略，将其覆盖。默认策略在子集字段上方定义，为v1和v3子集设置一个简单的随机负载均衡器。在v2策略中，在相应子集的字段中指定了循环负载均衡器。

配置选项的关联图：

image-20201230093419149

Gateways

​ 您可以使用网关来管理网状网络的入站和出站流量，让您指定哪些流量要进入或离开网状网络。网关配置适用于在网格边缘运行的独立 Envoy 代理，而不是与服务工作负载一起运行的侧车 Envoy 代理。

​ 与控制进入系统的流量的其他机制（如Kubernetes Ingress API）不同，Istio网关让您可以使用Istio流量路由的全部功能和灵活性。你可以做到这一点，因为Istio的网关资源只是让你配置4-6层的负载均衡属性，如要暴露的端口、TLS设置等。然后，你不需要将应用层流量路由（L7）添加到同一个API资源中，而是将一个常规的Istio虚拟服务绑定到网关上。这让你基本上可以像Istio网状网络中的其他数据平面流量一样管理网关流量。

​ 网关主要用于管理入口流量，但您也可以配置出口网关。出口网关可以让您为离开网状网的流量配置一个专用的出口节点，让您限制哪些服务可以或应该访问外部网络，或者实现出口流量的安全控制，以增加网状网的安全性，例如。您也可以使用网关来配置一个纯粹的内部代理。

​ Istio提供了一些预配置的网关代理部署（istio-ingressgateway和istio-egressgateway）

例子：外部的HTTPS入口流量的网关配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    app: my-gateway-controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      credentialName: ext-host-cert
          
---

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
  - ext-host-gwy

以上还可以给virtual service配置带有路由规则的虚拟服务

Service entries

您可以使用服务条目向 Istio 内部维护的服务注册表添加条目。添加服务条目后，Envoy 代理可以向该服务发送流量，就像该服务是您网状网络中的服务一样。通过配置服务条目，您可以管理在网状网络之外运行的服务的流量，包括以下任务:

  • 为外部目的地重定向和转发流量，例如从网络上消费的 API，或到传统基础设施中服务的流量。
  • 为外部目的地定义重试、超时和故障注入策略。
  • 通过将虚拟机添加到您的网格中，在虚拟机（VM）中运行网格服务。
  • 将来自不同集群的服务逻辑地添加到mesh中，以在Kubernetes上配置多集群Istio mesh。

注意：不需要为您希望您的网格服务使用的每个外部服务添加服务条目。默认情况下，Istio会将Envoy代理配置为将请求传递给未知服务。但是，你不能使用Istio功能来控制前往未在Mesh中注册的目的地的流量

例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - ext-svc.example.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

您可以使用hosts字段指定外部资源。您可以完全限定它或使用通配符前缀域名。

您可以配置虚拟服务和目标规则，以更细化的方式控制到服务条目的流量，就像您配置网状网络中任何其他服务的流量一样。例如，以下目的规则将流量路由配置为使用相互 TLS 来确保与我们使用服务条目配置的 ext-svc.example.com 外部服务的连接。

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ext-res-dr
spec:
  host: ext-svc.example.com
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

更详细配置See the Service Entry reference

Sidecars

默认情况下，Istio 会将每个 Envoy 代理配置为接受其关联工作负载的所有端口上的流量，并在转发流量时到达网格中的每个工作负载。您可以使用sidecar配置来完成以下工作:

  • 微调Envoy代理接受的端口和协议集。
  • 限制 Envoy 代理服务器可以到达的服务集。

在大型应用中，您可能需要这样限制sidecar的可到达性，因为在大型应用中，如果每个代理都被配置为可到达网状网络中的其他服务，那么由于内存占用率高，可能会影响网状网络的性能

可以指定您希望 sidecar 配置应用于特定命名空间中的所有工作负载，或者使用 workloadSelector 选择特定的工作负载。例如，以下 sidecar 配置将 bookinfo 命名空间中的所有服务配置为只到达运行在同一命名空间和 Istio 控制平面中的服务

1
2
3
4
5
6
7
8
9
10
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: bookinfo
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

See the Sidecar reference for more details

Ingress

kubernetes中是使用Ingress资源来指定需要暴露到集群外的服务，在istio服务网格中，使用一种新的配置模型——stio Gateway

Ingress Gateway是来描述运行在网格边界的负载均衡器，负责接收入口HTTP/TCP连接，其中配置了对外暴露的端口，协议等，但是不想kubernetes中Ingress资源，Ingress Gateway不包含任何流量路由配置，它的流量路由使用istio路由规则来配置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "httpbin.example.com"

为通过Gateway的入口流量配置路由：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - "httpbin.example.com"
  gateways:
  - httpbin-gateway
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: /delay
    route:
    - destination:
        port:
          number: 8000
        host: httpbin

Network resilience and testing

为了帮助管理网格周围的流量，Istio还提供了可选择的故障恢复和故障注入功能，你可以在运行时动态配置这些功能。使用这些功能可以帮助您的应用程序可靠的运行，确保服务网格能够容忍故障节点，并防止局部故障传递到其它节点

Timeouts：

超时是指Envoy代理应该等待给定服务回复的时间，以确保服务不会无限期地等待回复，并确保呼叫在可预测的时间范围内成功或失败。Istio中默认禁用HTTP请求的Envoy超时。

对于某些应用程序和服务，Istio的默认超时可能不合适。例如，过长的超时可能会导致等待失败服务的回复而产生过长的延迟，而过短的超时可能会导致在等待涉及多个服务的操作返回时，不必要的调用失败。为了找到并使用您的最佳超时设置，Istio让您可以轻松地使用虚拟服务在每个服务的基础上动态调整超时，而无需编辑您的服务代码。下面是一个虚拟服务，它为调用评级服务的v1子集指定了10秒的超时。

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10s
Retries

重试设置指定了Envoy代理在首次呼叫失败时尝试连接服务的最大次数。重试可以确保呼叫不会因为服务或网络暂时超载等短暂问题而永久失败，从而提高服务可用性和应用性能。重试之间的间隔（25ms+）是可变的，由Istio自动决定，防止被叫服务被请求淹没。HTTP请求的默认重试行为是在返回错误之前重试两次。

和超时一样，Istio的默认重试行为可能在延迟（对失败的服务重试次数过多会使事情变慢）或可用性方面不适合你的应用需求。同样和超时一样，您可以在虚拟服务中以每个服务为基础调整重试设置，而无需接触您的服务代码。您还可以通过添加每次重试超时来进一步完善重试行为，指定每次重试尝试成功连接到服务时需要等待的时间。下面的示例配置了最多 3 次重试，以在初始调用失败后连接到该服务子集，每次重试的超时时间为 2 秒。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s
Circuit breakers

断路器是Istio为创建基于微服务的弹性应用提供的另一种有用机制。在断路器中，您可以为服务中的各个主机的调用设置限制，例如并发连接的数量或对该主机的调用失败的次数。一旦达到该限制，断路器就会 “跳闸”，停止与该主机的进一步连接。使用断路器模式可以实现快速故障，而不是客户端试图连接到过载或失败的主机。

由于断路适用于负载均衡池中的 “真实 “网状目的地，您可以在目的地规则中配置断路器阈值，设置适用于服务中的每个单独主机。以下示例将 v1 子集的 reviews 服务工作负载的并发连接数限制为 100

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100
Fault injection

在您配置好网络，包括故障恢复策略后，您可以使用Istio的故障注入机制来测试整个应用的故障恢复能力。故障注入是一种将错误引入系统的测试方法，以确保系统能够承受并从错误条件下恢复。使用故障注入可以特别有用，以确保你的故障恢复策略不会不兼容或限制性太强，有可能导致关键服务不可用。

与其他在网络层引入错误的机制（如延迟数据包或杀死豆荚）不同，Istio’让您在应用层注入故障。这让您可以注入更相关的故障，如HTTP错误代码，以获得更相关的结果。

您可以注入两种类型的故障，都是使用虚拟服务配置的。

延迟 延迟是定时故障。它们模仿网络延迟增加或上游服务过载。
终止。终止是一种崩溃故障 它们模仿上游服务的故障。终止通常表现为HTTP错误代码或TCP连接失败的形式。
例如，这个虚拟服务在每1000个请求中，有1个请求会对评级服务引入5秒的延迟。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percentage:
          value: 0.1
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1

说明：

Istio故障恢复功能对应用程序完全透明。应用程序在返回响应之前，并不知道Envoy sidecar代理是否在处理被调用服务的故障。这意味着，如果你在应用代码中也设置了故障恢复策略，你需要记住，两者是独立工作的，因此可能会发生冲突。例如，假设你可以有两个超时，一个配置在虚拟服务中，另一个配置在应用程序中。应用程序为服务的API调用设置了2秒的超时。然而，你在虚拟服务中配置了一个3秒的超时和1次重试。在这种情况下，应用程序的超时首先启动，所以你的Envoy超时和重试尝试没有效果。

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

流量管理应用的总结

​ 路由：流量转移（蓝绿、灰度、ab测试）

​ 弹性能力：超时、重试、熔断

​ 调试：故障注入、流量镜像

​ 说明：

​ 流量转移

​ 此功能说明：我们使用 Istio 的权重路由功能将流量从旧版本的服务迁移到新版本。 请注意，这和使用容器编排平台的部署功能来进行版本迁移完全不同，后者使用了实例扩容来对流量进行管理

​ 使用 Istio，两个版本的服务可以独立地进行扩容和缩容，而不会影响这两个服务版本之间的流量分发。

​ 流量镜像

​ 此概念说一下，流量镜像，也称为影子流量，TCP流量copy等，镜像会将实时流量的副本发送到镜像服务。这个镜像服务可以是其他另外一个版本指定，可以通过这个镜像流量我们分析高并发产生的问题等

​ Envoy中日志：流量五元祖

​ downstream:自己pod ip

​ upstream：目标pod ip

​ upstream_cluster：生产者的集群

​ 理解上述，要知道上下游的概念，大白话解释，上游就是当前服务调用谁，谁就是上游，反之就是下游

​ 下述两个参数概念，是针对sidecar参照来说，谁指挥它就是上游，反之就是下游来理解

​ upstream_local_address ：当前pod ip

​ downstream_local_address ： 目标服务ip

​

可观测性

Istio为网格内的所有服务通信生成详细的遥测数据，这种遥测数据提供了服务行为的可观察性，使操作者能够在不给服务开发人员带来任何额外负担的情况下，对其应用程序进行故障排除、维护和优化。通过Istio，操作者可以全面的了解被监控的服务如何与其它服务和Istio组件本身进行交互。

Istio会生成以下类型的遥测信息，以提供整体服务网格的可观察性：

  • 指标 Metrics

    Istio根据监控的四个“黄金信号”（延迟、流量、错误和饱和度）生成一组服务指标，Istio还提供了网格控制平面的详细指标，另外还提供了一套默认的建立在这些指标之上的网格监控仪表盘。

  • 分布式跟踪

    Istio为每个服务生成分布式跟踪跨度，让操作者详细了解网格内调用流和服务依赖性

  • 访问日志

    当流量流入网格内的服务时，Istio可以生成每个请求的完整记录，包括源和目标元数据。这些信息使操作者能够对服务行为进行审计，直至单个工作负载实例级别

Metrics

为了监控服务行为，Istio为所有进入、流出和在Istio服务网格内的服务流量生成指标。这些指标提供了有关行为的信息，如总流量、流量中的错误率和请求的响应时间。

除了监控网状结构内的服务行为外，监控网状结构本身的行为也很重要。Istio组件会导出自身内部行为的指标，以深入了解Mesh控制平面的健康和功能。

  • Proxy-level metrics 代理级指标

    Istio的度量收集始于sidecar代理（Envoy）。每个代理都会生成一套丰富的关于所有通过代理的流量（包括入站和出站）的指标。代理商还提供有关代理本身的管理功能的详细统计数据，包括配置和健康信息。

    Envoy生成的指标提供了对Envoy资源（如监听器和集群）粒度的网状结构的监控。因此，在监控Envoy指标时，需要了解网状服务和Envoy资源之间的联系。

    Istio使运营商能够选择在每个工作负载实例中生成和收集哪些Envoy指标。默认情况下，Istio只启用Envoy生成的一小部分统计数据，以避免指标后端不堪重负，并减少与指标收集相关的CPU开销。但是，操作者可以在需要时轻松扩展收集的代理指标集。这样可以有针对性地调试网络行为，同时降低整个网状网络的监控成本。

    Envoy文档网站上有关于Envoy统计收集的详细介绍。Envoy统计的操作指南提供了更多关于控制代理级指标生成的信息

    例子：Proxy-level metrics

    1
    2
    3
    4
    5
    6
    7
    8
    9
    envoy_cluster_internal_upstream_rq{response_code_class="2xx",cluster_name="xds-grpc"} 7163

    envoy_cluster_upstream_rq_completed{cluster_name="xds-grpc"} 7164

    envoy_cluster_ssl_connection_error{cluster_name="xds-grpc"} 0

    envoy_cluster_lb_subsets_removed{cluster_name="xds-grpc"} 0

    envoy_cluster_internal_upstream_rq{response_code="503",cluster_name="xds-grpc"} 1

  • Service-level metrics 服务级指标

    除了代理级指标，Istio还提供了一套面向服务的指标来监控服务通信。这些指标涵盖了四个基本的服务监控需求：延迟、流量、错误和饱和度。Istio提供了一套默认的仪表盘，用于监控基于这些指标的服务行为。

    标准的 Istio 指标默认导出到 Prometheus。

    服务级指标的使用完全是可选的。操作者可以选择关闭这些指标的生成和收集，以满足其个人需求。

    例子：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    istio_requests_total{
      connection_security_policy="mutual_tls",
      destination_app="details",
      destination_canonical_service="details",
      destination_canonical_revision="v1",
      destination_principal="cluster.local/ns/default/sa/default",
      destination_service="details.default.svc.cluster.local",
      destination_service_name="details",
      destination_service_namespace="default",
      destination_version="v1",
      destination_workload="details-v1",
      destination_workload_namespace="default",
      reporter="destination",
      request_protocol="http",
      response_code="200",
      response_flags="-",
      source_app="productpage",
      source_canonical_service="productpage",
      source_canonical_revision="v1",
      source_principal="cluster.local/ns/default/sa/default",
      source_version="v1",
      source_workload="productpage-v1",
      source_workload_namespace="default"
    } 214

  • Control plane metrics 控制平面指标

    Istio控制平面还提供了一系列自我监控指标，这些指标允许监控Istio本身的行为

​ 更多的指标参考 please refer to the reference documentation.

Distributed triaces

分布式跟踪提供了一种通过监控单个请求流经网格时监控和获悉行为的方法。跟踪使网格操作者能够了解服务依赖性和服务网格内的延迟来源。

Istio通过Envoy代理支持分布式跟踪，这些代理可以代表它们代理的应用自动生成跟踪跨度，只需要应用转发适当的请求上下文即可。

Istio支持许多追踪后端，包括zipkin、jaeger、Lightstep和Datadog。操作者可以控制跟踪生成的采样率（即每个请求生成跟踪数据的速度），这使得操作者可以控制为它们的网格生成跟踪数据的数量和速率。

Access logs

访问日志提供了一种从单个工作负载实例的角度监控和了解行为的方法。

Istio可以以一套可配置的格式为服务流量生成访问日志，使操作者可以完全控制记录的方式、内容、时间、地点

例子：访问日志

1
[2019-03-06T09:31:27.360Z] "GET /status/418 HTTP/1.1" 418 - "-" 0 135 5 2 "-" "curl/7.60.0" "d209e46f-9ed5-9b61-bbdd-43e22662702a" "httpbin:8000" "127.0.0.1:80" inbound|8000|http|httpbin.default.svc.cluster.local - 172.30.146.73:80 172.30.146.82:38618 outbound_.8000_._.httpbin.default.svc.cluster.local