istio-0.8 规则配置 官方案例

Istio提供了一个简单的配置模型来控制API调用和第4层流量如何跨应用程序部署中的各类服务流动。配置模型容许操做员配置服务级属性，例如断路器，超时，重试，以及设置常见的连续部署任务，例如金丝雀推出，A / B测试，基于％的流量分割的分阶段推出等。

例如，可使用以下配置来描述将评论服务的100％传入流量发送到版本“v1” 的简单规则：

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

此配置表示发送到评论服务（在hosts字段中指定）的流量应路由到基础评论服务实例的v1子集。路由subset指定相应目标规则配置中已定义子集的名称：

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2

子集指定一个或多个标识特定于版本的实例的标签。例如，在Istio的Kubernetes部署中，“version：v1”表示只有包含标签“version：v1”的pod才会收到流量。

可使用istioctl CLI配置规则，也可使用命令在Kubernetes部署中配置规则kubectl，尽管只会istioctl执行模型验证并建议使用。有关示例，请参阅配置请求路由任务。

Istio中有四种流量管理配置资源：VirtualService，DestinationRule，ServiceEntry和Gateway。下面描述了这些资源的一些重要方面。有关详细信息，请参阅网络参考

虚拟服务

甲VirtualService定义了控制如何用于服务请求的服务Istio网格内路由的规则。例如，虚拟服务能够将请求路由到不一样版本的服务，或者其实是将请求路由到与请求彻底不一样的服务。能够根据请求源和目标，HTTP路径和标头字段以及与各个服务版本关联的权重来路由请求。

规则目的地

路由规则对应于VirtualService配置中指定的一个或多个请求目标主机。这些主机可能与实际目标工做负载相同或不一样，甚至可能不对应于网格中的实际可路由服务。例如，要使用其内部网格名称或经过主机为审阅服务定义请求的路由规则，可使用以下字段：reviewsbookinfo.comVirtualServicehosts

hosts: - reviews - bookinfo.com

该hosts字段隐式或显式指定一个或多个彻底限定的域名（FQDN）。reviews上面的短名称将隐式扩展为特定于实现的FQDN。例如，在Kubernetes环境中，全名是从VirtualSevice（例如reviews.default.svc.cluster.local）的集群和名称空间派生的。

按源/标头限定规则

能够选择将规则限定为仅应用于符合某些特定条件的请求，例如：

1.限制为特定呼叫者。例如，规则能够指示它仅适用于来自实现评论服务的工做负载（pod）的调用。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: sourceLabels: app: reviews ...

值sourceLabels取决于服务的实现。例如，在Kubernetes中，它可能与相应Kubernetes服务的pod选择器中使用的标签相同。

2.限制到呼叫者的特定版本。例如，如下规则将前一个示例简化为仅应用于评论服务的版本“v2”的调用。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 ...

3.根据HTTP标头选择规则。例如，若是传入请求包含包含子字符串“user = jason”的“cookie”标头，则如下规则将仅适用于传入请求。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" ...

若是提供了多个标头，则全部相应的标头必须匹配才能应用规则。

能够同时设置多个标准。在这种状况下，取决于嵌套，应用AND或OR语义。若是多个条件嵌套在单个匹配子句中，则条件为AND。例如，如下规则仅适用于请求的来源是“reviews：v2”而且存在包含“user = jason”的“cookie”标题。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" ...

相反，若是条件出如今单独的匹配子句中，则只能应用其中一个条件（OR语义）：

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 - headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" ...

在服务版本之间拆分流量

每一个路由规则标识在激活规则时要调用的一个或多个加权后端。每一个后端对应于目标服务的特定版本，其中版本可使用标签表示。若是存在多个具备指定标签的已注册实例，则它们将根据为服务配置的负载平衡策略进行路由，或者默认为循环。

例如，如下规则会将评论服务的25％流量路由到具备“v2”标签的实例，将剩余流量（即75％）路由到“v1”。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 75 - destination: host: reviews subset: v2 weight: 25

超时和重试

默认状况下，http请求的超时为15秒，但这能够在路由规则中覆盖，以下所示：

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

也能够在路由规则中指定给定http请求的重试次数。能够按以下方式设置最大尝试次数，或者在默认或覆盖的超时期限内尽量多的尝试次数：

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

请注意，还能够基于每一个请求覆盖请求超时和重试。

有关超时控制的演示，请参阅请求超时任务。

在请求路径中注入错误

路由规则能够指定在将http请求转发到规则的相应请求目的地时要注入的一个或多个故障。故障能够是延迟或停止。

