05流量管理原理

介绍 Istio 流量管理

https://istio.io/latest/docs/concepts/traffic-management/

1. VirtualService虚拟服务案例

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews        //虚拟主机，也可以是IP地址
  http:
  - match:        //匹配的条件
    - headers:
        end-user:
          exact: jason    //exact精确，prefix前缀，regex正则3中，自己查看
    route:            //路由到
    - destination:     //目的地，host，port，subnet
        host: reviews    //服务
        subset: v2			//服务的子服务名字
  - route:
    - destination:
        host: reviews
        subset: v3

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

• 随机：请求被随机转发到池中的实例
• 权重：请求根据特定的百分比被转发到池中的实例。
• 最小请求：请求被转发给请求数量最少的实例。

针对每个负载的详情信息，参考链接

2. Destination rule 案例

下面的示例目标规则使用不同的负载平衡策略为my-svc目标服务配置三个不同的子集:

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

每个子集都是基于一个或多个标签定义的，在Kubernetes中，这些标签是附加到对象(如Pods)上的键/值对。这些标签在Kubernetes服务的部署中作为元数据应用，以识别不同的版本。

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

3.Gateway案例：

下面的例子显示了一个可能的网关配置为外部HTTPS进入流量:

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
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

此网关配置允许来自ext-host.example.com的HTTPS流量进入端口443上的网格，但不为流量指定任何路由。

要指定路由并使网关按预期工作，还必须将网关绑定到虚拟服务。您可以使用虚拟服务的网关字段来实现这一点，如下面的示例所示:

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

然后可以使用外部通信流的路由规则配置虚拟服务。

先进入istio-ingressgateway，再进入Gateway，再到VirtualService（路由匹配，负载轮询），再到istio-egressgateway流量流出

4.服务条目案例

您可以使用一个服务条目来将一个条目添加到Istio内部维护的服务注册表中。在您添**加服务条目之后，envoy代理可以向服务发送流量，就好像它是您网格中的服务一样。**配置服务条目允许您管理网格外运行的服务的流量，包括以下任务:

重定向和转发外部目的地的流量,例如从 Web 使用的 API ,或将流量转发到遗留基础设施中的服务。
为外部目标定义重试、超时和错误注入策略。
通过将 VM 添加到网格中,在虚拟机( VM )中运行网格服务。
在逻辑上将来自不同集群的服务添加到网格中,以便在 Kuber netes 上配置多集群 Is tio 网格

您不需要为您希望mesh服务使用的每个外部服务添加一个服务条目。默认情况下，Istio将envoy代理配置为将请求传递给未知服务。然而，你不能使用Istio功能来控制没有在mesh中注册的目的地的流量。

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - www.baidu.com			//指定外部资源。您可以完全限定它或使用通配符前缀的域名。
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS          //www.baidu.com将在内部的DNS解析

配置虚拟服务和目标规则，以更细粒度的方式控制到服务条目的流量，与为网格中的任何其他服务配置流量的方式相同。例如，下面的目的地规则配置流量路由，以使用相互TLS来保护到ext-svc.example.com外部服务的连接，我们使用服务条目配置了该连接:

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

更多关于服务条目参考链接

sidecar

默认情况下，Istio配置每个envoy代理来接受其相关工作负载的所有端口上的流量，并在转发流量时到达网格中的每个工作负载。你可以使用sidecar配置做以下事情:

• 微调envoy代理接受的端口和协议集。

• 限制envoy代理可以访问的服务集。

您可能希望在较大的应用程序中限制这样的sidecar可达性，因为配置每个代理来访问网格中的每个其他服务可能会由于高内存使用量而潜在地影响网格性能。

您可以指定希望将sidecar配置应用于特定名称空间中的所有工作负载，或者使用workloadSelector选择特定的工作负载。例如，下面的sidecar配置将bookinfo名称空间中的所有服务配置为只访问在相同名称空间和Istio控制平面中运行的服务(目前需要使用Istio的策略和遥测功能):

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: bookinfo
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

更多关于sidecar的内容参考：参考链接

除了帮助您引导网格周围的通信之外，Istio还提供了可选的故障恢复和故障注入功能，您可以在运行时动态配置这些功能。使用这些特性可以帮助您的应用程序可靠地运行，确保服务网格能够容忍故障节点，并防止局部故障级联到其他节点。

1. 超时

超时是envoy代理应该等待来自给定服务的答复的时间量，以确保服务不会无限期地等待答复，并确保调用在可预测的时间范围内成功或失败。HTTP请求的默认超时时间是15秒，这意味着如果服务在15秒内没有响应，调用将失败。

