Linkerd 社区宣布发布 Linkerd 2.20，带来一系列性能、可观测性和流量管理方面的增强，进一步巩固了这款 CNCF 毕业项目在 Kubernetes 网络领域作为轻量级服务网格的定位。本次发布新增了感知限流的负载均衡（Rate-Limit-Aware Load Balancing），大幅降低控制平面的内存占用，改进入站流量指标，并继续坚持在保持企业级可靠性和安全性的同时，尽可能降低运维复杂度。
本次发布最引人关注的改进之一是重新设计了控制平面。在 Pod 大量频繁创建和销毁的场景下，控制平面的内存占用最高可降低 85%，使运维团队能够在资源受限的 Kubernetes 集群以及大规模生产环境中更加高效地运行 Linkerd。结合更加智能的流量路由和增强的可观测性能力，这一版本延续了 Linkerd 一贯的设计思路：优先解决生产环境中的实际运维问题，而不是不断增加功能复杂度。
Linkerd 2.20 最重要的新特性是感知限流的负载均衡。传统服务网格主要依据请求延迟和后端实例的可用性进行流量分发，而越来越多的现代 API 会通过 HTTP 限流响应（Rate Limit Response）来通知客户端服务已达到处理上限，而不是直接返回失败。
Linkerd 现在能够识别这些限流信号，并自动调整流量路由策略，将请求暂时绕开正在主动限流的服务实例。相比持续向已经过载的实例发送请求，代理会优先将流量调度到状态更健康的实例，在维持整体吞吐量的同时，降低分布式系统中级联故障发生的风险。这一能力尤其适用于大量依赖第三方 API，或需要与采用动态限流机制服务交互的微服务架构。
性能优化仍然是此次发布的重要主题。Linkerd 维护团队对 destination controller 进行了大幅优化，使其在 Kubernetes 调度频繁变化期间的内存占用显著下降。项目表示，这项改进能够让运维团队将更多集群资源用于运行应用，而不是消耗在基础设施组件上。
轻量级一直是 Linkerd 与其他服务网格的重要区别，这些优化进一步强化了这一设计理念。
Linkerd 由 Buoyant 使用 Rust 开发，在设计之初便以尽可能降低运维开销为目标。它持续致力于提供双向 TLS（mTLS）、流量管理和可观测性等核心服务网格能力，同时避免大型服务网格部署通常伴随的高资源消耗。
2.20 版本还增强了入站请求指标，让平台团队能够更准确地了解服务接收和处理流量的情况。
更加完善的遥测数据有助于运维人员发现流量瓶颈、排查延迟问题，并在故障发生时更好地理解服务运行状态。
这些改进也是 Linkerd 持续投入可观测性建设的一部分，与此前对 OpenTelemetry 的集成形成互补，同时进一步体现了云原生平台朝着标准化遥测体系发展的趋势。随着 Kubernetes 环境越来越动态，可观测性带来的运行洞察能力，已经变得与流量管理能力同样重要。
Linkerd 2.20 并没有引入大规模的架构调整，而是在项目长期坚持的设计理念基础上持续演进：提供服务网格所需的核心能力，同时尽可能降低运维复杂度。
此次发布正值服务网格生态持续演进之际。以 Istio 为代表的平台不断扩展自身能力，逐步发展成为覆盖流量管理、安全策略和网络功能的综合平台；相比之下，Linkerd 始终坚持另一条路线，更加注重简单易用、运维效率以及部署门槛。
与此同时，Kubernetes Gateway API 和基于 eBPF 的网络技术等新方案，也正在改变企业构建服务间网络通信的方式。这些变化促使服务网格更加关注实际运维价值，而不是单纯追求功能数量。
Linkerd 2.20 也体现了云原生网络的发展趋势。服务网格发展的早期阶段，创新主要集中在流量路由、重试、熔断以及双向 TLS 等能力。而如今，这些功能已经逐渐成为现代 Kubernetes 平台的基础能力。
原文链接：Linkerd 2.20 Delivers Smarter Traffic Management and Dramatic Efficiency Gains
