首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >《云原生服务网格Istio》第3章 非侵入的流量治理

《云原生服务网格Istio》第3章 非侵入的流量治理

作者头像
yeedomliu
发布2019-10-11 15:07:02
1.6K0
发布2019-10-11 15:07:02
举报
文章被收录于专栏:yeedomliuyeedomliu

第3章 非侵入的流量治理

  • 通过对本章的学习,可基于Istio的这些配置在不修改代码的情况下实现各种流量治理

3.1 Istio流量治理的原理

  • 流量治理是一个非常宽泛的话题
    • 动态修改服务间访问的负载均衡策略,比如根据某个请求特征做会话保持
    • 同一个服务有两个版本在线,将一部分流量切到某个版本上
    • 对服务进行保护,例如限制并发连接数、限制请求数、隔离故障服务实例等
    • 动态修改服务中的内容,或者模拟一个服务运行故障等
  • 在Istio中实现这些服务治理功能时无须修改任何应用的代码。Istio以一种更轻便、透明的方式向用户提供了这些功能。用户可以用自己喜欢的任意语言和框架进行开发,专注于自己的业务,完全不用嵌入任何治理逻辑。只要应用运行在Istio的基础设施上,就可以使用这些治理能力
  • 一句话总结 Istio 流量治理的目标:以基础设施的方式提供给用户非侵入的流量治理能力,用户只需关注自己的业务逻辑开发,无须关注服务访问管理

3.1.1 负载均衡

  • 负载均衡从严格意义上讲不应该算治理能力,因为它只做了服务间互访的基础工作
  • 在微服务场景下,负载均衡一般和服务发现配合使用,每个服务都有多个对等的服务实例,需要有一种机制将请求的服务名解析到服务实例地址上。服务发现负责从服务名中解析一组服务实例的列表,负载均衡负责从中选择一个实例
Service Mesh架构,服务发现和负载均衡的工作流程
Kubernetes上支持Service的重要组件Kube-proxy
  • 运行在工作节点的一个网络代理和负载均衡器,它实现了Service模型,默认通过轮询等方式把Service访问转发到后端实例Pod上

3.1.2 服务熔断

  • “熔断器”这个概念延伸到计算机世界中指的是故障检测和处理逻辑,防止临时故障或意外导致系统整体不可用,最典型的应用场景是防止网络和服务调用故障级联发生,限制故障的影响范围,防止故障蔓延导致系统整体性能下降或雪崩
  • 在Hystrix官方曾经有这样一个推算:如果一个应用包含30个依赖的服务,每个服务都可以保证99.99%可靠性地正常运行,则从整个应用角度看,可以得到99.9930=99.7%的正常运行时间,即有0.3%的失败率,在10亿次请求中就会有3 000 000多种失败,每个月就会有两个小时以上的宕机。即使其他服务都是运行良好的,只要其中一个服务有这样0.001%的故障几率,对整个系统就都会产生严重的影响
  • 熔断主要应用于微服务场景下的分布式调用中
    • 在远程调用时,请求在超时前一直挂起,会导致请求链路上的级联故障和资源耗尽
    • 熔断器封装了被保护的逻辑,监控调用是否失败,当连续调用失败的数量超过阈值时,熔断器就会跳闸,在跳闸后的一定时间段内,所有调用远程服务的尝试都将立即返回失败
    • 同时,熔断器设置了一个计时器,当计时到期时,允许有限数量的测试请求通过
    • 如果这些请求成功,则熔断器恢复正常操作;如果这些请求失败,则维持断路状态
  • 熔断关闭:熔断器处于关闭状态,服务可以访问。熔断器维护了访问失败的计数器,若服务访问失败则加一
  • 熔断开启:熔断器处于开启状态,服务不可访问,若有服务访问则立即出错
  • 熔断半开启:熔断器处于半开启状态,允许对服务尝试请求,若服务访问成功则说明故障已经得到解决,否则说明故障依然存在
Hystrix熔断
  • 关于熔断,大家比较熟悉的一个落地产品就是Hystrix。Hystrix是Netflix提供的众多服务治理工具集中的一个,在形态上是一个Java库,在2011年出现,后来多在Spring Cloud中配合其他微服务治理工具集一起使用
  • 在使用上,不管是直接使用Netflix的工具集还是Spring Cloud中的包装,都建议在代码中写熔断处理逻辑,有针对性地进行处理,但侵入了业务代码,这也是与 Istio 比较大的差别
  • 业界一直以 Hystrix 作为熔断的实现模板,尤其是基于 Spring Cloud。但遗憾的是,Hystrix 在 1.5.18 版本后就停止开发和代码合入,转为维护状态,其替代者是不太知名的Resilience4J
