istio-控制 Ingress 流量 （Gateway VirtualService）

时间  2020-05-22
标签 istio 控制 ingress 流量 gateway virtualservice 栏目 CGI 繁體版
原文   原文链接

控制 Ingress 流量git


到目前为止，Istio提供了一个简单的API来进行流量管理，该API包括了四种资源：RouteRule，DestinationPolicy，EgressRule和Ingress（直接使用了Kubernets的Ingress资源）。借助此API，用户能够轻松管理Istio服务网格中的流量。该API容许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等等，全部这些功能都没必要更改应用程序自己的代码。github

虽然目前API的功能已被证实是Istio很是引人注目的一部分，但用户的反馈也代表，这个API确实有一些缺点，尤为是在使用它来管理包含数千个服务的很是大的应用程序，以及使用HTTP之外的协议时。 此外，使用Kubernetes Ingress资源来配置外部流量的方式已被证实不能知足需求。api

为了解决上述缺陷和其余的一些问题，Istio引入了新的流量管理API v1alpha3，新版本的API将彻底取代以前的API。 尽管v1alpha3和以前的模型在本质上是基本相同的，但它并不向后兼容的，基于旧API的模型须要进行手动转换。 Istio接下来的几个版本中会提供一个新旧模型的转换工具。安全

为了证实该非兼容升级的必要性，v1alpha3 API经历了漫长而艰苦的社区评估过程，以但愿新的API可以大幅改进，并经得起时间考验。 在本文中，咱们将介绍新的配置模型，并试图解释其后面的一些动机和设计原则。服务器

设计原则
路由模型的重构过程当中遵循了一些关键的设计原则：cookie

  • 除支持声明式（意图）配置外，也支持显式指定模型依赖的基础设施。例如，除了配置入口网关（的功能特性）以外，负责实现 入口网关功能的组件（Controller）也能够在模型指定。
  • 编写模型时应该“生产者导向”和“以Host为中心”，而不是经过组合多个规则来编写模型。 例如，全部与特定Host关联的规则被配置在一块儿，而不是单独配置。
  • 将路由与路由后行为清晰分开。

v1alpha3中的配置资源
在一个典型的网格中，一般有一个或多个用于终结外部TLS连接，将流量引入网格的负载均衡器（咱们称之为gateway）。 而后流量经过边车网关（sidecar gateway）流经内部服务。 应用程序使用外部服务的状况也很常见（例如访问Google Maps API），一些状况下，这些外部服务可能被直接调用；但在某些部署中，网格中全部访问外部服务的流量可能被要求强制经过专用的出口网关（Egress gateway）。 下图描绘了网关在网格中的使用状况。网络

gateway
考虑到上述因素，v1alpha3引入了如下这些新的配置资源来控制进入网格，网格内部和离开网格的流量路由。架构

  1. Gateway
  2. VirtualService
  3. DestinationRule
  4. ServiceEntry

VirtualService，DestinationRule和ServiceEntry分别替换了原API中的RouteRule，DestinationPolicy和EgressRule。 Gateway是一个独立于平台的抽象，用于对流入专用中间设备的流量进行建模。负载均衡

下图描述了跨多个配置资源的控制流程。 不一样配置资源之间的关系ide

virtualService

Gateway
Gateway用于为HTTP / TCP流量配置负载均衡器，并无论该负载均衡器将在哪里运行。 网格中能够存在任意数量的Gateway，而且多个不一样的Gateway实现能够共存。 实际上，经过在配置中指定一组工做负载（Pod）标签，能够将Gateway配置绑定到特定的工做负载，从而容许用户经过编写简单的Gateway Controller来重用现成的网络设备。

对于入口流量管理，您可能会问： 为何不直接使用Kubernetes Ingress API ？ 缘由是Ingress API没法表达Istio的路由需求。 Ingress试图在不一样的HTTP代理之间取一个公共的交集，所以只能支持最基本的HTTP路由，最终致使须要将代理的其余高级功能放入到注解（annotation）中，而注解的方式在多个代理之间是不兼容的，没法移植。

