Istio 流量治理

引言
目标规则(DestinationRule)
- 流量策略(TrafficPolicy)
- - tls (ClientTLSSettings)
  - subsets(服务版本子集)
  - portLevelSettings(PortTrafficPolicy[])
  - 负载均衡配置(LoadBalancerSettings)
  - - simple方式
    - hash一致性方式(consistentHash)
    - 区域加权负载均衡(LocalityLoadBalancer)
熔断降级
- 连接池管理
- 异常检测（OutlierDetection 也叫离群检测）
- 服务重试
故障注入(HTTPFaultInjection)
Sidecar配置

引言

流量治理是Istio的核心功能，通过使用Istio可以管理服务网格的服务发现、流量路由、负载均衡，简化服务级属性的配置，例如超时和重试等。

目标规则(DestinationRule)

在东西向流量管理的文章中我们简单的了解过DestinationRule的subsets的作用，配合VirtrualService可以实现基于不同比例和通过header来控制流量导向。

这些规则还可以指定负载均衡的配置、来自Sidecar代理的连接池大小或异常检测的设置，以实现从负载均衡池中检测和驱逐不健康的主机。

DestinationRule定义了在路由发生后，应用于服务(对应host)流量的策略。

流量策略(TrafficPolicy)

在DestinationRule中我们可以配置TrafficPolicy，虽然它不是必须的。

tls (ClientTLSSettings)

我们在南北向流量管理中，也有一个tls设置，还记得吗？不过那是在Gateway网关上的配置，其意义在于从集群外部到服务网格内部的流量设置，这和网格内的流量策略要区分开。
tls的mode有这几种：

栗子:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: db-mtls
spec:host: mydbserver.prod.svc.cluster.localtrafficPolicy:tls:mode: MUTUALclientCertificate: /etc/certs/myclientcert.pemprivateKey: /etc/certs/client_private_key.pemcaCertificates: /etc/certs/rootcacerts.pem

subsets(服务版本子集)

我们在东西向流量管理那篇文章中没有写trafficPolicy，我们可以看见这个字段并不是必须写的，因为当时我们只是想简单的分配比例和通过http headers导向不同版本，所以我们只使用了subsets。
其实我们可以根据subsets也可以定义不同的trafficPolicy，像是这样：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: bookinfo-ratings
spec:host: ratings.prod.svc.cluster.localtrafficPolicy: # 如果没有匹配subsets默认的流策loadBalancer:simple: LEAST_CONNsubsets:- name: testversionlabels:version: v3trafficPolicy: # 看这里哦loadBalancer:simple: ROUND_ROBIN

portLevelSettings(PortTrafficPolicy[])

针对某一具体目标我们可以定义流量策略，这些策略默认对目标服务端的所有端口有效。如果针对某一端口需要定义特定的策略，那么可以通过使用portLevelSettings(PortTrafficPolicy[]类型)来定义，像是这样：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: bookinfo-ratings-port
spec:host: ratings.prod.svc.cluster.localtrafficPolicy: # Apply to all portsportLevelSettings:- port:number: 80loadBalancer:simple: LEAST_CONN- port:number: 9080loadBalancer:simple: ROUND_ROBIN

负载均衡配置(LoadBalancerSettings)

在trafficPolicy中我们看见了loadBalancer，上面2个例子都是使用simple方式的负载均衡算法，Istio其实提供了3种方式。

simple方式

我们先来看看simple提供的4种负载均衡算法:

轮训模式
最少连接
随机
透传

hash一致性方式(consistentHash)

consistentHash的httpCookie栗子：
描述一个HTTP cookie，它将用作Consistent Hash负载平衡器的哈希键。如果不存在Cookie，则会生成它。

 apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:name: bookinfo-ratingsspec:host: ratings.prod.svc.cluster.localtrafficPolicy:loadBalancer:consistentHash:httpCookie:name: userttl: 0s # Cookie的生命周期 必须写

区域加权负载均衡(LocalityLoadBalancer)

熔断降级

Istio提供了一种非常实用且经过良好测试的熔断模式，实现3个状态机，这和Hystrix类似

Closed
Half-Open
Open
关于这3个状态机，这里就不过多解释了，应该都懂。

连接池管理

熔断是分布式系统的重要组成部分，在整个微服务系统中，如果没有熔断，那么极大可能会因为某一服务挂掉导致整个服务雪崩。
Istio采用连接池管理Envoy代理在网络级别实现强制断路限制，而不必独立配置和编写对应每个应用程序的熔断代码。
我们可以通过trafficPolicy.connectionPoll来限制最大连接数和超时时间：

trafficPolicy:connectionPoll:tcp:maxConnections: 100connectTimeout: 30mshttp:http2MaxRequests: 1000maxRequestsPerConnection: 10

关于connectionPoll.tcp:

关于connectionPoll.http:

异常检测（OutlierDetection 也叫离群检测）

