华为云-张伟-华为云服务网格数据面演进与实践

华为云服务网格数据面演进与实践 讲师简介 “《Istio权威指南》第二版核心作者。18年开发经验，先后就职于亿阳信通、北电、甲骨文、Polycom、阿里巴巴及华为等公司，作为核心开发人员开发过传输网管系统、Tuxedo交易中间件、ts-server多媒体转码服务、GTS（seata）高性能事务云服务、SC高性能注册中心、ASM数据面等多个产品，有丰富的架构设计及开发经验，现主要负责华为云ASM服务网格数据面代理产品的方案设计及开发工作。 张伟 ASM服务网格架构师 目录 •网格数据面运维增强功能介绍•ASM网格数据面的演进路线 Istio+ Kubernetes：云原生应用治理+云原生应用设施 核心理念： 1.非侵入式Sidecar注入技术，将数据面组件注入到应用所在的容器，通过劫持应用流量来进行功能实现，应用无感知。2.北向API基于K8s CRD实现，完全声明式，标准化。3.数据面与控制面通过xDSgRPC标准化协议通信，支持订阅模式。 核心特性： 1.服务&流量治理：熔断，故障注入，丰富的负载均衡算法，限流，健康检查，灰度发布，蓝绿部署等2.流量与访问可视化：提供应用级别的监控，分布式调用链，访问日志等3.安全连接：通过mTLS、认证、鉴权等安全措施帮助企业在零信任的网络中运行应用 华为云ASM，全托管的应用服务网格基础设施 •覆盖全应用形态，支持容器、虚机、边缘、传统微服务、第三方服务等多种应用平滑接入、统一治理。支持多云、混合云复杂场景多种网络条件下服务跨集群流量混合管理；大规模网格；提供智能运维、智能扩缩容，帮助用户自动透明的管理应用访问 •高性能、低损耗、轻量、多形态网格数据面，支持每POD、每Node形态，加快Sidecar转发效率，优化网格控制面资源。 亮点介绍 •ASM产品在运维能力上针对现有Envoy进行了增强，可以对一些普遍由于引入代理的时延增加类问题快速定位。 •ASM产品的发展路线从Sidecar和节点模式NodeProxy逐渐演进到下一代L4/L7分离式架构。这一演进旨在提升用户资源利用率的同时，实现更快的L4层快速路径数据治理以及更具弹性的L7层远程处理能力。 案例背景：常见的时延问题 问题基本描述： 1.多个客户线程同时访问Envoy，TCP分片或应用发送消息分片使得同一个应用消息处理时间拉长，而且不一定可以稳定重现。 2.客户端处理响应较慢，导致Envoy上游读服务端响应水位被关闭，造成整体请求处理时间较长。 3. Envoy内用户自定义插件编写不当，导致请求整体处理时间较长。 案例背景 1.客户线上服务支持用户使用HTTP请求上传文档，文档本身10k左右，有时延达到秒级。通过EnvoyAccessLog只能看出Envoy内时延较高，但不知道在哪个阶段引起。 2.此为线上偶现问题，再尝试上传相同文档则在几十毫秒内完成传输。3.从OS层面观察内核数据发送无延迟，HTTP数据量本身不大，不应在不同调用时呈现较大的时延差异。4.测试环境下无法稳定重现，此问题定位最终耗时几周。5.最后判断由于Istio ingressgateway网关处理较大并发时，用户消息被分片处理，且Envoy事件处理不及时导致完整HTTP完成处理较慢。 问题与挑战 •线上问题、测试环境无法稳定重现、即使重现在Envoy现有日志也没法直接判断。 破题思路 1.时延类问题需要在请求整个梳理路径中，对L4数据收发、插件执行、连接池观察等多个方面进行综合分析。2.可以结合tcpdump抓包查看客户端到Envoy、Envoy之间、Envoy到目标服务之间包时间戳的差异（需要NTP校准各个部分的系统时间）。3.需要将更详细的观测状态记录到AccessLog中，作为日常观测手段，可以快速对不同时延类问题进行判断。 解决问题思路：简要但不简单；经验->能力 打通Envoy请求处理链路中L4~L7自身运行状态观察能力 1.增强Envoy的请求级别信息，提供更详细的信息，包括： •调用操作系统读写操作的耗时•是否使用安全连接•处理连接的线程ID及连接ID•是否出现HTTP消息分片•是否出现由于连接内缓存限制导致的流控•插件框架执行时间•上游连接池在HTTP协议中是否被重用•处理HTTP响应时收到的HTTP头部和数据部分是否存在较大时间间隔等信息 2.日志增强增强信息可以帮助快速定位时延问题，例如系统调用阻塞、消息分片、Envoy自身插件处理时间过长、到达缓存水位暂停接收等。 3.日志增强功能不会影响现有的Envoy内的请求级别服务维度日志，而是作为日常运维手段的补充。4.可以提供更全面的请求级别信息，帮助运维人员更好地分析和调优系统性能，快速定位潜在的性能瓶颈和延迟问题。 成果展示1 判断HTTP大小，以及Envoy L4接收及发送的数据量和Envoy处理中自身增加的HTTP头部大小： 只有HTTP Header部分的下游请求日志： 1.上面例子DOWNSTREAM_READ_DURATION部分[C56:R:<21:36.106>0,0,96]H中： •<21:36.106>0表示OS接收开始的时间戳，以及接收用时ms，如果耗时较长需要考虑调整内核参数提升网络接收性能。•96表示本次接收到的数据字节数•H表示本地接收到的数据经过HTTP解码器作为HTTP头部进行解码。•Envoy内HTTP添加部分：1271-96 = 1175字节 2.如果观察到日志中只有头部而没有数据部分，并且整个接收字节数较大，那么可以推断存在较大的HTTP头部。在这种情况下，可能会触发一些HTTP服务器处理框架中的HTTP头部长度校验限制。管理员可以将这个问题反馈给开发，建议他们将某些头部参数移动到数据部分。通过将一部分头部参数放入数据部分，可以减少整体头部的长度，从而避免触发服务器处理框架的限制。 成果展示2 判断Envoy工作线程数量及各个线程处理新连接情况是否均衡： Envoy启动参数：concurrency参数启动4个工作线程 单行日志： 使用命令：awk‘{print $29}’4.log | sort | uniq-c统计每个线程处理请求的数量了解各个线程处理连接是否均衡： 1.在Istio 1.8版本之前，存在在多线程环境下，outbound方向的Envoy可能出现每个线程处理连接数差异较大的情况的问题，这可能导致端到端处理的平均时延不均衡。 2.运维人员可判断是否需要启用连接均衡选项来提升吞吐。从而在多线程环境下更均衡地分配连接，提高系统性能并改善响应时间。 成果展示3 判断是否单个消息太大导致TCP分片，或HTTP响应头和数据部分之间产生延迟： a.由于HTTP请求及响应消息较大，导致出现同一个HTTP消息出现分片： b. HTTP响应头部与数据部分存在延时19ms： 上面例子中： 1.Envoy的处理过程中，HTTP头部和数据部分为独立回调，并且每个回调在完成后会单独发送到L4连接的发送缓冲区中，当多个客户端频繁发送请求时，可能会导致HTTP消息的头部和数据部分被分别发送，增加某HTTP消息时延。 2.通过分析分片日志，可以观察到同一个HTTP消息的每个分片的接收时间，以及在服务器端发送响应时是否分开发送HTTP头部和数据部分，增加了客户端的端到端处理时延。 3.对于这种情况，可以考虑以下优化措施： •减小请求端单个HTTP请求的发送的数据量大小。 •优化服务器端的处理逻辑，以减少处理时间，确保HTTP头部和数据部分能够尽快被一起发送给客户端。 成果展示4 判断Envoy之间是否启动了TLS，以及是否执行了连接复用 1.在线上配置过程中，如网格默认没有启用mTLS，导致新增的服务没有配置mTLS，从而导致明文传输，增加了安全风险。可以通过监控Envoy日志来发现此类情况。 2.在下面的日志中（例如2023-11-28T01:43:00.757Z），可以找到以下信息： •DOWNSTREAM_READ_DURATION中：[C676:R:<43:00.757>0,0,1167]H,D,E，表示客户端发起的请求是明文内容，其中的R表示明文请求。 •UPSTREAM_WRITE_DURATION中：[C677~C677:S:0,<43:00.759>0.2336]d中，C677~C677表示上游连接池在收到客户请求后新创建了一个C677连接，并且实际使用的也是C677连接。S表示该连接使用了TLS。 •另外在Istio 1.8版本之前，存在一个问题，即创建的上游连接并不一定是实际请求所使用的连接。这可能导致消息接收端的错乱。您也可以通过上面提到的日志信息中连接ID来判断。 3.在接下来的2023-11-28T01:43:09.310Z日志中： •UPSTREAM_WRITE_DURATION中：[C0~C677:S:0,<43:09.311>0,2336]d中，表示此时没有创建新的上游连接，而是重用了已有的C677连接。可以判断在某段时间内有多少活跃的上游连接被重用。根据重用情况，可以决定是否需要调整连接池连接参数，扩大或缩减连接池内的活动连接容量。这样可以优化连接池的性能和资源利用情况。 成果展示5 判断是否由于连接缓冲区水位大小导致接收关闭： a.上游接收响应触发连接流控日志： b.上游接收响应水位恢复后日志： 1.Envoy每个连接都可以配置缓存的水位大小。默认情况下，低水位线为512K，高水位线1M。当前连接内的请求未完成处理时，如果新的请求数据量超过了缓存水位，将会触发水位关闭。一旦待处理的数据发送完毕，水位将恢复。 2.下游连接和上游连接是独立的连接，它们分别具有各自的缓存配置。这意味着在处理下游请求时使用的缓存配置可能与处理上游请求时使用的缓存配置不同3.从上面的例子中可以看出：•（42）线程上游连接日志UPSTREAM_READ_DURATION显示在<18:00.647>0,0,11137]H,D,E!1时接收服务端响应时，由于上游发送处理较慢无法发送到后端服务时，触发水位关闭，连续关闭次数为1。•在（42）线程的下一个请求处理中，上游连接日志UPSTREAM_READ_DURATION显示C[114~C44:S:0,<18:00.680>0,11345]d”“[C44:S:<18:00.743>0,0,11133]H+5<18:00.679>,D,E!1时，在经过5ms（对应前一条日志关闭时间<18:00.647>)后水位在<18:00.679>重新开放，因此上游发送可以在<18:00.680>时继续发送数据。此时可以判断出是由于Envoy上游连接水位被限制导致服务端接收数据变慢。管理员可以配置下游监听器或上游Cluster的perConnectionBufferLimitBytes参数控制连接水位。•根因推测为下游写response较慢导致上游的读出现了水位限制. 成果展示6 判断Envoy插件执行时间： 用例：增加根据头部x-delay参数进行延时的lua插件： 访问日志： 使用命令： curl-v -Hx-delay:9http://http-server-service.default:9000访问服务 根据以上日志： 1.下游接收DOWNSTREAM_READ_DURATION时间点<53:08.802>到上游发送UPSTREAM_WRITE_DURATION时间点<53:17.806>之间有9s的时间差，排除Envoy基本处理流程耗时外，相差较大的时间可以猜测为耗时的HTTP插件引入。2.接下来帮助管理员排查是否由于lua或耗时的用户自定义插件引入时延问题。 非时延类问题 有万分之一的概率，在WAF上看到502报错： 分析方法： 1.在WAF及ingressgateway侧分别抓包，发现都有FIN报文，Envoy主动关闭连接。 结论：