Istio Gateway 经过将L4-L6配置与L7配置分离的方式克服了Ingress的这些缺点。 Gateway只用于配置L4-L6功能（例如，对外公开的端口，TLS配置），全部主流的L7代理均以统一的方式实现了这些功能。 而后，经过在Gateway上绑定VirtualService的方式，可使用标准的Istio规则来控制进入Gateway的HTTP和TCP流量。

例如，下面这个简单的Gateway配置了一个Load Balancer，以容许访问host bookinfo.com的https外部流量入mesh中：

 

  1. apiVersion: networking.istio.io/v1alpha3

  2. kind: Gateway

  3. metadata:

  4.   name: bookinfo-gateway

  5. spec:

  6.   servers:

  7.   - port:

  8.       number: 443

  9.       name: https

  10.       protocol: HTTPS

  11.     hosts:

  12.     - bookinfo.com

  13.     tls:

  14.       mode: SIMPLE

  15.       serverCertificate: /tmp/tls.crt

  16.       privateKey: /tmp/tls.key


要为进入上面的Gateway的流量配置相应的路由，必须为同一个host定义一个VirtualService（在下一节中描述），并使用配置中的gateways字段绑定到前面定义的Gateway 上：

 

  1. apiVersion: networking.istio.io/v1alpha3

  2. kind: VirtualService

  3. metadata:

  4.   name: bookinfo

  5. spec:

  6.   hosts:

  7.     - bookinfo.com

  8.   gateways:

  9.   - bookinfo-gateway # <---- bind to gateway

  10.   http:

  11.   - match:

  12.     - uri:

  13.         prefix: /reviews

  14.     route:

  15.     ...


Gateway能够用于建模边缘代理或纯粹的内部代理，如第一张图所示。 不管在哪一个位置，全部网关均可以用相同的方式进行配置和控制。

VirtualService
用一种叫作“Virtual services”的东西代替路由规则可能看起来有点奇怪，但对于它配置的内容而言，这事实上是一个更好的名称，特别是在从新设计API以解决先前模型的可扩展性问题以后。

实际上，发生的变化是：在以前的模型中，须要用一组相互独立的配置规则来为特定的目的服务设置路由规则，并经过precedence字段来控制这些规则的顺序；在新的API中，则直接对（虚拟）服务进行配置，该虚拟服务的全部规则以一个有序列表的方式配置在对应的VirtualService 资源中。

例如，以前在Bookinfo 应用程序的reviews服务中有两个RouteRule资源，以下所示：

 

  1. apiVersion: config.istio.io/v1alpha2

  2. kind: RouteRule

  3. metadata:

  4.   name: reviews-default

  5. spec:

  6.   destination:

  7.     name: reviews

  8.   precedence: 1

  9.   route:

  10.   - labels:

  11.       version: v1

  12. ---

  13. apiVersion: config.istio.io/v1alpha2

  14. kind: RouteRule

  15. metadata:

  16.   name: reviews-test-v2

  17. spec:

  18.   destination:

  19.     name: reviews

  20.   precedence: 2

  21.   match:

  22.     request:

  23.       headers:

  24.         cookie:

  25.           regex: "^(.*?;)?(user=jason)(;.*)?$"

  26.   route:

  27.   - labels:

  28.       version: v2


在v1alph3，能够在单个VirtualService资源中提供相同的配置：

 

  1. apiVersion: networking.istio.io/v1alpha3

  2. kind: VirtualService

  3. metadata:

  4.   name: reviews

  5. spec:

  6.   hosts:

  7.     - reviews

  8.   http:

  9.   - match:

  10.     - headers:

  11.         cookie:

  12.           regex: "^(.*?;)?(user=jason)(;.*)?$"

  13.     route:

  14.     - destination:

  15.         host: reviews

  16.         subset: v2

  17.   - route:

  18.     - destination:

  19.         host: reviews

  20.         subset: v1


正如你所看到的， 和reviews服务相关的两个规则集中写在了一个地方。这个改变乍一看可能以为并无什么特别的优点， 然而，若是仔细观察这个新模型，会发现它和以前的API之间存在着根本的差别，这使得v1alpha3功能更增强大。

首先，请注意VirtualService的目标服务是使用hosts字段（其实是重复字段）指定的，而后再在每一个路由的destination字段中指定。 这是与之前模型的重要区别。

