istio服务网格技术解析与实践(istio apigateway)

大家好，又见面了，我是你们的朋友全栈君。

istio的第二篇主要介绍流量管理
1.前言
Istio的流量路由规则允许您轻松控制服务之间的流量和api调用。ISTIO简化了诸如断路器、超时和重试等服务级别属性的配置，并使设置重要任务（如A/B测试、金丝雀卷展和具有基于百分比的流量分割的分阶段卷展）变得容易。它还提供了开箱即用的故障恢复功能，有助于使您的应用程序在从属服务或网络故障时更加健壮。

ISTIO的流量管理模型依赖于与您的服务一起部署的特使代理。您的Mesh服务发送和接收的所有流量（数据平面业务）都是通过特使代理的，这使得在您的网格周围直接和控制流量变得容易，而不需要对您的服务进行任何更改。

如果您对本指南中描述的功能如何工作的详细信息感兴趣，可以在本文档末尾的“架构”部分中了解有关ISTIO流量管理架构的更多信息。本指南的其余部分介绍了istio的流量管理功能。

2.介绍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
本指南还概述了一些内置于api资源中的网络弹性和测试功能。
3.Virtual services
虚拟服务和目的地规则是istio流量路由功能的关键组成部分。虚拟服务允许您在istio和您的平台提供的基本连接和发现的基础上，配置如何将请求路由到istio服务网格中的服务。每个虚拟服务由一组按顺序计算的路由规则组成，允许istio将每个给定请求与虚拟服务匹配到网格中的特定真实目的地。根据您的用例，网格可能需要多个虚拟服务，也可能不需要。
3.1为什么要使用 virtual services?
Virtual services在使ISTIO的流量管理灵活高效的过程中起着关键性的作用。它们通过在客户机从实际实现它们的目标工作负载发送请求的地方进行强分离来实现这一点。Virtual services还提供了一种丰富的方式来指定不同的流量路由规则，以便将流量发送到这些工作负载。

为什么这么有用？在没有Virtual services的情况下，特使使用循环负载平衡在所有服务实例之间分配流量，如引言中所述。您可以根据对工作负载的了解改进此行为。例如，有些可能代表不同的版本。这在a/b测试中很有用，在a/b测试中，您可能需要根据不同服务版本的百分比配置流量路由，或者将内部用户的流量定向到特定的实例集。

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

典型的用例是将流量发送到服务的不同版本，指定为服务子集。客户端将请求发送到Virtual services主机，就好像它是一个单独的实体一样，然后根据Virtual services规则将流量路由到不同的版本：例如，“20%的呼叫转到新版本”或“这些用户的呼叫转到版本2”。例如，这允许您创建一个canary卷展栏，在这里您可以逐渐增加发送到新服务版本的流量百分比。流量路由与实例部署完全分离，这意味着实现新服务版本的实例数量可以根据流量负载进行上下缩放，而完全不参考流量路由。相比之下，像kubernetes这样的容器编排平台只支持基于实例缩放的流量分布，这很快就会变得复杂。您可以阅读更多有关Virtual services如何使用istio帮助金丝雀部署中。

虚拟服务还允许您：

通过单个虚拟服务寻址多个应用程序服务。例如，如果网格使用kubernetes，则可以配置虚拟服务来处理特定命名空间中的所有服务。将单个虚拟服务映射到多个“真实”服务在帮助将单个应用程序转换为由不同的微服务构建的组合服务时特别有用，而无需服务的使用者适应转换。您的路由规则可以指定“调用monolith.com的这些uri转到microservice
a”，等等。您可以在下面的一个示例中看到这是如何工作的。
结合网关配置流量规则以控制进出流量。

在某些情况下，您还需要配置目标规则以使用这些功能，因为这些是您指定服务子集的位置。通过在单独的对象中指定服务子集和其他特定于目标的策略，可以在虚拟服务之间干净地重用这些策略。您可以在下一节中了解有关目标规则的更多信息。

3.2 Virtual services用法举例
以下虚拟服务根据请求是否来自特定用户，将请求路由到服务的不同版本。

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

3.2.1 hosts 字段
hosts字段列出虚拟服务的主机—换句话说，这些路由规则应用于的用户可寻址目标。这是客户端向服务发送请求时使用的一个或多个地址。

虚拟服务主机名可以是IP地址、DNS名称，也可以是短名称（例如Kubernetes服务短名称），该短名称隐式或显式解析为完全限定域名（FQDN）。您还可以使用通配符（“*”）前缀，以便为所有匹配的服务创建一组路由规则。虚拟服务主机实际上不必是istio服务注册表的一部分，它们只是虚拟目的地。这允许您为网格中没有可路由条目的虚拟主机建模通信量。

3.2.2 路由规则
http部分包含虚拟服务的路由规则，描述将http/1.1、http2和grpc通信发送到“host”字段中指定的目标的匹配条件和操作（也可以使用tcp和tls部分为tcp和未终止的tls通信配置路由规则）。路由规则由您希望通信量到达的目的地和零个或多个匹配条件组成，具体取决于您的用例
3.2.3 match 条件匹配
示例中的第一个路由规则有一个条件，因此从匹配字段开始。在本例中，您希望此路由应用于来自用户“jason”的所有请求，因此可以使用头、最终用户和确切字段来选择适当的请求。

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

3.2.4 Destination
路由部分的Destination字段指定与此条件匹配的通信量的实际目的地。**与虚拟服务的主机不同，目的地的主机必须是ISTIO服务注册表中存在的真实目的地，**否则特使不知道往何处发送流量。这可以是带有代理项的网格服务或使用服务条目添加的非网格服务。在本例中，我们在kubernetes上运行，主机名是kubernetes服务名：

route:
- destination:
    host: reviews
    subset: v2

注意在本页和本页的其他示例中，为了简单起见，我们使用kubernetes短名称作为目标主机。计算此规则时，istio将根据包含路由规则的虚拟服务的命名空间添加域后缀，以获取主机的完全限定名。在我们的示例中使用短名称还意味着您可以在任何您喜欢的名称空间中复制和尝试它们。

只有当目标主机和虚拟服务实际上在同一个kubernetes名称空间中时，才可以使用这样的短名称。由于使用kubernetes短名称可能导致错误配置，建议您在生产环境中指定完全限定的主机名。

destination部分还指定要将符合此规则条件的请求转到kubernetes服务的哪个子集，在本例中是名为v2的子集。您将在下面关于目标规则的部分中看到如何定义服务子集。

3.2.5 路由规则优先级
路由规则按从上到下的顺序进行计算，其中虚拟服务定义中的第一个规则具有最高优先级。在这种情况下，您希望任何与第一个路由规则不匹配的内容都转到第二个规则中指定的默认目标。因此，第二条规则没有匹配条件，只是将通信量定向到v3子集。

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

我们建议在每个虚拟服务中提供一个默认的“无条件”或基于权重的规则（如下所述）作为最后一个规则，以确保到虚拟服务的流量始终至少有一个匹配的路由。
3.2.6 bookinfo举例
如上所述，路由规则是一个强大的工具，用于将特定的通信子集路由到特定的目的地。您可以在流量端口、头字段、uri等上设置匹配条件。例如，这个虚拟服务允许用户将流量发送到两个独立的服务，评级和评论，就好像他们是http://bookinfo.com/上更大的虚拟服务的一部分。虚拟服务规则根据请求uri匹配通信量，并将请求定向到适当的服务。

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
...

  http:
  - match:
      sourceLabels:
        app: reviews
    route:
...