淘客网站建设视频,做网站的怎样能翻页,怎样建设网站 需要哪些条件,网站设计内容包括1、xDS协议
1#xff09;、xDS是什么
xDS是一类发现服务的总称#xff0c;包含LDS、RDS、CDS、EDS以及SDS。Envoy通过xDS API可以动态获取Listener#xff08;监听器#xff09;、Route#xff08;路由#xff09;、Cluster#xff08;集群#xff09;、Endpoint、xDS是什么
xDS是一类发现服务的总称包含LDS、RDS、CDS、EDS以及SDS。Envoy通过xDS API可以动态获取Listener监听器、Route路由、Cluster集群、Endpoint集群成员以及Secret证书配置 LDSListener发现服务。Listener监听器控制Envoy启动端口监听目前只支持TCP协议并配置L3/L4层过滤器当网络连接达到后配置好的网络过滤器堆栈开始处理后续事件。这种通用的监听器体系结构用于执行大多数不同的代理任务限流、客户端认证、HTTP连接管理、TCP代理等 RDSRoute发现服务用于HTTP连接管理过滤器动态获取路由配置。路由配置包含HTTP头部修改增加、删除HTTP头部键值、Virtual Hosts虚拟主机以及Virtual Hosts定义的各个路由条目 CDSCluster发现服务用于动态获取Cluster信息。Envoy Cluster管理器管理着所有的上游Cluster。鉴于上游Cluster或者主机可用于任何代理转发任务所以上游Cluster一般从Listener或Route中抽象出来 EDSEndpoint发现服务。在Envoy术语中Cluster成员就叫Endpoint对于每个ClusterEnvoy通过EDS API动态获取Endpoint。EDS作为首选的服务发现的原因有两点 与通过DNS解析的负载均衡器进行路由相比Envoy能明确的知道每个上游主机的信息因而可以做出更加智能的负载均衡决策Endpoint配置包含负载均衡权重、可用域等附加主机属性这些属性可用于服务网格负载均衡、统计收集等过程中 SDSSecret发现服务用于运行时动态获取TLS证书。若没有SDS特性在Kubernetes环境中必须创建包含证书的Secret代理启动前Secret必须挂载到Sidecar容器中如果证书过期则需要重新部署。使用SDS集中式的SDS服务器将证书分发给所有的Envoy实例如果证书过期服务器会将新的证书分发Envoy接收到新的证书后重新加载即可不用重新部署
2、ADS的演进
1Why ADS Istio 0.8以前Pilot提供的单一资源的DS
每种资源需要一条单独的连接Istio高可用环境下可能部署多个Pilot
带来的挑战
没办法保证配置资源更新的顺序多Pilot配置资源的一致性没法保证
综合以上两个问题很容易出现配置更新过程中网络流量丢失带来网络错误
ADS是一种xDS的实现它基于gRPC长连接允许通过一条连接gRPC的同一stream发送多种资源的请求和响应
能够保证请求一定落在同一Pilot上解决多个管理服务器配置不一致的问题通过顺序的配置分发轻松解决资源更新顺序的问题
2ADS最终一致性的考量
xDS是一种最终一致的协议所以在配置更新过程中流量会丢失
例如如果通过CDS/EDS获得Cluster X一条指向Cluster X的RouteConfiguration刚好调整为指向Cluster Y但是在CDS、EDS还没来得及下发Cluster Y的配置的情况下路由到Cluster Y的流量会全部被丢弃并且返回给客户端状态码503
在某些场景下流量丢弃是不可接受的。Istio通过遵循make before break模型调整配置更新顺序可以完全避免流量丢失
CDS的更新必须先进行请求资源的名称为空EDS的更新必须在CDS的更新之后进行并且EDS的更新需要指定CDS获取的相关集群名称LDS的更新必须在CDS或EDS的更新之后进行请求资源的名称为空RDS的更新必须在LDS的更新之后进行因为RDS的更新与LDS新加的监听器有关在请求过程中必须指定新的监听器的路由名称 Envoy通过gRPC与某个特定的Pilot实例建立连接。Pilot通过简单的串行分发配置方式保证xDS的更新顺序按照CDS-EDS-LDS-RDS的顺序进行Envoy以相同的顺序加载配置
2、Istio Pilot源码 基于Istio 1.18.0版本源码 1、Pilot工作原理
Pilot-Discovery是Istio控制面的核心负责服务网格中的流量管理以及控制面和数据面之间的配置下发 Pilot-Discovery从注册中心如Kubernetes获取服务信息并汇集从Kubernetes API Server中获取配置规则将服务信息和配置数据转换为xDS接口的标准数据结构通过GRPC下发到数据面的Envoy Pilot Server中主要包含三部分逻辑
ConfigController管理各种配置数据包括用户创建的流量管理规则和策略ServiceController获取Service Registry中的服务发现数据DiscoveryService主要包含下述逻辑 启动GRPC Server并接收来自Envoy端的连接请求接收Envoy端的xDS请求从ConfigController和ServiceController中获取配置和服务信息生成响应消息发送给Envoy监听来自ConfigController的配置变化消息和ServiceController的服务变化消息并将配置和服务变化内容通过xDS接口推送到Envoy
2、Pilot启动流程 3、ConfigController工作机制
ConfigController为每种Config资源都创建了一个Informer用于监听所有Config资源并注册EventHandler 完整的Config事件处理流程如下图所示 EventHandler构造任务Task任务实际上是对onEvent函数的封装EventHandler将任务推送到任务队列中任务处理协程阻塞式地读取任务队列执行任务通过onEvent方法处理事件并通过ConfigHandler触发xDS的更新
4、ServiceController工作机制
ServiceController为4种资源分别创建了Informer用于监听Kubernetes资源的更新并为其注册EventHandler 当监听到Service、Endpoint、Pod、Node资源更新时EventHandler会创建资源处理任务并将其推送到任务队列然后由任务处理协程阻塞式地接收任务对象最终调用任务处理函数完成对资源对象的事件处理 5、xDS的异步分发
1DiscoveryService初始化 StreamAggregatedResources接收DiscoveryRequest返回DiscoveryResponse流包含全量的xDS数据 2DiscoveryServer启动
DiscoveryServer的Start()方法启动两个重要的goroutinehandleUpdates和sendPushes
Config、Service、Endpoint对资源的处理最后都会调用ConfigUpdate()方法向DiscoveryServer的pushChannel队列发送PushRequest实现的处理流程如下 DiscoveryServer首先通过handleUpdates协程阻塞式地接收并处理更新请求并将PushRequest发送到DiscoveryServer的pushQueue中然后由sendPushes协程并发地将PushRequest发送给每一条连接的pushChannel最后由DiscoveryServer的流处理接口处理分发请求
3handleUpdates
DiscoveryServer.Push方法会一直往下调用直到把数据推入到DiscoveryServer的pushQueue管道中代码调用逻辑如下 4sendPushes
doSendPushes()方法内启动了一个无限循环在default代码块中实现了主要的功能逻辑
push事件面向所有xDS客户端使用semaphore来控制推送并发数当semaphore满了之后会阻塞如果semaphore允许为每个客户端都启动一个发送协程尝试发送pushEvent到客户端队列pushChannel中
每个客户端在通过pushConnection将本次xDS推送完后都会调用pushEv.done()方法通知semaphore
从pushQueue到最终推送xDS配置流程如下图 5xDS配置的生成与分发
pushConnection()方法核心逻辑如下
根据资源的变化情况判断是否需要为该Envoy代理更新xDS如果不需要更新直接返回 如果变更的clusterScopedConfigTypes类型配置在root namespace或相同namespace需要xDS推送如果SidecarScope包含对应配置需要进行xDS推送 遍历该Envoy代理监听的资源类型根据订阅的资源类型生成xds配置并发送到客户端
6小结
配置变化后向Envoy推送xDS时序 响应Envoy主动发起的xDS时序 3、Istio落地问题总结 基于Istio 1.10版本落地问题总结 1、xDS全量下发问题
1Istio在大规模场景下xDS性能瓶颈
当前Istio下发xDS使用的是全量下发策略也就是网格里的所有Sidecar内存里都会有整个网格内所有的服务发现数据。比如下图虽然workload1在业务逻辑上只依赖service2但是Istiod会把全量的服务发现数据service2、3、4都发送给workload1 这样的结果是每个Sidecar内存都会随着网格规模增长而增长如果网格规模超过1万个实例单个Envoy的内存超过了250MiB而整个网格的开销还要再乘以网格规模大小
2Istio当前优化方案
针对这个问题社区提供了一个方案就是Sidecar这个CRD这个配置可以显式的定义服务之间的依赖关系或者说可见性关系。比如下图这个配置的意思就是workload1只依赖service2这样配置以后Istiod只会下发service2的信息给workload1 这个方案本身是有效的。但这种方式在大规模场景下很难落地首先这个方案需要用户提前配置服务间完整的依赖关系大规模场景下的服务依赖关系很难梳理清楚而且通常依赖关系也会随着业务的变化而变化
3Aeraki Lazy xDS
针对上述问题腾讯开源的Aeraki Lazy xDS和网易开源的Slime lazyload都是基于相同思路解决的以Aeraki Lazy xDS为例实现细节如下
在网格里增加2个组件一个是Lazy xDS EgressEgress充当类似网格模型中默认网关角色另一个是Lazy xDS Controller用来分析并补全服务间的依赖关系
首先配置Egress的服务中转能力Egress会获取网格内所有服务信息并配置所有HTTP服务的路由这样充当默认网关的Egress就可以转发网格内任意HTTP服务的流量第2步对于开启了按需加载特性的服务图中Workload1利用EnvoyFilter将其访问网格内HTTP服务的流量都路由到Egress第3步利用Istio Sidecar CRD限制Workload1的服务可见性经过步骤3后Workload1初始只会加载最小化的xDS当Workload1发起对Service2的访问时因为步骤2流量会转发到Egress因为步骤1Egress会分析接收到的流量特征并将流量转发到Service2Egress会将访问日志异步地上报给Lazy xDS Controller上报服务是利用Access Log ServiceLazy xDS Controller会对接收到的日志进行访问关系分析然后把新的依赖关系Workload1 - Service2表达到Sidecar CRD中同时Controller还会将步骤2Workload1需要转发Service2流量到Egress的规则去除这样未来Workload1再次访问Service2就会是直连因为步骤8Istiod更新可见性关系后续会将Service2的服务信息发给Workload1Workload1通过xDS接收到Service2的服务信息当Workload1再次发起对Service2的访问流量会直达Service2因为步骤9
这个方案的好处
不需要用户提前配置服务间的依赖而且服务间依赖是允许动态的增加的最终每个Envoy只会获得自身需要的xDS性能最优这个实现对用户流量影响也比较小用户的流量不会阻塞。性能损耗也比较小只有前几次请求会在Egress做中转后面都是直连的此方案对Istio和Envoy没有任何入侵没有修改Istio/Envoy源码使得这套方案能很好的适应未来Istio的迭代
目前只支持七层协议服务的按需加载原因是流量在Egress这里中转的时候Egress需要通过七层协议里的header判断原始目的地。纯TCP协议是没有办法设置额外的header。不过因为Istio主要目的就是为了做七层流量的治理当网格的大部分请求都是七层的这个情况目前可以接受的
相关资料
Aeraki Lazy xDS
Slime lazyload
2、EnvoyFilter推送范围改造
变更EnvoyFilter时xDS推送范围变更istio-system namespaceroot namespace下的EnvoyFilter会触发全局xDS推送全局生效变更namespaceA下的EnvoyFilter会触发namespaceA下所有边车的xDS推送同namespace下生效
问题点在Pod所在的namespace添加只针对单个Pod生效的EnvoyFilter通过workLoadSelector限制但实际会触发同namespace下所有Pod边车的xDS推送 使用场景
通过EnvoyFilter对实例入口请求限流EnvoyFilter上通过workLoadSelector限制只针对单个Pod生效在限流期间会频繁调整EnvoyFilter中的限流值来达到自适应限流的效果根据CPU变化调节限流QPSEnvoyFilter的workLoadSelector基本不变会频繁修改EnvoyFilter
针对我们的使用场景频繁修改只针对单个Pod生效的EnvoyFilter但每次修改会触发同namespace下所有边车的xDS推送是不可接受的所以进行了定制化改造让带workLoadSelector的EnvoyFilter只触发workLoadSelector范围内的边车的xDS推送
原始逻辑Istiod在推送xDS前会遍历所有的Envoy判断是否为该Envoy推送xDSpilot/pkg/model/sidecar.go中的DependsOnConfig()方法判断逻辑如下图 改造后逻辑这里最重要的是要考虑EnvoyFilter的workLoadSelector变更的场景如果EnvoyFilter的workLoadSelector变更时保持原始推送判断逻辑root namespace全局xDS推送其他namespace同namespace下xDS推送 3、优化Istiod启动时ServiceEntry处理速度
问题点 Istiod启动时list到所有istio-config namespace下的CRD信息Istiod内部serviceEntryHandler方法会逐个处理list到的ServiceEntry设置refreshIndexestrue调用edsUpdateByKeys()方法每个ServiceEntry处理时都会将refreshIndexestrue调用edsUpdateByKeys()方法后会触发mayBeRefreshIndexs()方法refreshIndexestrue时才会执行处理逻辑遍历所有ServiceEntry和对应Instance数据转换为ServiceInstance。执行一次耗时2s左右Istiod启动时serviceEntryHandler处理完所有ServiceEntry数据1000个ServiceEntry总耗时在10min以上
改造后逻辑 Istiod启动时list到所有istio-config namespace下的CRD信息Istiod内部serviceEntryHandler方法会逐个处理list到的ServiceEntry将ServiceEntry添加到toBeSyncedServiceEntry一个map写入时加锁中启动一个goroutine定时500ms执行PeriodicSyncServiceEntry()方法PeriodicSyncServiceEntry()方法取出所有toBeSyncedServiceEntry中的ServiceEntry处理过程中加锁设置refreshIndexestrue调用edsUpdateByKeys()方法批量处理取出的ServiceEntry这样无需每个ServiceEntry处理时都触发mayBeRefreshIndexs()方法而是每次取出一批ServiceEntry只会触发一次mayBeRefreshIndexs()方法优化后Istiod启动时serviceEntryHandler处理完所有ServiceEntry数据1000个ServiceEntry总耗时在30s左右
注意Istiod需要等待PeriodicSyncServiceEntry()方法处理完第一次list到的所有ServiceEntry后才启动DiscoveryService接收来自Envoy端的连接请求否则会导致Envoy拿不到未处理完的ServiceEntry相关数据主要是CDS和EDS导致Envoy调用下游发生503response_flagNC
解决方案
设置一个标志位当PeriodicSyncServiceEntry()方法处理完第一次list到的所有ServiceEntry后将标志位设置为trueServiceEntryStore的HasSynced()方法中返回标志位状态pilot/pkg/bootstrap/server.go中的waitForCacheSync()方法判断所有的registry处理ServiceEntry的为serviceEntryStore都返回true后才会启动DiscoveryService接收来自Envoy端的连接请求
4、Sidecar启动顺序
问题点由于Pod内容器按照spec.containers中的声明顺序依次启动而initContainers会在所有容器启动前执行所以容器的启动顺序是这样的istio-init修改Pod内iptables使得istio-proxy接管Pod内所有流量使应用容器内的所有网络请求都需要经过istio-proxy而应用容器启动的过程中如果发起网络请求请求配置中心获取配置等此时istio-proxy有可能还没有启动完成导致网络异常
Istio 1.7版本的解决方案
方式一安装Istio时全局设置
# 默认使用default profile(可通过--set profiledefault|demo|...调整)
istioctl install
# 设置sidecar优先启动(且sidecar启动成功后再启动其他应用容器)-1.7新特性
--set values.global.proxy.holdApplicationUntilProxyStartstrue方式二在应用Deployment通过annotation设置
annotations:# 重点:配置proxy-设置proxy启动成功后再启动其他应用proxy.istio.io/config: |holdApplicationUntilProxyStarts: trueholdApplicationUntilProxyStarts启用效果
spec:initContainers:- name: istio-init...containers:- name: istio-proxy...lifecycle:postStart:exec:command:- pilot-agent- wait将sidecar istio-proxy容器放到Pod containers中的第一位即最先启动设置istio-proxy lifecycle已保证sidecar容器启动成功前一直阻塞阻塞Pod内其他容器启动
5、HTTP1.0支持
问题点Istio使用Envoy作为数据面转发HTTP请求而Envoy默认要求使用HTTP/1.1或HTTP/2当客户端使用HTTP/1.0时就会返回426 Upgrade Required
解决方案编辑istioctl安装配置项文件
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:values:pilot:env:PILOT_HTTP10: 1...istio-proxy容器中会添加环境变量ISTIO_META_HTTP101使得Envoy支持HTTP/1.0
问题点Envoy支持HTTP/1.0后会有delay close timeout 1s的问题默认情况HTTP/1.0的请求有1s的延迟
解决方案通过EnvoyFilter修改delayed_close_timeout为0s
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:name: delayed-close-timeout-filternamespace: istio-system
spec:configPatches:- applyTo: NETWORK_FILTERmatch:listener:filterChain:filter:name: envoy.filters.network.http_connection_managerpatch:operation: MERGEvalue:typed_config:type: -type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManagerdelayed_close_timeout: 0s相关资料
Istio 常见问题 - Istio 支持 HTTP/1.0
6、Header大小写敏感
问题点 Envoy默认会将HTTP header统一转换为小写例如有一个HTTP header为X-UserId: 12345经过Envoy代理后会变成x-userid: 12345。HTTP的RFC规范也要求应用不能对header大小写敏感但有些应用没有遵循RFC规范对大小写敏感了导致开启Mesh后报错
解决方案通过EnvoyFilter让Envoy保留HTTP header大小写
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:name: header-casing-filternamespace: istio-system
spec:configPatches:- applyTo: CLUSTERmatch:context: SIDECAR_INBOUNDpatch:operation: MERGEvalue:typed_extension_protocol_options:envoy.extensions.upstreams.http.v3.HttpProtocolOptions:type: -type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptionscommonHttpProtocolOptions:idleTimeout: 20suse_downstream_protocol_config:http_protocol_options:header_key_format:stateful_formatter:name: preserve_casetyped_config:type: -type.googleapis.com/envoy.extensions.http.header_formatters.preserve_case.v3.PreserveCaseFormatterConfig- applyTo: CLUSTERmatch:context: SIDECAR_OUTBOUNDpatch:operation: MERGEvalue:typed_extension_protocol_options:envoy.extensions.upstreams.http.v3.HttpProtocolOptions:type: -type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptionscommonHttpProtocolOptions:idleTimeout: 20suse_downstream_protocol_config:http_protocol_options:header_key_format:stateful_formatter:name: preserve_casetyped_config:type: -type.googleapis.com/envoy.extensions.http.header_formatters.preserve_case.v3.PreserveCaseFormatterConfig- applyTo: NETWORK_FILTERmatch:listener:filterChain:filter:name: envoy.filters.network.http_connection_managerpatch:operation: MERGEvalue:typed_config:type: -type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManagerhttp_protocol_options:header_key_format:stateful_formatter:name: preserve_casetyped_config:type: -type.googleapis.com/envoy.extensions.http.header_formatters.preserve_case.v3.PreserveCaseFormatterConfig7、重复Header处理
问题点 未开启Mesh时Spring MVC遇到重复Content-Type情况下取第一个 开启Mesh后Envoy把重复Content-Type使用逗号拼接Spring MVC不识别拼接后的Content-Type报错415 Unsupported Media Type
解决方案通过EnvoyFilter当出现两个Content-Type时仅保留一个
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:name: double-header-filternamespace: istio-system
spec:configPatches:- applyTo: HTTP_FILTERmatch:context: SIDECAR_INBOUNDlistener:filterChain:filter:name: envoy.filters.network.http_connection_managersubFilter:name: envoy.filters.http.routerpatch:operation: INSERT_BEFOREvalue:name: envoy.luatyped_config:type: type.googleapis.com/envoy.extensions.filters.http.lua.v3.LuainlineCode: |function envoy_on_request(request_handle)local function is_empty(input)return input nil or input endorigin_type request_handle:headers():get(content-type)if not is_empty(origin_type) thenlocal type_table {}for type in origin_type:gmatch(([^,]),?) do table.insert(type_table, type)endif table.getn(type_table)0 thenrequest_handle:headers():replace(content-type, type_table[1]) endtype_table nilendend- applyTo: HTTP_FILTERmatch:context: SIDECAR_OUTBOUNDlistener:filterChain:filter:name: envoy.filters.network.http_connection_managersubFilter:name: envoy.filters.http.routerpatch:operation: INSERT_BEFOREvalue:name: envoy.luatyped_config:type: type.googleapis.com/envoy.extensions.filters.http.lua.v3.LuainlineCode: |function envoy_on_request(request_handle)local function is_empty(input)return input nil or input endorigin_type request_handle:headers():get(content-type)if not is_empty(origin_type) thenlocal type_table {}for type in origin_type:gmatch(([^,]),?) do table.insert(type_table, type)endif table.getn(type_table)0 thenrequest_handle:headers():replace(content-type, type_table[1]) endtype_table nilendend8、Passthrough内存增高
问题点部分站点开启Mesh后边车内存缓慢持续增长且不释放这些站点的特点是接入的sdk是存在定期的Passthrough调用 对同一个站点Passthrough调用eureka的频率进行调整做对比结果如下
调用eureka的频率不调用1s调用一次30s调用一次是否会导致边车内存缓慢持续增长不会不会会
根因边车对于走Passthrough的下游超过5s未调用边车会清理下游主机、连接数据等清理过程中存在bug会导致内存泄漏
GitHub issuehttps://github.com/envoyproxy/envoy/issues/22218
解决方案调大清理间隔
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:name: cleanup-interval-filternamespace: istio-system
spec:configPatches:- applyTo: CLUSTERmatch:cluster:name: PassthroughClustercontext: SIDECAR_OUTBOUNDpatch:operation: MERGEvalue:cleanup_interval: 1h- applyTo: CLUSTERmatch:context: SIDECAR_INBOUNDpatch:operation: MERGEvalue:cleanup_interval: 1h相关资料
边车cleanup_interval参数文档
9、偶发503问题
问题点客户端直接访问服务端正常但开启Mesh后经过Envoy访问服务端则会出现一定几率的503错误response code503, response flagUC
根因
Envoy的HTTP Router会在第一次和Upstream建立TCP连接并使用后将连接释放到一个连接池中而不是直接关闭该连接。这样下次downstream请求相同的Upstream host时可以重用该连接可以避免频繁创建/关闭连接带来的开销
当连接被Envoy放入连接池后连接中不再转发来自downstream数据即连接处于空闲状态。连接对端的应用程序会检查连接的空闲状态并在空闲期间通过TCP keepalive packet来侦测对端状态。由于空闲的连接也会占用资源因此应用并不会无限制地在一个空闲连接上进行等待。几乎所有语言/框架在创建TCP服务器时都会设置一个keepalive timeout选项如果在keepalive timeout的时间内没有收到新的TCP数据包应用就会关闭该连接 在应用端关闭连接后的极短时间内Envoy侧尚未感知到该连接的状态变化如果此时Envoy收到了来自downstream的请求并将该连接从连接池中取出来使用就会出现503 UC upstream_reset_before_response_started{connection_termination}异常
总结Envoy Inbound和应用的HttpServerTomcat或者其他HttpServer在Http1.1 keep-alive的情况下HttpServer的空闲连接超时释放时间比Envoy默认的要短Envoy默认1小时当Envoy正在使用连接时应用的HttpServer要释放空闲连接时会产生冲突造成503
解决方案调整Inbound的idleTimeout为20s短于HttpServer的idleTimeout
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:name: http-idle-timeoutnamespace: istio-system
spec:configPatches:- applyTo: CLUSTERmatch:context: SIDECAR_INBOUNDpatch:operation: MERGEvalue:typedExtensionProtocolOptions:envoy.extensions.upstreams.http.v3.HttpProtocolOptions:type: -type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptionscommonHttpProtocolOptions:idleTimeout: 20s相关资料
关于 istio-proxy 503/504等5xx问题排查
Istio503、UC 和 TCP
细说Http中的Keep-Alive和Java Http中的Keep-Alive机制
503 UC upstream_reset_before_response_started
10、源IP地址保持
问题点 开启Mesh后应用无法获取客户端的源IP地址获取到的地址为127.0.0.6
方案一使用TPROXY代理
Istio支持两种拦截模式
REDIRECT使用iptables的REDIRECT目标来拦截入站请求转给EnvoyTPROXY使用iptables的TPROXY目标来拦截入站请求转给Envoy 使用TPROXY代理方式可以通过getRemoteAddr的方式获取对端IP
方案二设置XFF头
七层的客户端源IP都是通过HTTP XFFX-Forwarded-For头实现的XFF保存原始客户端的源IP并透传到后端应用可以解析XFF得到客户端的源IP Envoy提供了设置XFF的方法https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-for
为了防止对其他七层代理的XFF产生影响通过EnvoyFilter写Lua脚本实现Inbound中XFF的设置设置XFF逻辑如果XFF为空设置客户端源IP如果XFF不为空不修改XFF
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:name: add-header-filternamespace: istio-system
spec:configPatches:- applyTo: HTTP_FILTERmatch:context: SIDECAR_INBOUNDlistener:filterChain:filter:name: envoy.filters.network.http_connection_managerpatch:operation: INSERT_BEFOREvalue:name: envoy.luatyped_config:type: type.googleapis.com/envoy.extensions.filters.http.lua.v3.LuainlineCode: |function envoy_on_request(handle)local xff handle:headers():get(X-FORWARDED-FOR)local remote_address handle:streamInfo():downstreamDirectRemoteAddress()if((remote_address ~ nil and remote_address ~ ) and (xff nil or xff ))thenlocal parts {}for part in string.gmatch(remote_address, [^:,]) dotable.insert(parts, part)endlocal client_ip parts[1]handle:headers():add(X-FORWARDED-FOR, client_ip)endend相关资料
Istio中实现客户端源IP的保持
11、边车限流不准问题
1各场景边车限流准确性验证
验证点在每秒限流100qps时以每秒200qps请求验证边车限流是否精准
预期请求成功率稳定为50%
场景1针对整个Inbound限流
直接使用本地限流器EnvoyFilter示例如下
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:name: instanceA.instanceA-namespace.ratelimitnamespace: instanceA-namespace
spec:configPatches:- applyTo: HTTP_FILTERmatch:context: SIDECAR_INBOUNDlistener:filterChain:filter:name: envoy.filters.network.http_connection_managerpatch:operation: INSERT_BEFOREvalue:name: envoy.filters.http.local_ratelimittyped_config:type: type.googleapis.com/udpa.type.v1.TypedStructtype_url: -type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimitvalue:filter_enabled:default_value:denominator: HUNDREDnumerator: 100runtime_key: local_rate_limit_enabledfilter_enforced:default_value:denominator: HUNDREDnumerator: 100runtime_key: local_rate_limit_enforcedstat_prefix: http_local_rate_limitertoken_bucket: # 每秒限流100qpsfill_interval: 1smax_tokens: 100tokens_per_fill: 100workloadSelector:labels:instance: instanceA结果请求成功率能稳定在50% 结论使用本地限流器针对整个Inbound限流时限流精准✅
场景2针对指定请求路径限流
使用descriptors精细化限流EnvoyFilter示例如下
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:name: instanceA.instanceA-namespace.ratelimitnamespace: instanceA-namespace
spec:configPatches:- applyTo: HTTP_ROUTEmatch:context: SIDECAR_INBOUNDpatch:operation: MERGEvalue:route:rate_limits:- actions:- request_headers:descriptor_key: pathheader_name: :path- applyTo: HTTP_FILTERmatch:context: SIDECAR_INBOUND listener:filterChain:filter:name: envoy.filters.network.http_connection_managerpatch:operation: INSERT_BEFOREvalue:name: envoy.filters.http.local_ratelimittyped_config:type: type.googleapis.com/udpa.type.v1.TypedStructtype_url: -type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimitvalue:descriptors:- entries:- key: pathvalue: /api/testtoken_bucket: # 每秒限流100qpsfill_interval: 1smax_tokens: 100tokens_per_fill: 100filter_enabled:default_value:denominator: HUNDREDnumerator: 100runtime_key: local_rate_limit_enabledfilter_enforced:default_value:denominator: HUNDREDnumerator: 100runtime_key: local_rate_limit_enforcedstat_prefix: http_local_rate_limitertoken_bucket:fill_interval: 1smax_tokens: 100000tokens_per_fill: 100000workloadSelector:labels:instance: instanceA结果请求成功率不能稳定在50% 结论使用descriptors精细化限流针对指定请求路径限流不准❎
2使用descriptors精细化限流时限流不准问题分析 根因descriptors精细化限流实现时使用的全局计时器具有一定的不确定性/-O(10ms)所以在再填充时间N和N1处记录的时钟时间很可能小于间隔本身。比如每秒限流100qps实际令牌桶填充令牌的时间间隔不能稳定在1s
Github地址https://github.com/envoyproxy/envoy/pull/21327
解决方案该问题官方已修复Istio 1.18.2版本已包含该commit基于Istio 1.18.2版本验证descriptors精细化限流限流功能正常可升级至Istio 1.18.2以上版本
推荐阅读
各公司Istio落地实践
百度大规模Service Mesh落地实践
istio 在知乎大规模集群的落地实践
携程Service Mesh性能优化实践
网易数帆的 Istio 推送性能优化经验
多点生活在 Service Mesh 上的实践
Istio Pilot源码
Istio Pilot源码学习一Pilot-Discovery启动流程、ConfigController配置规则发现
Istio Pilot源码学习二ServiceController服务发现
Istio Pilot源码学习三xDS的异步分发