Istio熔断
  • 云原生场景下的服务调用关系更加复杂,Istio提供了一套非侵入的熔断能力来应对这种挑战
  • 连接池管理(ConnectionPoolSettings)和异常点检查(OutlierDetection)这两种配置
    • 在 Istio 中通过限制某个客户端对目标服务的连接数、访问请求数等,避免对一个服务的过量访问,如果超过配置的阈值,则快速断路请求。还会限制重试次数,避免重试次数过多导致系统压力变大并加剧故障的传播
    • 如果某个服务实例频繁超时或者出错,则将该实例隔离,避免影响整个服务
  • 通过Istio的连接池管理可以控制frontend服务对目标服务forecast的请求
  • 被移除的实例在一段时间之后,还会被加回来再次尝试访问,如果可以访问成功,则认为实例正常;如果访问不成功,则实例不正常,重新被逐出,后面驱逐的时间等于一个基础时间乘以驱逐的次数
  • Istio 的这个流程也是基于 Martin 的熔断模型设计和实现的,不同之处在于这里没有熔断半开状态,熔断器要打开多长时间取决于失败的次数
  • 在 Istio 中可以控制驱逐比例,即有多少比例的服务实例在不满足要求时被驱逐。当有太多实例被移除时,就会进入恐慌模式,这时会忽略负载均衡池上实例的健康标记,仍然会向所有实例发送请求,从而保证一个服务的整体可用性
  • 当 Hystrix 开发的服务运行在Istio环境时,两种熔断机制叠加在一起。在故障场景下,如果Hystrix和Istio两种规则同时存在,则严格的规则先生效。当然,不推荐采用这种做法,建议业务代码处理好业务,把治理的事情交给Istio来做

3.1.3 故障注入

  • 对于一个系统,尤其是一个复杂的系统,重要的不是故障会不会发生,而是什么时候发生。故障处理对于开发人员和测试人员来说都特别耗费时间和精力:对于开发人员来说,他们在开发代码时需要用20%的时间写80%的主要逻辑,然后留出80%的时间处理各种非正常场景;
  • 故障注入是一种评估系统可靠性的有效方法,最早在硬件场景下将电路板短路来其观察对系统的影响,在软件场景下也是使用一种手段故意在待测试的系统中引入故障,从而测试其健壮性和应对故障的能力,
  • 故障注入从方法上来说有编译期故障注入和运行期故障注入,前者要通过修改代码来模拟故障,后者在运行阶段触发故障
  • 在 Istio 的故障注入中可以对故障的条件进行各种设置,例如只对某种特定请求注入故障,其他请求仍然正常

3.1.4 灰度发布

  • 其核心是能配置一定的流量策略,将用户在同一个访问入口的流量导到不同的版本上。有如下几种典型场景
蓝绿发布
AB测试
金丝雀发布
  • 灰度发布技术上的核心要求是要提供一种机制满足多不版本同时在线,并能够灵活配置规则给不同的版本分配流量,可以采用以下几种方式
基于负载均衡器的灰度发布
基于Kubernetes的灰度发布
  • 在Kubernetes环境下可以基于Pod的数量比例分配流量
基于Istio的灰度发布
  • Istio本身并没有关于灰度发布的规则定义,灰度发布只是流量治理规则的一种典型应用,在进行灰度发布时,只要写个简单的流量规则配置即可

3.1.5 服务访问入口

  • 一组服务组合在一起可以完成一个独立的业务功能,一般都会有一个入口服务,从外部可以访问,主要是接收外部的请求并将其转发到后端的服务
Kuberntes服务的访问入口
  • 在 Kubernetes 中可以将服务发布成 Loadbalancer 类型的 Service,通过一个外部端口就能访问到集群中的指定服务
Istio服务访问入口

3.1.6 外部接入服务治理

  • 随着系统越来越复杂,服务间的依赖也越来越多,当实现一个完整的功能时,只靠内部的服务是无法支撑的。且不说当前云原生环境下的复杂应用,就是在多年前的企业软件开发环境下,自己开发的程序也需要搭配若干中间件才能完成