VirtualService描述了一个或多个用户可寻址目标到网格内实际工做负载之间的映射。在上面的示例中，这两个地址是相同的，但实际上用户可寻址目标能够是任何用于定位服务的，具备可选通配符前缀或CIDR前缀的DNS名称。 这对于应用从单体架构到微服务架构的迁移过程特别有用，单体应用被拆分为多个独立的微服务后，采用VirtaulService能够继续把多个微服务对外暴露为同一个目标地址，而不须要服务消费者进行修改以适应该变化。

例如，如下规则容许服务消费者访问Bookinfo应用程序的reviews和ratings服务，就好像它们是http://bookinfo.com/（虚拟）服务的一部分：

 

  1. apiVersion: networking.istio.io/v1alpha3

  2. kind: VirtualService

  3. metadata:

  4.   name: bookinfo

  5. spec:

  6.   hosts:

  7.     - bookinfo.com

  8.   http:

  9.   - match:

  10.     - uri:

  11.         prefix: /reviews

  12.     route:

  13.     - destination:

  14.         host: reviews

  15.   - match:

  16.     - uri:

  17.         prefix: /ratings

  18.     route:

  19.     - destination:

  20.         host: ratings

  21.   ...


实际上在｀VirtualService｀中hosts部分设置只是虚拟的目的地,所以不必定是已在网格中注册的服务。这容许用户为在网格内没有可路由条目的虚拟主机的流量进行建模。 经过将VirtualService绑定到同一Host的Gateway配置（如前一节所述 ），可向网格外部暴露这些Host。

除了这个重大的重构以外， VirtualService还包括其余一些重要的改变：

  1. 能够在VirtualService配置中表示多个匹配条件，从而减小对冗余的规则设置。
  2. 每一个服务版本都有一个名称（称为服务子集）。 属于某个子集的一组Pod/VM在DestinationRule定义，具体定义参见下节。
  3. 经过使用带通配符前缀的DNS来指定VirtualService的host，能够建立单个规则以做用于全部匹配的服务。 例如，在Kubernetes中，在’VirtualService’中使用*.foo.svc.cluster.local做为host,能够对foo命名空间中的全部服务应用相同的重写规则。

DestinationRule
DestinationRule配置将流量转发到服务时应用的策略集。 这些策略应由由服务提供者撰写，用于描述断路器，负载均衡设置，TLS设置等。 除了下述改变外，DestinationRule与其前身DestinationPolicy大体相同。

DestinationRule的host能够包含通配符前缀，以容许单个规则应用于多个服务。
DestinationRule定义了目的host的子集subsets （例如：命名版本）。 这些subset用于｀VirtualService｀的路由规则设置中，能够将流量导向服务的某些特定版本。 经过这种方式为版本命名后，能够在不一样的virtual service中明确地引用这些命名版本的ubset，简化Istio代理发出的统计数据，并能够将subsets编码到SNI头中。 为reviews服务配置策略和subsets的DestinationRule可能以下所示：

 

  1. apiVersion: networking.istio.io/v1alpha3

  2. kind: DestinationRule

  3. metadata:

  4.   name: reviews

  5. spec:

  6.   host: reviews

  7.   trafficPolicy:

  8.     loadBalancer:

  9.       simple: RANDOM

  10.   subsets:

  11.   - name: v1

  12.     labels:

  13.       version: v1

  14.   - name: v2

  15.     labels:

  16.       version: v2

  17.     trafficPolicy:

  18.       loadBalancer:

  19.         simple: ROUND_ROBIN

  20.   - name: v3

  21.     labels:

  22.       version: v3


注意，与DestinationPolicy不一样的是，可在单个DestinationRule中指定多个策略（例如上面实例中的缺省策略和v2版本特定的策略）。

ServiceEntry
ServiceEntry用于将附加条目添加到Istio内部维护的服务注册表中。 它最经常使用于对访问网格外部依赖的流量进行建模，例如访问Web上的API或遗留基础设施中的服务。

全部之前使用EgressRule进行配置的内容均可以经过ServiceEntry轻松完成。 例如，可使用相似这样的配置来容许从网格内部访问一个简单的外部服务：

 

  1. apiVersion: networking.istio.io/v1alpha3

  2. kind: ServiceEntry

  3. metadata:

  4.   name: foo-ext

  5. spec:

  6.   hosts:

  7.   - foo.com

  8.   ports:

  9.   - number: 80

  10.     name: http

  11.     protocol: HTTP