异常检测OutlierDetection是Istio中熔断具体实现，英文直译离群检测，是因为一旦达到需要移除的阈值就会被移出连接池。用于跟踪上游服务中每个主机的状态，适用于HTTP和TCP服务。对于HTTP服务来说，在预定时间段内，持续返回API调用的5XX错误的主机将在连接池中被移除。对于TCP服务来说，连接超时或连接失败将认为异常。
白话的理解就是连接池负责熔断降级，异常检测负责将被降级或错误的服务移出连接池。
在不使用Istio的情况下我们只能做到熔断降级，快速返回熔断后被降级服务的响应。

优点:以前Hystrix只是针对单个服务实例的熔断降级，而在微服务集群下，也许我们想要的是相同的服务均摊限流策略(有时候我们并不是用轮训规则选择服务)，而不是针对单个实例。所以Sentinel加入了集群限流模式，但是有时候我们的这些服务实例也许机器配置不同，集群限流模式下也许会让比较差的服务器跟不上更高配置的机器。Istio的这种基础架构上的异常离群检测可以将单个服务实例暂时移出集群，比起集群限流来说更稳定。

我们可以通过trafficPolicy.outlierDetection来配置异常检测：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: test-policy
spec:host: test.prod.svc.cluster.localtrafficPolicy:connectionPool:tcp:maxConnections: 1 # TCP最大连接数http:http1MaxPendingRequests: 1 # HTTP1.1 等待就绪连接池连接时排队的最大请求数http2MaxRequests: 1 # HTTP2最大请求数maxRequestsPerConnection: 1 # 一个连接内能够发出的最大请求数，如果为1那么就不会保持keepalive特性，因为这个连接只能发一次请求，也就不需要长连接了。outlierDetection: # 异常检测consecutiveErrors: 1 # 连续错误数量interval: 1s # 移除检测的时间间隔baseEjectionTime: 1m # 最小的移除时间长度，主机每次被移除后的隔离时间=移除次数*最小的移除时间长度maxEjectionPercent: 100 # 上游服务的负载均衡池中允许被移除主机的最大百分比，默认是10%

我们测试后，可以使用下面的命令进入pod中的sidecar代理查看关于upstream_rq_pending_xx日志。
upstream_rq_pending_overflow记录的是熔断次数。

kubectl exec it -n 命名空间 pod名 -c istio-proxy -- sh -c ‘curl localhost:15000/status’ | grep 服务名 | grep pending

服务重试

注意：这里开始是在VirtualService中了哦，不是DestinationRule.
Istio的VirtualService提供了用于定义HTTP请求失败时的重试策略。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: test-vs
spec:hosts:- test.prod.svc.cluster.localhttp:- route:- destination:host: test.prod.svc.cluster.localsubset: v1retries:attempts: 3 # 给定请求的重试次数。重试之间的时间间隔将自动确定（25毫秒以上）perTryTimeout: 2s # 给定请求的每次重试尝试超时retryOn: 5xx,gateway-error,connect-failure,refused-stream # 指定重试发生的条件。可以使用“，”分隔列表指定一个或多个策略

故障注入(HTTPFaultInjection)

故障注入HTTPFaultInjection用于在将HTTP请求转发到路由中指定的目标时，指定要注入的一个或多个故障。故障规范是虚拟服务规则的一部分，包括从下游服务终止HTTP请求、延迟请求的代理等。
故障注入是混沌工程（说白话就是模拟故障）中经常用的一种手段。Istio支持2种故障注入手段(中断abort和延迟delay)。

混沌工程，是一种提高技术架构弹性能力的复杂技术手段。Chaos工程经过实验可以确保系统的可用性。混沌工程旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: test-vs
spec:hosts:- test.prod.svc.cluster.localhttp:- route:- destination:host: test.prod.svc.cluster.localfault:#abort: # 表示将50%的请求直接返回502错误#  httpStatus: 502#  percentage:#    value: 0.5delay: # 表示将50%的请求延迟5秒 如果是abort就是直接返回定义的错误fixedDelay: 5spercentage:value: 0.5

Sidecar配置

默认情况下，Istio将使用到达网格中每个工作负载实例所需的必要配置对网格中的所有Sidecar代理进行编程，并在与工作负载相关的所有端口上接受流量。Sidecar配置提供了一种方法，可以微调代理在与工作负载之间来回通信时，代理将接受的端口集，协议。此外，可以限制从工作负载实例转发出站流量时，代理可以访问的服务集。
注意:每个命名空间下只允许存在一个没有workloadSelector的Sidecar配置。
默认情况下如果该命名空间下没有Sidecar配置将使用根命名空间istio-config中的Sidecar配置。

注意：这里说的是Sidecar是资源，不是之前所说的Sidecar代理模式。
Sidecar资源包含了4个部分

IstioIngressListener在附加到工作负载实例的Sidecar代理上指定入站流量侦听器的属性。

IstioEgressListener在附加到工作负载实例的Sidecar代理上指定出站流量侦听器的属性。

栗子：

这个栗子在根命名空间istio-config下声明了一个全局默认的Sidecar配置，它将所有命名空间中的Sidecar配置为出口流量只允许到同命名空间(并不是istio-config,而是指用了全局默认配置的命名空间本身)或istio-system命名空间中的工作负载服务。

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:name: defaultnamespace: istio-config
spec:egress:- hosts: - "./*"- "istio-system/*"