3.2 Istio路由规则配置:VirtualService

  • VirtualService是Istio流量治理的一个核心配置,可以说是Istio流量治理中最重要、最复杂的规则

3.2.1 路由规则配置示例

3.2.2 路由规则定义

  • VirtualService定义了对特定目标服务的一组流量规则。VirtualService在形式上表示一个虚拟服务,将满足条件的流量都转发到对应的服务后端,这个服务后端可以是一个服务,也可以是在DestinationRule中定义的服务的子集
  • VirtualService描述了一个具体的服务对象,在该服务对象内包含了对流量的各种处理,其主体是一个服务而不是一组规则,更易于理解
  • VirtualService中的一些术语
    • Service:服务
    • Service Version:服务版本,参照2.2.2节Istio服务模型中的概念
    • Source:发起调用的服务
    • Host:服务调用方连接和调用目标服务时使用的地址,是 Istio的几个配置中非常重要的一个概念
  • 非复合字段hosts和gateways是每种协议都要用到的公共字段,体现了VirtualService的设计思想

3.2.3 HTTP路由(HTTPRoute)

  • HTTP是当前最通用、内容最丰富的协议,控制也最多,是Istio上支持最完整的一种协议
    • 服务的端口协议是HTTP、HTTP2、GRPC,即在服务的端口名中包含http-、http2-、grpc-等
    • Gateway的端口协议是HTTP、HTTP2、GRPC,或者Gateway是终结TLS,即Gateway外部是HTTPS,但内部还是HTTP
    • ServiceEntry的端口协议是HTTP、HTTP2、GRPC
HTTPRoute规则解析
  • 图3-30 HTTPRoute规则
HTTP匹配规则(HTTPMatchRequest)
  • Authority的定义与 Host的定义容易混淆,实际上,Authority的标准定义是:“authority=[userinfo@]host[:port]”
  • 注意:在HTTPRoute的匹配条件中,每个HTTPMatchRequest中的诸多属性都是“与”逻辑,几个元素间的关系是“或”逻辑
  • 在VirtualService中match字段都是数组类型。HTTPMatchRequest中的诸多属性如uri、headers、method等是“与”逻辑,而数组中几个元素间的关系是“或”逻辑
HTTP路由目标(HTTPRouteDestination)
  • 在HTTPRouteDestination中主要有三个字段:destination(请求目标)、weight(权重)和headers(HTTP头操作),destination和weight是必选字段
  • 1)destination
    • 这个字段是一个Destination类型的结构,通过host、subset和port三个属性来描述
    • host 是 Destination 的必选字段,表示在 Istio 中注册的服务名,不但包括网格内的服务,也包括通过ServiceEntry方式注册的外部服务。Istio 就会根据规则的命名空间解析服务名,而不是根据 Service 的命名空间来解析。所以在使用上建议写全域名
  • 2)weight
    • 除了 destination,HTTPRouteDestination 上的另一个必选字段是 weight,表示流量分配的比例,在一个route下多个destination的weight总和要求是100
  • 3)headers
    • 可以修改一次 HTTP 请求中Request或者Response的值,包含request和response两个字段
    • request:表示在发请求给目标地址时修改Request的Header
    • response:表示在返回应答时修改Response的Header
HTTP重定向(HTTPRedirect)
HTTP重写(HTTPRewrite)
HTTP重试(HTTPRetry)
  • HTTPRetry可以定义请求失败时的重试策略。重试策略包括重试次数、超时、重试条件等,这里分别描述相应的三个字段
    • attempts:必选字段,定义重试的次数
    • perTryTimeout:每次重试的超时时间,单位可以是毫秒(ms)、秒(s)、分钟(m)和小时(h)
    • retryOn:进行重试的条件,可以是多个条件,以逗号分隔