也就是说，ServiceEntry比它的前身具备更多的功能。首先，ServiceEntry不限于外部服务配置，它能够有两种类型：网格内部或网格外部。网格内部条目只是用于向网格显式添加服务，添加的服务与其余内部服务同样。采用网格内部条目，能够把本来未被网格管理的基础设施也归入到网格中（例如，把虚机中的服务添加到基于Kubernetes的服务网格中）。网格外部条目则表明了网格外部的服务。对于这些外部服务来讲，mTLS身份验证是禁用的，而且策略是在客户端执行的，而不是在像内部服务请求同样在服务器端执行策略。

因为ServiceEntry配置只是将服务添加到网格内部的服务注册表中，所以它能够像注册表中的任何其余服务同样,与VirtualService和/或DestinationRule一块儿使用。例如，如下DestinationRule可用于启动外部服务的mTLS链接：

 

  1. apiVersion: networking.istio.io/v1alpha3

  2. kind: DestinationRule

  3. metadata:

  4.   name: foo-ext

  5. spec:

  6.   name: foo.com

  7.   trafficPolicy:

  8.     tls:

  9.       mode: MUTUAL

  10.       clientCertificate: /etc/certs/myclientcert.pem

  11.       privateKey: /etc/certs/client_private_key.pem

  12.       caCertificates: /etc/certs/rootcacerts.pem


除了扩展通用性之外，ServiceEntry还提供了其余一些有关EgressRule改进，其中包括：

  1. 一个ServiceEntry能够配置多个服务端点，这在以前须要采用多个EgressRules来实现。
  2. 如今能够配置服务端点的解析模式（NONE，STATIC或DNS）。
  3. 此外，咱们正在努力解决另外一个难题：目前须要经过纯文本端口访问安全的外部服务（例如http://google.com:443）。该问题将会在将来几周内获得解决，届时将容许从应用程序直接访问https://google.com。请继续关注解决此限制的Istio补丁版本（0.8.x）。

建立和删除v1alpha3路由规则
因为一个特定目的地的全部路由规则如今都存储在单个VirtualService资源的一个有序列表中，所以为该目的地添加新的规则不须要再建立新的RouteRule，而是经过更新该目的地的VirtualService资源来实现。

旧的路由规则：

$ istioctl create -f my-second-rule-for-destination-abc.yaml


v1alpha3路由规则：

$ istioctl replace -f my-updated-rules-for-destination-abc.yaml


删除路由规则也使用istioctl replace完成，固然删除最后一个路由规则除外（删除最后一个路由规则须要删除VirtualService）。

在添加或删除引用服务版本的路由时，须要在该服务相应的DestinationRule更新subsets 。 正如你可能猜到的，这也是使用istioctl replace完成的。

总结
Istio v1alpha3路由API具备比其前身更多的功能，但不幸的是新的API并不向后兼容，旧的模型升级须要一次手动转换。 Istio 0.9之后将再也不支持RouteRule，DesintationPolicy和EgressRule这些之前的配置资源 。Kubernetes用户能够继续使用Ingress配置边缘负载均衡器来实现基本的路由。 可是，高级路由功能（例如，跨两个版本的流量分割）则须要使用Gateway ，这是一种功能更强大，Istio推荐的Ingress替代品。

致谢
感谢如下人员为新版本的路由模型重构和实现工做作出的贡献（按字母顺序）

Frank Budinsky (IBM)
Zack Butcher (Google)
Greg Hanson (IBM)
Costin Manolache (Google)
Martin Ostrowski (Google)
Shriram Rajagopalan (VMware)
Louis Ryan (Google)
Isaiah Snell-Feikema (IBM)
Kuat Yessenov (Google)
原文
Introducing the Istio v1alpha3 routing API

参考：https://istio.io/zh/docs/tasks/traffic-management/ingress/
转载：https://zhaohuabing.com/2018/06/04/introducing-the-istio-v1alpha3-routing-api/#原文

参考：https://www.yangcs.net/posts/istio-ingress/ （推荐看）

实例：https://github.com/4220182/k8s/tree/master/example/istio/gateway

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程