问题提出
流量有损是在应用发布时的常见问题，其现象通常会反馈到流量监控上，如下图所示，发布过程中服务RT突然升高，造成部分业务响应变慢，给用户的最直观体验就是卡顿；或是请求的500错误数突增，在用户侧可能感受到服务降级或服务不可用，从而影响用户体验。
因为应用发布会伴随流量有损，所以我们往往需要将发布计划移到业务低谷期，并严格限制应用发布的持续时间，尽管如此，还是不能完全避免发布带来的风险，有时甚至不得不选择停机发布。EDAS作为一个通用应用管理系统，应用发布是其最基本的功能之一，而K8s 应用是EDAS中最普遍的应用的形态，下文将通过对EDAS客户真实场景的归纳，从K8s的流量路径入手，分析有损发布产生的原因，并提供实用的解决方案。
流量路径分析
K8s中，流量通常可以从以下几种路径进入到应用Pod中，每条路径大相径庭，流量损失的原因各不相同。我们将分情况探究每种路径的路由机制，以及Pod变更对流量路径的影响。
LB Service流量
通过LoadBalancer类型Service访问应用时，流量路径中核心组件是LoadBalancer和ipvs/iptables。LoadBalancer负责接收K8s集群外部流量并转发到Node节点上，ipvs/iptables负责将节点接收到的流量转发到Pod中。核心组件的动作由CCM（cloud-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环境下的就绪探针和存活探针配置：
1 | readinessProbe: |
微服务流量场景
对于微服务应用，服务的注册和发现由注册中心管理，而注册中心并没有如K8s就绪探针的检查机制。并且由于JAVA应用通常启动较慢，服务注册成功后所需资源均仍然可能在初始化中，比如数据库连接池、线程池、JIT编译等。如果此时有大量微服务请求涌入，那么很可能造成请求RT过高或超时等异常。
针对上述问题，Dubbo提供了延迟注册、服务预热的解决方案，功能概述如下：
• 延迟注册功能允许用户指定一段时长，程序在启动后，会先完成设定的等待，再将服务发布到注册中心，在等待期间，程序有机会完成初始化，避免了服务请求的涌入。
• 服务预热功能允许用户设定预热时长，Provider在向注册中⼼注册服务时，将⾃身的预热时⻓、服务启动时间通过元数据的形式注册到注册中⼼中，Consumer在注册中⼼订阅相关服务实例列表，根据实例的预热时长，结合Provider启动时间计算调用权重，以控制刚启动实例分配更少的流量。通过小流量预热，能够让程序在较低负载的情况下完成类加载、JIT编译等操作，以支持预热结束后让新实例稳定均摊流量。
我们可以通过为程序增加如下配置来开启延迟注册和服务预热功能：
1 | dubbo: |
配置以上参数后，我们通过为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注解“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以达到上述效果，