HTTP流量镜像(Mirror)
HTTP故障注入(HTTPFaultInjection)
  • 除了支持Redirect、Rewrite、Retry等HTTP请求的常用操作,在HTTPRoute上还支持故障注入
  • HTTPFaultInjection通过delay和abort两个字段配置延时和中止两种故障,分别表示Proxy延迟转发HTTP请求和中止HTTP请求
  • 延迟故障注入:HTTPFaultInjection中的延迟故障使用HTTPFaultInjection.Delay类型描述延时故障,表示在发送请求前进行一段延时,模拟网络、远端服务负载等各种原因导致的失败,主要有如下两个字段
    • fixedDelay:一个必选字段,表示延迟时间,单位可以是毫秒、秒、分钟和小时,要求时间必须大于1毫秒
    • percentage:配置的延迟故障作用在多少比例的请求上,通过这种方式可以只让部分请求发生故障
  • 请求中止故障注入:HTTPFaultInjection使用 HTTPFaultInjection.Abort描述中止故障,模拟服务端异常,给调用的客户端返回预先定义的错误状态码,主要有如下两个字段
    • httpStatus:是一个必选字段,表示中止的HTTP 状态码
    • percentage:配置的中止故障作用在多少比例的请求上,通过这种方式可以只让部分请求发生故障,用法同延迟故障
HTTP跨域资源共享(CorsPolicy)

3.2.4 TLS路由(TLSRoute)

  • TLSRoute被应用于以下场景中
    • 服务的端口协议是HTTPS和TLS。即在服务的端口名中包含https-、tls-等
    • Gateway的端口是非终结的 HTTPS和 TLS
    • ServiceEntry的端口是HTTPS和TLS

3.2.6 三种协议路由规则的对比

  • 从各个维度来看,HTTP路由规则的内容最丰富,TCP路由规则的内容最少,这也符合协议分层的设计
多个服务的组合
路由规则的优先级
复杂条件路由
特定版本间的访问规则

3.3 Istio目标规则配置:DestinationRule

  • 在路由的目标对象 Destination 中大多包含表示 Service子集的 subset字段,这个服务子集就是通过 DestinationRule定义的

3.3.1 DestinationRule配置示例

3.3.2 DestinationRule规则定义

  • DestinationRule经常和VirtualService结合使用,VirtualService用到的服务子集subset在 DestinationRule 上也有定义
  • VirtualService也是一个虚拟Service,描述的是满足什么条件的流量被哪个后端处理。可以对应这样一个Restful服务,每个路由规则都对应其中Resource中的资源匹配表达式。只是在 VirtualService 中,这个匹配条件不仅仅是路径方法的匹配,还是更开放的 Match条件
  • 而 DestinationRule 描述的是这个请求到达某个后端后怎么去处理
  • 理解了这两个对象的定位,就不难理解其规则上的设计原理,从而理解负载均衡和熔断等策略为什么被定义在DestinationRule上。在 Istio 中可以配置目标服务的负载均衡策略、连接池大小、异常实例驱除规则等功能
1.流量策略(TrafficPolicy)
2.负载均衡设置(LoadBalancerSettings)
  • 一致性哈希是一种高级的负载均衡策略,只对 HTTP有效,因为在实现上基于 HTTP Header、Cookie的取值来进行哈希。负载均衡器会把哈希一致的请求转发到相同的后端实例上,从而实现一定的会话保持
3.连接池设置(ConnectionPoolSettings)
  • 通过连接池管理可以配置阈值来防止一个服务的失败级联影响到整个应用,可以看到Istio连接池管理在协议上分为TCP流量和HTTP流量治理
  • 1)TCP连接池配置(TCPSettings)
  • 2)HTTP连接池配置(HTTPSettings)
  • 3)Istio连接池配置总结
  • 两者的属性划分维度不一样:在Istio中根据协议划分为TCP和HTTP;在Envoy中根据属性的业务划分为不同的分组,一部分属于 circuit_breakers 分组,另一部分属于 cluster 分组
