[Istio]流量管理API v1alpha3路由规则

　　Istio提供一个API进行流量管理，该API允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加断路器等，所有这些功能都不必更改应用程序本身的代码。Istio 1.0中引入新的流量管理API v1alpha3，新版本API将完全取代之前的API，并不向后兼容。

设计原则

　　1）除支持声明式（意图）配置外，也支持显示指定模型依赖的基础设施。例如除了配置入口网管的功能特性以外，负责实现入口网管功能的组件（Controller）也可以在模型指定

　　2）编写模型时应该“生产者导向”和“以Host为中心”，而不是通过组合多个规则来编写模型，例如所有与特定Host关联的规则被配置在一起

　　3）将路由和路由后行为清晰分开

v1alpha3中的配置资源

　　在一个典型的网格中，通常有一个或多个用于终结外部TLS链接，将流量引入网格的负载均衡器（gateway），然后流量通过边车网关（sidecar gateway）流经内部服务。应用程序使用外部服务时，有些情况这些外部服务可能被直接调用，但有些情况网格中所有访问外部服务的流量可能被要求强制通过专用的出口网关（EgressGateway）

　　

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

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

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

　　下图描述了跨多个配置资源的控制流程。

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中：

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

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

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可以用于建模边缘代理或纯粹的内部代理，如第一张图所示。 无论在哪个位置，所有网关都可以用相同的方式进行配置和控制。

VirtualService

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

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

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

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  precedence: 1
  route:
  - labels:
      version: v1
---
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-test-v2
spec:
  destination:
    name: reviews
  precedence: 2
  match:
    request:
      headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?$"
  route:
  - labels:
      version: v2

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

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

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

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

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

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

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

　　实际上在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大致相同。

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

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

ServiceEntry

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

　　所有以前使用EgressRule进行配置的内容都可以通过ServiceEntry轻松完成。 例如，可以使用类似这样的配置来允许从网格内部访问一个简单的外部服务：

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

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

　　由于ServiceEntry配置只是将服务添加到网格内部的服务注册表中，因此它可以像注册表中的任何其他服务一样,与VirtualService和/或DestinationRule一起使用。例如，以下DestinationRule可用于启动外部服务的mTLS连接：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: foo-ext
spec:
  name: foo.com
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

　　

创建和删除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 1.0以后将不再支持RouteRule，DesintationPolicy和EgressRule这些以前的配置资源 。Kubernetes用户可以继续使用Ingress配置边缘负载均衡器来实现基本的路由。 但是，高级路由功能（例如，跨两个版本的流量分割）则需要使用Gateway ，这是一种功能更强大，Istio推荐的Ingress替代品。

转载博客：https://themes.gohugo.io//theme/hugo-theme-cleanwhite/2018/06/04/introducing-the-istio-v1alpha3-routing-api/

原文地址：https://www.cnblogs.com/yuxiaoba/p/9693921.html

时间： 2024-10-10 10:02:29

[Istio]流量管理API v1alpha3路由规则的相关文章

ASP.NET Web API路由规则（二）

默认的规则 在ASP.NET MVC4中 global.asax.cs代码中并无注册默认路由规则的代码 代码如下: public class WebApiApplication : System.Web.HttpApplication { protected void Application_Start() { AreaRegistration.RegisterAllAreas(); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters

Microsoft Azure中TrafficManager (流量管理器)的路由方式

目前Azure的流量管理器有三种可供选择的路由方式.尽管你可以在任何时间去选择任何路由方法,每个流量管理器的配置文件在同一个时间段只能使用一个路由方法. 值得注意的是,所有的流量路由的方法均包括端点监控.配置流量管理器配置文件指定最适合需求的流量路由方式之后,你需要配置监控设置.当监控配置正确,流量管理器将监视端点的状态,包括云服务和网站,不会发送流量到它认为是不可用的端点. 这三种流量管理器流量路由的方法是:(为了便于理解,这里都举出场景) 1,故障转移:你在相同或不同的Azure数据中心均有

[翻译]ASP.NET Web API的路由

原文:Routing in ASP.NET Web API 在我们新建一个Web API项目时,会在App_Start文件夹下的WebApiConfig.cs中定义一个默认路由: config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); 在默认路由中加

WebAPI的路由规则

1.自定义路由 public static class WebApiConfig { public static void Register(HttpConfiguration config) { // Web API 路由 config.MapHttpAttributeRoutes(); //1.默认路由 config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}

dubbo之路由规则

向注册中心写入路由规则:(通常由监控中心或治理中心的页面完成) RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension(); Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181")); re

MVC路由规则以及前后台获取Action、Controller、ID名方法

1.前后台获取Action.Controller.ID名方法 前台页面:ViewContext.RouteData.Values["Action"].ToString(); ViewContext.RouteData.Values["Controller"].ToString(); ViewContext.RouteData.Values["ID"].ToString(); 后台页面:RouteData.GetRequiredString(&qu

Python开发【Django】：路由规则

Django请求生命周期: -->url对应关系(匹配) ->视图函数->返回用户字符串 -->url对应关系(匹配)->视图函数->打开一个HTML文件,读取内容 创建django project django-admin startproject mysite cd mysite python manage.py startapp cmdb mysite mysite --配置文件 -url.py -settings.py cd mysite cmdb -views

【基础】MVC路由规则

一.RouteData解析过程 在ASP.NET MVC中,服务器收到来自客户端的请求后,会经过一些列的处理拿到请求的数据,比如在Pipeline 管线事件中,通过订阅适当的事件,将HttpContext作为参数传入HttpContextWrapper进行封装,然后取得当前路由集合的数据RouteData进行解析,拿到具体的参数,包括请求路径.请求的参数.IRouteHandler等,通过IRouteHandler的GetHttpHandler返回一个IHttpHandler对象,通过该对象对请

添加路由规则

听着李健的<传奇>,敲着dell的键盘,用着windows10的系统,我写下了这篇博客,关于express路由规则的添加. app.js: var express = require('express'); var path = require('path'); var favicon = require('serve-favicon'); var logger = require('morgan'); var cookieParser = require('cookie-parser');