如下示例将向评级微服务的“v1”版本的10％请求中引入5秒延迟。

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

另外一种故障停止可用于过早终止请求，例如，模拟故障。

如下示例将向评级服务“v1” 返回10％请求的HTTP 400错误代码。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: abort: percent: 10 httpStatus: 400 route: - destination: host: ratings subset: v1

有时延迟和停止故障一块儿使用。例如，如下规则将审核服务“v2”的全部请求延迟5秒到评级服务“v1”，而后停止10％：

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 fault: delay: fixedDelay: 5s abort: percent: 10 httpStatus: 400 route: - destination: host: ratings subset: v1

要查看故障注入操做，请参阅故障注入任务。

HTTP路由规则优先

当给定目的地有多个规则时，它们按照它们出现的顺序进行评估VirtualService，即列表中的第一个规则具备最高优先级。

为何优先重要？每当特定服务的路由故事纯粹基于权重时，就能够在单个规则中指定。另外一方面，当使用其余标准（例如，来自特定用户的请求）来路由流量时，将须要不止一个规则来指定路由。这是必须仔细考虑规则优先级的地方，以确保以正确的顺序评估规则。

广义路由规范的一种常见模式是提供一个或多个更高优先级的规则，这些规则经过源/头限定规则，而后提供单个基于权重的规则，最后没有匹配条件，以提供全部其余状况的流量的加权分布。

例如，如下VirtualService包含2个规则，它们一块儿指定对包含名为“Foo”且值为“bar”的标题的评论服务的全部请求将被发送到“v2”实例。全部剩余的请求将被发送到“v1”。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: Foo: exact: bar route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v1

请注意，基于标头的规则具备更高的优先级。若是它较低，这些规则将没法按预期工做，由于基于权重的规则（没有特定的匹配标准）将首先进行评估，而后将全部流量简单地路由到“v1”，甚至包括匹配“Foo”的请求“头。一旦找到适用于传入请求的规则，它将被执行而且规则评估过程将终止。这就是为何在存在多个规则时仔细考虑每一个规则的优先级很是重要的缘由。

目标规则

一个DestinationRule配置组策略后应用的请求VirtualService已经发生路由。它们旨在由服务全部者编写，描述断路器，负载平衡器设置，TLS设置等。

A DestinationRule还定义subsets了相应目标主机的可寻址（即，命名版本）。VirtualService在将流量发送到特定版本的服务时，这些子集用于路由规范。

如下DestinationRule配置评论服务的策略和子集：

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews 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

请注意，能够在单个DestinationRule配置中指定多个策略（例如，默认和特定于v2）。

断路器

能够根据许多标准（例如链接和请求限制）设置简单的断路器。

例如，如下DestinationRule设置对评论服务版本“v1”后端的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

有关断路器控制的演示，请参阅断路任务。

DestinationRule评估

与路由规则相似，策略与特定主机相关联，但若是它们是特定于子集，则激活取决于路由规则评估结果。

规则评估过程当中的第一步评估VirtualService对应于所请求主机的路由规则（若是有任何已定义的），以肯定当前请求将被路由到的目标服务的子集（即，特定版本）。接下来，评估与所选子集相对应的策略集（若是有的话）以肯定它们是否适用。

注意：要记住的算法的一个细微之处在于，只有在明确路由到相应的子集时，才会应用为特定子集定义的策略。例如，考虑如下配置，做为为评论服务定义的惟一规则（即，相应的路由规则中没有路由规则）VirtualService。

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

因为没有为评论服务定义特定的路由规则，所以将应用默认的循环路由行为，有时可能会调用“v1”实例，若是“v1”是惟一运行的版本，甚至可能老是如此。然而，因为默认路由是在较低级别完成的，所以永远不会调用上述策略。规则评估引擎将不知道最终目标，所以没法将子集策略与请求匹配。

您能够经过如下两种方式之一修复上述示例。您能够将流量策略上移一级以使其适用于任何版本：

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

或者，更好的是，为服务定义正确的路由规则。例如，您能够为“reviews：v1”添加简单的路由规则。

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

虽然默认的Istio行为能够方便地将流量从任何源发送到目标服务的全部版本而不设置任何规则，但只要须要版本区分，就须要规则。所以，从一开始就为每一个服务设置默认规则一般被认为是Istio中的最佳实践。

服务条目