4.异常实例检测设置(OutlierDetection)
  • 异常点检查就是定期考察被访问的服务实例的工作情况,如果连续出现访问异常,则将服务实例标记为异常并进行隔离,在一段时间内不为其分配流量。过一段时间后,被隔离的服务实例会再次被解除隔离,尝试处理请求,若还不正常,则被隔离更长的时间。在模型上,Istio的异常点检查符合一般意义的熔断模型
  • 在 Istio 中,其实可以将异常点检查理解成健康检查,但是与传统的健康检查不同。在传统的健康检查中,都是定期探测目标服务实例,根据应答来判断服务实例的健康状态,这里的健康检查是指通过对实际的访问情况进行统计来找出不健康的实例,所以是被动型的健康检查,负载均衡的健康检查是主动型的健康检查
  • 可以通过如下参数配置来控制检查驱逐的逻辑
    • consecutiveErrors:实例被驱逐前的连续错误次数,默认是 5。对于 HTTP 服务,返回 502、503 和 504 的请求会被认为异常;对于 TCP 服务,连接超时或者连接错误事件会被认为异常
    • interval:驱逐的时间间隔,默认值为10秒,要求大于1毫秒,单位可以是时、分、毫秒
    • baseEjectionTime:最小驱逐时间。一个实例被驱逐的时间等于这个最小驱逐时间乘以驱逐的次数。默认值为30秒,要求大于1毫秒,单位可以是时、分、毫秒
    • maxEjectionPercent:指负载均衡池中可以被驱逐的故障实例的最大比例,默认是10%,
    • minHealthPercent:最小健康实例比例,
  • 当负载均衡池中的健康实例数的比例大于这个比例时,异常点检查机制可用;当可用实例数的比例小于这个比例时,异常点检查功能将被禁用,所有服务实例不管被认定为健康还是不健康,都可以接收请求。参数的默认值为50%
5.端口流量策略设置(PortTrafficPolicy)
  • 只要了解在端口上定义的流量策略会覆盖全局的流量策略即可
6.服务子集(Subset)
  • Subset的一个重要用法是定义服务的子集,包含若干后端服务实例。要在 VirtualService 中完成这种流量规则,就必须先通过DestinationRule对Subset进行定义
  • Subset包含以下三个重要属性
    • name:Subset的名字,为必选字段。通过VirtualService引用的就是这个名字
    • labels:Subset上的标签,通过一组标签定义了属于这个Subset的服务实例。比如最常用的标识服务版本的Version标签
    • trafficPolicy:应用到这个Subset上的流量策略

3.3.3 DestinationRule的典型应用

1.定义Subset
2.服务熔断
  • 假设 forecast 服务有 10 个实例,则以上配置的效果是:为 forecast 服务配置最大 80个连接,最大请求数为800,每个连接的请求数都不超过10个,连接超时是25毫秒;另外,在4分钟内若有某个forecast服务实例连续出现5次访问异常,比如返回5xx错误,则该forecast服务实例将被隔离10分钟,被隔离的实例总数不超过3个。在第1次隔离期满后,异常的实例将重新接收流量,如果实例工作仍不正常,则被重新隔离,第2次将被隔离20分钟,以此类推
3.负载均衡配置
4.TLS认证配置

3.4 Istio服务网关配置:Gateway

  • Istio通过Gateway将网格内的服务发布成外部可访问的服务,还可以通过Gateway配置外部访问的端口、协议及与内部服务的映射关系

3.4.1 Gateway配置示例

  • 通过一个配置示例认识 Gateway,通过 HTTP的 80端口访问网格内的服务
  • 配合 Gateway的使用, VirtualService要做适当修改,在 hosts上匹配 Gateway上请求的主机名,并通过 gateways字段关联定义的 Gateway对象

3.4.2 Gateway规则定义

  • Gateway一般和 VirtualService配合使用。Gateway定义了服务从外面怎样访问;VirtualService定义了匹配到的内部服务怎么流转。正是有了 Gateway的存在,才能在入口处对服务进行统一治理
  • Kubernetes的 Ingress对象同时描述服务入口和对后端服务的路由, Istio在当前的 V1alpha3中引入的 Gateway只是描述服务的外部访问,而服务的内部路由都在 VirtualService中定义,从而解耦服务的外部入口和服务的内部路由
    • selector:必选字段,表示 Gateway负载,为入口处的 Envoy运行的 Pod的标签,通过这个标签来找到执行 Gateway规则的 Envoy
    • server:必选字段,表示开放的服务列表,是 Gateway的关键内容信息,是一个数组,每个元素都是 Server类型
1.后端服务Server
  • Server在结构上真正定义了服务的访问入口,可通过 port、 hosts、 defaultEndpoint和 tls来描述
    • port:必选字段,描述服务在哪个端口对外开放,是对外监听的端口
    • hosts:必选字段,为 Gateway发布的服务地址,是一个 FQDN域名,可以支持左侧通配符来进行模糊匹配。注意:在 Istio 1. 1的 Gateway中支持在 hosts匹配时使用命名空间的过滤条件。绑定到一个 Gateway上的 VirtualService必须匹配这里的 hosts条件,支持精确匹配和模糊匹配。Istio 1. 1在 VirtualService中增加的 exportTo字段,只有对应的 VirtualService的 exporTo包含 Gateway的命名空间,对应的关联才会生效
    • defaultEndpoint:是 Istio 1. 1新增的属性,表示流量转发的默认后端,可以是一个 loopback的后端,也可以是 UNIX的域套接字
    • tls:在实际使用中考虑到安全问题,在入口处都通过 HTTPS的安全协议访问