针对性的栗子：

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:name: ratingsnamespace: prod-us1
spec:workloadSelector:labels:app: ratingsingress:- port:number: 9080protocol: HTTPname: somenamedefaultEndpoint: unix:///var/run/someuds.sockegress:- hosts:- "prod-us1/*"port:number: 9080protocol: HTTPname: egresshttp- hosts:- "istio-system/*"

上面的栗子是说，在prod-us1命名空间下，配置pod或VM标签为app:ratings的工作负载实例使用此Sidecar配置进行限制，入口限制为仅允许9080端口（HTTP协议），并将它们转发到附加的工作负载实例的unix套接字上。
对于出口流量只允许访问prod-us1命名空间下9080端口的服务，或istio-system命名空间下的所有服务。
注意:因为我们写了workloadSelector，所以prod-us1命名空间下还可以创建其他的Sidecar配置。

Istio 流量治理相关推荐

Istio服务网格进阶⑦：Istio流量治理之故障注入与重试
文章目录 1.Istio故障注入与重试的概念 1.1.故障注入 1.2.重试 2.配置Istio中应用程序的故障注入以及重试 2.1.案例描述 2.2.在Istio中部署Nginx服务 2.3.在Is ...
使用 Istio 实现非侵入流量治理
现在最火的后端架构无疑是微服务了,微服务将之前的单体应用拆分成了许多独立的服务应用,每个微服务都是独立的,好处自然很多,但是随着应用的越来越大,微服务暴露出来的问题也就随之而来了,微服务越来越多,管理 ...
“天猫双11”背后的流量治理技术与标准实践
赵奕豪(宿何):Sentinel & OpenSergo 开源项目负责人一年一度的天猫双11已经落下帷幕,大家在疯狂买买买的过程中一定会有疑问:如何保障微服务在双十一的超级峰值下也能如丝般顺 ...
亿级流量治理系列：常用的限流算法有哪些？
前言上篇文章<为什么大公司都要做流量治理?>跟大家聊了下做流量治理的真正目的是什么.如果你要开发一个流量治理的平台或者一个限流的框架,那么必不可少的就是要选择一种合适的限流算法.本篇文章 ...
微服务引擎的线上流量治理最佳实践
简介:本实践将重点介绍如何快速集成主流开源微服务框架,实现业务零改造,解决开源框架在生产落地过程中的痛点,例如无损上下线.标签路由等,并通过托管微服务开源组件(API网关.注册中心.配置中心等)的服务 ...
MSE 治理中心重磅升级-流量治理、数据库治理、同 AZ 优先
作者:流士本次 MSE 治理中心在限流降级.数据库治理及同 AZ 优先方面进行了重磅升级,对微服务治理的弹性.依赖中间件的稳定性及流量调度的性能进行全面增强,致力于打造云原生时代的微服务治理平台. ...
分布式架构-流量治理-流量控制
系列目录分布式架构-流量治理-服务容错分布式架构-流量治理-流量控制引子任何一个系统的运算.存储.网络资源都不是无限的,当系统资源不足以支撑外部超过预期的突发流量时,便应该要有取舍,建立面对超 ...
流量治理Sentinel dashboard K8S部署
1. 前言 Sentinel 是面向分布式.多语言异构化服务架构的流量治理组件,主要以流量为切入点,从流量路由.流量控制.流量整形.熔断降级.系统自适应过载保护.热点流量防护等多个维度来帮助开发者保障 ...
流量治理最大的痛点-资源利用率上不去
Python微信订餐小程序课程视频 https://edu.csdn.net/course/detail/36074 Python实战量化交易理财系统 https://edu.csdn.net/cou ...

Istio 流量治理

Istio 流量治理

引言

目标规则(DestinationRule)

流量策略(TrafficPolicy)

tls (ClientTLSSettings)

subsets(服务版本子集)

portLevelSettings(PortTrafficPolicy[])

负载均衡配置(LoadBalancerSettings)

simple方式

hash一致性方式(consistentHash)

区域加权负载均衡(LocalityLoadBalancer)

熔断降级

连接池管理

异常检测（OutlierDetection 也叫离群检测）

服务重试

故障注入(HTTPFaultInjection)

Sidecar配置

Istio 流量治理相关推荐

最新文章

热门文章

Istio 流量治理

Istio 流量治理

引言

目标规则(DestinationRule)

流量策略(TrafficPolicy)

tls (ClientTLSSettings)

subsets(服务版本 子集)

portLevelSettings(PortTrafficPolicy[])

负载均衡配置(LoadBalancerSettings)

simple方式

hash一致性方式(consistentHash)

区域加权负载均衡(LocalityLoadBalancer)

熔断降级

连接池管理

异常检测（OutlierDetection 也叫离群检测）

服务重试

故障注入(HTTPFaultInjection)

Sidecar配置

Istio 流量治理相关推荐

最新文章

热门文章

subsets(服务版本子集)