一个ServiceEntry用于添加额外的条目成Istio内部维护的服务注册。它最经常使用于启用对Istio服务网格以外的服务的请求。例如，如下内容ServiceEntry可用于容许外部调用*.foo.com域下托管的服务。

apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: foo-ext-svc spec: hosts: - *.foo.com ports: - number: 80 name: http protocol: HTTP - number: 443 name: https protocol: HTTPS

ServiceEntry使用该hosts字段指定a的目标，该字段能够是彻底限定域名或通配符域名。它表示容许访问网格中的服务的一个或多个服务的白名单集。

A ServiceEntry不限于外部服务配置，它能够有两种类型：网状内部或网状外部。网状内部条目与全部其余内部服务相似，但用于向网格显式添加服务。它们可用于添加服务，做为扩展服务网格的一部分，以包括非托管基础架构（例如，添加到基于Kubernetes的服务网格的VM）。网格外部条目表示网格外部的服务。对于他们来讲，mTLS身份验证被禁用，而且在客户端执行策略实施，而不是在一般的服务器端执行内部服务请求。

只要服务条目使用匹配引用服务，服务条目就能够与虚拟服务和目标规则结合使用hosts。例如，如下规则可与上述ServiceEntry规则结合使用，为外部服务的调用设置10秒超时bar.foo.com。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bar-foo-ext-svc spec: hosts: - bar.foo.com http: - route: - destination: host: bar.foo.com timeout: 10s

外部目的地支持重定向和转发流量，定义重试，超时和故障注入策略的规则。然而，加权（基于版本）路由是不可能的，由于没有外部服务的多个版本的概念。

有关访问外部服务的更多信息，请参阅出口任务。

网关

甲网关配置HTTP / TCP流量负载平衡器，在网格的边缘最经常使用操做，以实现入口流量为应用程序。

与Kubernetes Ingress不一样，Istio Gateway仅配置L4-L6功能（例如，要暴露的端口，TLS配置）。而后，用户可使用标准的Istio规则来控制HTTP请求以及Gateway经过绑定VirtualService到它来进入的TCP流量。

例如，如下简单Gateway配置负载均衡器以容许主机的外部https流量bookinfo.com进入网格：

apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway spec: servers: - port: number: 443 name: https protocol: HTTPS hosts: - bookinfo.com tls: mode: SIMPLE serverCertificate: /tmp/tls.crt privateKey: /tmp/tls.key

要配置相应的路由，VirtualService必须为同一主机定义a 并绑定到Gateway使用gateways配置中的字段：

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - bookinfo.com gateways: - bookinfo-gateway # <---- bind to gateway http: - match: - uri: prefix: /reviews route: ...

有关完整的入口网关示例，请参阅入口任务。

虽然主要用于管理入口流量，Gateway但也可用于模拟纯内部或出口代理。不管位置如何，全部网关均可以以相同的方式进行配置和控制。有关详细信息，请参阅网关参考。

 

https://istio.io/docs/concepts/traffic-management/rules-configuration/

 

总结：

Istio中有四种流量管理配置资源：VirtualService，DestinationRule，ServiceEntry和Gateway

 

VirtualService：

VirtualService定义了控制如何用于服务请求的服务Istio网格内路由的规则。例如，虚拟服务能够将请求路由到不一样版本的服务，或者其实是将请求路由到与请求彻底不一样的服务。能够根据请求源和目标，HTTP路径和标头字段以及与各个服务版本关联的权重来路由请求。

一、按源/标头限定规则

二、在服务版本之间拆分流量

三、超时和重试

四、在请求路径中注入错误

五、HTTP路由规则优先

 

DestinationRule：

DestinationRule配置组策略后应用的请求VirtualService已经发生路由。它们旨在由服务全部者编写，描述断路器，负载平衡器设置，TLS设置等。

一、destinationRule还定义subsets

二、断路器

 

ServiceEntry: 访问外部请求

用于添加额外的条目成Istio内部维护的服务注册。它最经常使用于启用对Istio服务网格以外的服务的请求。例如，如下内容ServiceEntry可用于容许外部调用*.foo.com域下托管的服务。

 

Gateway：与Kubernetes Ingress不一样，Istio Gateway仅配置L4-L6功能（例如，要暴露的端口，TLS配置）。而后，用户可使用标准的Istio规则来控制HTTP请求以及Gateway经过绑定VirtualService到它来进入的TCP流量。

 

简而言之：

流程

Gateway (路径匹配) > VirtualService(规则，权重匹配) > DestinationRule(目标服务，断路器) > 具体服务

ServiceEntry: 访问外部请求