3.4.3 Gateway的典型应用

1.将网格内的 HTTP服务发布为 HTTP外部访问
2.将网格内的 HTTPS服务发布为 HTTPS外部访问
  • 在实际使用中更多的是配置 HTTPS等安全的外部访问
  • Istio支持通过这种方式把服务发布成外部可访问,但更推荐的是下面的做法,即将网格内一个 HTTP的服务通过 Gateway发布为 HTTPS外部访问
3.将网格内的 HTTP服务发布为 HTTPS外部访问
4.将网格内的 HTTP服务发布为双向 HTTPS外部访问
5.将网格内的 HTTP服务发布为 HTTPS外部访问和 HTTPS内部访问

3.5 Istio外部服务配置:ServiceEntry

  • 在 Istio中提供了 ServiceEntry的配置,将网格外的服务加入网格中,像网格内的服务一样进行管理。在实现上就是把外部服务加入 Istio的服务发现,这些外部服务因为各种原因不能被直接注册到网格中

3.5.1 ServiceEntry配置示例

3.5.2 ServiceEntry规则的定义和用法

3.5.3 ServiceEntry的典型应用

3.6 Istio代理规则配置:Sidecar

  • Sidecar这个全新的资源对象是 Istio在 1. 1版本中引入的,用于对 Istio数据面的行为进行更精细的控制

3.6.1 Sidecar配置示例

3.6.2 Sidecar规则定义

  • Sidecar资源对象可以更精细地控制 Envoy转发和接收的端口、协议等,并可以限制 Sidecar Outbound流量允许到达的目标服务集合。
  • 在 Sidecar上主要通过三个字段来描述规则
  • (1) workloadSelector:表示工作负载的选择器。每个命名空间都只能定义一个没有 workloadSelector的 Sidecar,表示对命名空间的全局配置。
  • (2) egress:是一种 IstioEgressListener类型,可用来配置 Sidecar对网格内其他服务的访问,如果没有配置,则只要命名空间可见,命名空间里的服务就都可以被访问。
  • IstioEgressListener通过如下几个字段来描述规则。
  • port:监听器关联的端口,被设定后会作为主机的默认目标端口
  • bind:监听器绑定的地址。
  • captureMode:配置如何捕获监听器的流量,可以有 DEFAULT、 IPTABLES、 NONE三种模式。DEFAULT表示使用环境默认的捕获规则;IPTABLES指定基于 iptabels的流量拦截;NONE表示没有流量拦截。
  • hosts:是一个必选字段,表示监听器的服务,为“ namespace/dnsName”格式。dnsName需要为 FQDN格式,可以对namespace、dnsName使用通配符
  • (3) ingress:IstioIngressListener类型,配置 Sidecar对应工作负载的 Inbound流量。IstioIngressListener字段和 IstioEgressListener字段有点像
    • port:必选字段,监听器关联的端口
    • bind:监听器绑定的地址
    • captureMode:配置如何捕获监听器的流量,该模式的取值同 IstioEgressListener上的对应字段
    • defaultEndpoint:必选字段,为流量转发的目标地址

3.7本章总结

  • Istio流量规则要点总结

规则

说明

规则适用场合

规则覆盖

本地覆盖全局原则

HTTPMatchRequest、TLSMatchAttributes、L4MatchAttributes中对gateways的配置都覆盖VirtualService上的配置;DestinationRulePortTrafficPolicy和Subset中的负载均衡、连接池、异常点检查规则配置,都覆盖DestionationRule上全局的对应配置

组合条件

属性间的“与”逻辑,元素间的“或”逻辑,实现丰富的条件表达能力

在VirtualService的HTTPMatchRequest的TLSMatchAttributes和L4MatchAttributes的条件定义中,各自属性间是“与”逻辑,元素间是“或”逻辑

hosts规则

匹配访问来源的地址;hosts名是一个FQDN域名,支持精确匹配和模糊匹配

