长沙制作网站的公司,平谷营销型网站建设,上海app网站建设,拼团小程序代理问题提出
流量有损是在应用发布时的常见问题#xff0c;其现象通常会反馈到流量监控上#xff0c;如下图所示#xff0c;发布过程中服务RT突然升高#xff0c;造成部分业务响应变慢#xff0c;给用户的最直观体验就是卡顿#xff1b;或是请求的500错误数突增#xff0c…问题提出
流量有损是在应用发布时的常见问题其现象通常会反馈到流量监控上如下图所示发布过程中服务RT突然升高造成部分业务响应变慢给用户的最直观体验就是卡顿或是请求的500错误数突增在用户侧可能感受到服务降级或服务不可用从而影响用户体验。 因为应用发布会伴随流量有损所以我们往往需要将发布计划移到业务低谷期并严格限制应用发布的持续时间尽管如此还是不能完全避免发布带来的风险有时甚至不得不选择停机发布。EDAS作为一个通用应用管理系统应用发布是其最基本的功能之一而K8s 应用是EDAS中最普遍的应用的形态下文将通过对EDAS客户真实场景的归纳从K8s的流量路径入手分析有损发布产生的原因并提供实用的解决方案。
流量路径分析
K8s中流量通常可以从以下几种路径进入到应用Pod中每条路径大相径庭流量损失的原因各不相同。我们将分情况探究每种路径的路由机制以及Pod变更对流量路径的影响。
LB Service流量 通过LoadBalancer类型Service访问应用时流量路径中核心组件是LoadBalancer和ipvs/iptables。LoadBalancer负责接收K8s集群外部流量并转发到Node节点上ipvs/iptables负责将节点接收到的流量转发到Pod中。核心组件的动作由CCMcloud-controller-manager和kube-proxy驱动分别负责更新LoadBalancer后端和ipvs/iptables规则。
在应用发布时就绪的Pod会被添加到Endpoint后端Terminating状态的Pod会从Endpoint中移除。kube-proxy组件会更新各节点的ipvs/iptables规则CCM组件监听到了Endpoint的变更后会调用云厂商API更新负载均衡器后端将Node IP和端口更新到后端列表中。流量进入后会根据负载均衡器配置的监听后端列表转发到对应的节点再由节点ipvs/iptables转发到实际Pod。
Service支持设置externalTrafficPolicy根据该参数的不同节点kube-proxy组件更新ipvs/iptables列表及CCM更新负载均衡器后端的行为会有所不同
Local模式CCM 仅会将目标服务所在节点添加入负载均衡后端地址列表。流量到达该节点后仅会转发到本节点的Pod中。Cluster模式CCM会将所有节点都添加到负载均衡后端地址列表。流量到达该节点后允许被转发到其他节点的Pod中。
Nginx Ingress流量 通过Nginx Ingress提供的SLB访问应用时流量路径核心组件为Ingress Controller它不但作为代理服务器负责将流量转发到后端服务的Pod中还负责根据Endpoint更新网关代理的路由规则。
在应用发布时Ingress Controller会监听Endpoint的变化并更新Ingress网关路由后端流量进入后会根据流量特征转发到匹配规则上游并根据上游后端列表选择一个后端将请求转发过去。
默认情况下Controller在监听到Service的Endpoint变更后会调用Nginx中的动态配置后端接口更新Nginx网关上游后端列表为服务Endpoint列表即Pod的IP和端口列表。因此流量进入Ingress Controller后会被直接转发到后端Pod IP和端口。
微服务流量 使用微服务方式访问应用时核心组件为注册中心。Provider启动后会将服务注册到注册中心Consumer会订阅注册中心中服务的地址列表。
在应用发布时Provider启动后会将Pod IP和端口注册到注册中心下线的Pod会从注册中心移除。服务端列表的变更会被消费者订阅并更新缓存的服务后端Pod IP和端口列表。流量进入后消费者会根据服务地址列表由客户端负载均衡转发到对应的Provider Pod中。
原因分析与通用解决方案
应用发布过程其实是新Pod上线和旧Pod下线的过程当流量路由规则的更新与应用Pod上下线配合出现问题时就会出现流量损失。我们可以将应用发布中造成的流量损失归类为上线有损和下线有损总的来看上线和下线有损的原因如下后文将分情况做更深入讨论
上线有损新Pod上线后过早被加入路由后端流量被过早路由到了未准备好的Pod。下线有损旧Pod下线后路由规则没有及时将后端移除流量仍路由到了停止中的Pod。
上线有损分析与对策
K8s中Pod上线流程如下图所示 如果在Pod上线时不对Pod中服务进行可用性检查这会使得Pod启动后过早被添加到Endpoint后端后被其他网关控制器添加到网关路由规则中那么流量被转发到该Pod后就会出现连接被拒绝的错误。因此健康检查尤为重要我们需要确保Pod启动完成再让其分摊线上流量避免流量损失。K8s为Pod提供了readinessProbe用于校验新Pod是否就绪设置合理的就绪探针对应用实际的启动状态进行检查进而能够控制其在Service后端Endpoint中上线的时机。
基于Endpoint流量场景
对于基于Endpoint控制流量路径的场景如LB Service流量和Nginx Ingress流量配置合适的就绪探针检查就能够保证服务健康检查通过后才将其添加到Endpoint后端分摊流量以避免流量损失。例如在Spring Boot 2.3.0以上版本中增加了健康检查接口/actuator/health/readiness和/actuator/health/liveness以支持配置应用部署在K8S环境下的就绪探针和存活探针配置 微服务流量场景
对于微服务应用服务的注册和发现由注册中心管理而注册中心并没有如K8s就绪探针的检查机制。并且由于JAVA应用通常启动较慢服务注册成功后所需资源均仍然可能在初始化中比如数据库连接池、线程池、JIT编译等。如果此时有大量微服务请求涌入那么很可能造成请求RT过高或超时等异常。
针对上述问题Dubbo提供了延迟注册、服务预热的解决方案功能概述如下
延迟注册功能允许用户指定一段时长程序在启动后会先完成设定的等待再将服务发布到注册中心在等待期间程序有机会完成初始化避免了服务请求的涌入。服务预热功能允许用户设定预热时长Provider在向注册中⼼注册服务时将⾃身的预热时⻓、服务启动时间通过元数据的形式注册到注册中⼼中Consumer在注册中⼼订阅相关服务实例列表根据实例的预热时长结合Provider启动时间计算调用权重以控制刚启动实例分配更少的流量。通过小流量预热能够让程序在较低负载的情况下完成类加载、JIT编译等操作以支持预热结束后让新实例稳定均摊流量。
我们可以通过为程序增加如下配置来开启延迟注册和服务预热功能 配置以上参数后我们通过为Provider应用扩容一个Pod来查看新Pod启动过程中的QPS曲线以验证流量预热效果。QPS数据如下图所示 根据Pod接收流量的QPS曲线可以看出在Pod启动后没有直接均摊线上的流量而是在设定的预热时长120秒内每秒处理的流量呈线性增长趋势并在120秒后趋于稳定符合流量预热的预期效果。
下线有损分析与对策
在K8s中Pod下线流程如下图所示 从图中我们可以看到Pod被删除后状态被endpoint-controller和kubelet订阅并分别执行移除Endpoint和删除Pod操作。而这两个组件的操作是同时进行的并非我们预期的按顺序先移除Endpoint后再删除Pod因此有可能会出现在Pod已经接收到了SIGTERM信号但仍然有流量进入的情况。
K8s在Pod下线流程中提供了preStop Hook机制可以让kubelet在发现Pod状态为Terminating时不立即向容器发送SIGTERM信号而允许其做一些停止前操作。对于上述问题的通用方案可以在preStop中设置sleep一段时间让SIGTERM延迟一段时间再发送到应用中可以避免在这段时间内流入的流量损失。此外也能允许已被Pod接收的流量继续处理完成。
上面介绍了在变更时由于Pod下线和Endpoint更新时机不符合预期顺序可能会导致的流量有损问题在应用接入了多种类型网关后流量路径的复杂度增加了在其他路由环节也会出现流量损失的可能。
LB Service流量场景
在使用LoadBalancer类型Service访问应用时配置Local模式的externalTrafficPolicy可以避免流量被二次转发并且能够保留请求包源IP地址。
应用发布过程中Pod下线并且已经从节点的ipvs列表中删除但是由CCM监听Endpoint变更并调用云厂商API更新负载均衡器后端的操作可能会存在延迟。如果新Pod被调度到了其他的节点且原节点不存在可用Pod时若负载均衡器路由规则没有及时更新那么负载均衡器仍然会将流量转发到原节点上而这条路径没有可用后端导致流量有损。 此时在Pod的preStop中配置sleep虽然能够让Pod在LoadBalancer后端更新前正常运行一段时间但却无法保证kube-proxy在CCM移除LoadBalancer后端前不删除节点中ipvs/iptables规则的。场景如上图所示在Pod下线过程中请求路径2已经删除而请求路径1还没有及时更新即使sleep能够让Pod继续提供一段时间服务但由于转发规则的不完整流量没有被转发到Pod就已经被丢弃了。
解决方案
设置externalTrafficPolicy为Cluster能够避免流量下线损失。因为Cluster模式下集群所有节点均被加入负载均衡器后端且节点中ipvs维护了集群所有可用Pod列表当本节点中不存在可用Pod时可以二次转发到其他节点上的Pod中但是会导致二次转发损耗并且无法保留源IP地址。设置Pod原地升级通过为Node打特定标签的方式设置新Pod仍然被调度到本节点上。那么该流程无需调用云厂商API进行负载均衡器后端更新流量进入后会转发到新Pod中。
Nginx Ingress流量场景
对于Nginx Ingress默认情况下流量是通过网关直接转发到后端PodIP而非Service的ClusterIP。在应用发布过程中Pod下线并由Ingress Controller监听Endpoint变更并更新到Nginx网关的操作存在延迟流量进入后仍然可能被转发到已下线的Pod此时就会出现流量损失。 解决方案
Ingress注解“http://nginx.ingress.kubernetes.io/service-upstream”支持配置为“true”或“false”默认为“false”。设置该注解为“true”时路由规则使用ClusterIP为Ingress上游服务地址设置为“false”时路由规则使用Pod IP为Ingress上游服务地址。由于Service的ClusterIP总是不变的当Pod上下线时无需考虑Nginx网关配置的变更不会出现上述流量下线有损问题。但需要注意的是当使用该特性时流量负载均衡均由K8s控制一些Ingress Controller特性将会失效如会话保持、重试策略等。在Pod的preStop设置sleep一段时间让Pod接收SIGTERM信号前等待一段时间允许接收并处理这段时间内的流量避免流量损失。
微服务流量场景
在Provider应用发布的过程中Pod下线并从注册中心注销但消费者订阅服务端列表变更存在一定的延迟此时流量进入Consumer后若Consumer仍没有刷新serverList仍然可能会访问到已下线的Pod。 对于微服务应用Pod的下线服务注册发现是通过注册中心而非不依赖于Endpoint上述endpoint-controller移除Endpoint并不能实现Pod IP从注册中心下线。仅仅在preStop中sleep仍然无法解决消费者serverList缓存刷新延迟问题。为了旧Pod能够优雅下线在preStop中需要首先从注册中心下线并能够处理已经接收的流量还需要保证下线前消费者已经将其客户端缓存的Provider实例列表刷新。下线实例可以通过调用注册中心接口或在程序中调用服务框架所提供的接口并设置到preStop以达到上述效果在EDAS中可以直接使用http://localhost:54199/offline 企业级一站式解决方案
上面我们对应用发布过程中三种常用流量路径的流量有损问题进行了原因分析并给出了解决方案。总的来说为了保证流量无损需要从网关参数和Pod生命周期探针和钩子来保证流量路径和Pod上下线的默契配合。EDAS在面对上述问题时提供了无侵入式的解决方案无需更改程序代码或参数配置在EDAS控制台即可实现应用无损上下线。如下图所示
LB Service支持配置外部流量策略externalTrafficPolicyNginx Ingress支持配置“http://nginx.ingress.kubernetes.io/service-upstream”注解微服务应用配置无损上线参数除此之外EDAS还提供了多种流量网关管理方式如Nginx Ingress、ALB Ingress、云原生网关也为应用的发布提供了多种部署方式如分批发布、金丝雀发布还提供了不同维度的可观测手段如Ingress监控、应用监控。在EDAS平台管理应用能够轻松实现多种部署场景下的无损上下线。
原文链接
本文为阿里云原创内容未经允许不得转载。