对于某些应用程序和服务，Istio的缺省超时可能不太合适。例如，超时太长可能导致等待失败服务的响应的延迟过大，而超时太短可能导致在等待涉及多个服务的操作返回时调用不必要地失败。为了找到并使用您的最佳超时设置，Istio允许您使用虚拟服务轻松地在每个服务的基础上动态调整超时，而不必编辑您的服务代码。这是一个指定10秒超时的虚拟服务.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10s

2. 重试

重试设置指定如果初始调用失败，envoy代理尝试连接到服务的最大次数。重试可以提高服务可用性和应用程序性能，方法是确保调用不会因为临时过载的服务或网络等临时问题而永久失败。重试之间的间隔(25ms+)是可变的，并由Istio自动确定，从而防止被调用的服务被请求淹没。默认情况下，在第一次失败后，Envoy代理不会尝试重新连接到服务。

与超时一样，Istio的默认重试行为可能不适合您的应用程序在延迟(对失败的服务进行过多的重试会降低速度)或可用性方面的需求。与超时一样，您可以在虚拟服务中根据每个服务调整重试设置，而不必修改服务代码。您还可以通过添加每次重试超时来进一步细化重试行为，指定每次重试尝试成功连接到服务时需要等待的时间量。下面的示例最多配置3次重试以连接到此服务子集:

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

3. 断路器

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

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

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

更多关于断路器的参考链接：参考链接

4. 故障注入

在配置了网络(包括故障恢复策略)之后，可以使用Istio的故障注入机制测试整个应用程序的故障恢复能力。故障注入是一种将错误引入系统的测试方法，以确保系统能够承受并从错误状态中恢复。使用故障注入对于确保故障恢复策略不是不兼容或限制太多非常有用，这可能导致关键服务不可用。

与其他在网络层引入错误(如延迟数据包或杀死吊舱)的机制不同，Istio允许在应用层注入错误。这使您可以注入更多相关的失败，例如HTTP错误代码。

可以注入两种类型的错误，都是在虚拟服务中配置的。

• 延迟： 延迟就是时间失败。它们模拟增加的网络延迟或过载的上游服务。

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

例如，这个虚拟服务每1000个请求中就有1个请求延迟5秒。

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的流量路由规则让您可以轻松地控制服务之间的流量和API调用流。Istio简化了服务级属性(如断路器、超时和重试)的配置，并简化了重要任务的设置，如A/B测试、金丝雀测试和基于流量分割的分阶段测试。它还提供开箱即用的故障恢复功能，帮助您的应用程序更健壮地应对依赖服务或网络的故障。

Istio的流量管理模型依赖于与您的服务一起部署的envoy代理。您的mesh服务发送和接收的所有流量(数据飞机流量)都是通过Envoy代理的，这使得在您的mesh周围指挥和控制流量变得很容易，而不需要对您的服务做任何更改。

1. Istio流量管理介绍

为了在你的网格中引导流量，Istio需要知道你所有的端点在哪里，它们属于哪个服务。为了填充它自己的服务注册表，Istio连接到一个服务发现系统。例如，如果您在Kubernetes集群上安装了Istio，那么Istio将自动检测该集群中的服务和端点。

使用此服务注册中心，envoy代理可以将流量定向到相关服务。大多数基于微服务的应用程序具有每个服务工作负载的多个实例来处理服务流量，有时也称为负载平衡池。缺省情况下，envoy代理使用循环模型在每个服务的负载平衡池中分发流量，其中请求依次发送给每个池成员，在每个服务实例收到请求后返回到池的顶部。

虽然Istio的基本服务发现和负载平衡为您提供了一个工作服务网格，但这远远不是Istio所能做的。在许多情况下，您可能希望对网格流量的变化进行更细粒度的控制。作为A/B测试的一部分，您可能希望将特定的流量百分比定向到服务的新版本，或者为特定的服务实例子集应用不同的负载平衡策略来处理流量。您可能还希望对进出网格的流量应用特殊的规则，或者将网格的外部依赖项添加到服务注册中心。通过使用Istio的流量管理API将您自己的流量配置添加到Istio，您可以完成所有这些工作。

与其他Istio配置一样，API是使用Kubernetes自定义资源定义(crd)指定的，您可以使用YAML对其进行配置，您将在示例中看到这一点。

本指南的其余部分将介绍每个流量管理API资源以及如何使用它们。这些资源是：

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