VirtualService上的hosts字段:描述VirtualService定义的服务,匹配流量的目标地址TLSMatchAttributes上的sniHosts字段:TLS路由匹配条件,匹配TLS请求的SNI。Gateway的Server上的hosts字段:Gateway后端服务的主机名,匹配服务的外部访问地址。ServiceEntry上的hosts:ServiceEntry的主机名,匹配外部服务地址

hosts服务名

Istio服务发现的服务名。在Kubernetes平台上如果用了短域名,Istio就会根据规则的命名空间来解析服务名

VirtualService上的hosts字段:描述VirtualService定义的服务,匹配流量的目标地址。Destination上的host字段:描述一个目标后端的服务名。DestinationRule上的host字段:描述目标规则适用的服务名

  • 本章了解了Istio提供的诸多流量治理规则及其原理、用法、场景
本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-10-10,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 yeedomliu 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 3.1 Istio流量治理的原理
    • 3.1.1 负载均衡
      • Service Mesh架构,服务发现和负载均衡的工作流程
      • Kubernetes上支持Service的重要组件Kube-proxy
    • 3.1.2 服务熔断
      • Hystrix熔断
      • Istio熔断
    • 3.1.3 故障注入
      • 3.1.4 灰度发布
        • 蓝绿发布
        • AB测试
        • 金丝雀发布
        • 基于负载均衡器的灰度发布
        • 基于Kubernetes的灰度发布
        • 基于Istio的灰度发布
      • 3.1.5 服务访问入口
        • Kuberntes服务的访问入口
        • Istio服务访问入口
      • 3.1.6 外部接入服务治理
      • 3.2 Istio路由规则配置:VirtualService
        • 3.2.1 路由规则配置示例
          • 3.2.2 路由规则定义
            • 3.2.3 HTTP路由(HTTPRoute)
              • HTTPRoute规则解析
              • HTTP匹配规则(HTTPMatchRequest)
              • HTTP路由目标(HTTPRouteDestination)
              • HTTP重定向(HTTPRedirect)
              • HTTP重写(HTTPRewrite)
              • HTTP重试(HTTPRetry)
              • HTTP流量镜像(Mirror)
              • HTTP故障注入(HTTPFaultInjection)
              • HTTP跨域资源共享(CorsPolicy)
            • 3.2.4 TLS路由(TLSRoute)
              • 3.2.6 三种协议路由规则的对比
                • 多个服务的组合
                • 路由规则的优先级
                • 复杂条件路由
                • 特定版本间的访问规则
            • 3.3 Istio目标规则配置:DestinationRule
              • 3.3.1 DestinationRule配置示例
                • 3.3.2 DestinationRule规则定义
                  • 1.流量策略(TrafficPolicy)
                  • 2.负载均衡设置(LoadBalancerSettings)
                  • 3.连接池设置(ConnectionPoolSettings)
                  • 4.异常实例检测设置(OutlierDetection)
                  • 5.端口流量策略设置(PortTrafficPolicy)
                  • 6.服务子集(Subset)
                • 3.3.3 DestinationRule的典型应用
                  • 1.定义Subset
                  • 2.服务熔断
                  • 3.负载均衡配置
                  • 4.TLS认证配置
              • 3.4 Istio服务网关配置:Gateway
                • 3.4.1 Gateway配置示例
                  • 3.4.2 Gateway规则定义
                    • 1.后端服务Server
                  • 3.4.3 Gateway的典型应用
                    • 1.将网格内的 HTTP服务发布为 HTTP外部访问
                    • 2.将网格内的 HTTPS服务发布为 HTTPS外部访问
                    • 3.将网格内的 HTTP服务发布为 HTTPS外部访问
                    • 4.将网格内的 HTTP服务发布为双向 HTTPS外部访问
                    • 5.将网格内的 HTTP服务发布为 HTTPS外部访问和 HTTPS内部访问
                • 3.5 Istio外部服务配置:ServiceEntry
                  • 3.5.1 ServiceEntry配置示例
                    • 3.5.2 ServiceEntry规则的定义和用法
                      • 3.5.3 ServiceEntry的典型应用
                      • 3.6 Istio代理规则配置:Sidecar
                        • 3.6.1 Sidecar配置示例
                          • 3.6.2 Sidecar规则定义
                          • 3.7本章总结
                          相关产品与服务
                          负载均衡
                          负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
                          领券
                          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档