linkerd怎样服务网格

本文目录导读：

1. 核心工作原理：数据平面与控制平面
2. Linkerd 如何实现关键功能？
3. 与 Istio 的主要区别
4. 总结：Linkerd 适合谁？

Linkerd 是一个轻量级、高性能的服务网格（Service Mesh）实现，它的核心目标是解决微服务架构中的通信问题，比如可观测性、安全性和可靠性，它的设计哲学是“Keep it simple”（保持简单），相比于 Istio 等其它服务网格，Linkerd 的部署、管理和资源占用都更轻量。

Linkerd 通过在每个微服务旁边部署一个透明的“代理”（sidecar 代理）来工作，所有服务之间的流量都会被这个代理拦截，从而在不修改应用代码的情况下，实现各种高级功能。

下面从几个方面详细解释 Linkerd 是如何实现服务网格的：

核心工作原理：数据平面与控制平面

Linkerd 架构分为两大部分：

1. 数据平面：

   • 本质上是每个 Pod 中运行的一个轻量级代理（通常是 linkerd-proxy，基于 Rust 语言编写，性能和安全性很高）。
   • 这个代理接管所有进出该 Pod 的网络流量，它不会修改你的应用代码，但它是一个透明的中间人。
   • 关键功能：
     • HTTP/2 和 gRPC 代理：自动将流量升级到更高效的 HTTP/2 或 gRPC 协议。
     • mTLS：自动为服务间通信启用双向TLS加密，保证通信安全。
     • 负载均衡：基于延迟、成功率等动态指标进行智能负载均衡。
     • 熔断、重试、超时：增强服务调用的可靠性。
     • 指标收集：收集请求延迟、成功率、流量量等关键指标。

2. 控制平面：

   • 一组独立的微服务,负责管理和配置整个网格。
   • 核心组件：
     • destination：服务发现和路由决策的中心，它告诉代理应该把请求发送到哪里。
     • identity：证书颁发机构（CA），负责管理 mTLS 所需的证书和密钥。
     • proxy-injector：自动将 Linkerd 代理注入到新的 Pod 中（通过准入控制器）。
     • tap：允许查看实时请求和响应流，用于调试。
     • web：提供基于浏览器的 Dashboard。
     • controller：控制平面的大脑，协调各个组件。

Linkerd 如何实现关键功能？

1. 服务发现与路由：

   • Linkerd 不使用 Kubernetes 原生的 kube-proxy（这是它和很多其他服务网格的关键区别），它通过自己高性能的 destination 服务（基于 gRPC）直接与 Kubernetes API Server 通信，获取服务端点信息。
   • 当一个服务（Service A）想要调用另一个服务（Service B）时：
     1. Service A 的 Linkerd 代理拦截了这个请求（目标可能是 http://service-b:8080）。
     2. 代理向控制平面的 destination 服务询问 service-b 的当前所有健康端点 (Pod IP)。
     3. destination 服务返回一个动态更新的端点列表（考虑了负载均衡权重、健康检查、端点失败等）。
     4. 代理根据负载均衡算法（如EWMA，指数加权移动平均）选择一个最佳端点，然后建立连接并转发请求。

2. 安全性（mTLS）：

   • 这是 Linkerd 的核心卖点之一。
   • 它默认启用端到端的双向 TLS（mTLS）。
   • 工作原理：
     1. 控制平面的 identity 组件充当 CA，为每个 Pod 或工作负载签发短期证书。
     2. 当服务 A 的代理连接到服务 B 的代理时，它们会进行 TLS 握手。
     3. 双方验证彼此的身份（证明自己是合法的服务 A 和服务 B），这确保了流量只能在被授权和受信任的服务之间流动，阻止了中间人攻击和未经授权的访问。
     4. 所有通信在此过程中自动加密,无需修改应用代码或管理证书。

3. 可靠性（熔断、重试、超时）：

   • 这些功能直接在 Linkerd 代理中实现，非常高效。
   • 重试：代理可以自动重试失败的请求（网络闪断或服务临时不可用），Linkerd 会检测“幂等”请求（即重试不会造成副作用的请求，如GET请求）并安全地重试。
   • 熔断：如果目标服务持续失败（响应时间过长或出现5xx错误），Linkerd 会主动切断到该服务的连接，避免“雪崩效应”，它通过监控后端服务的“失败率”来决定何时断开连接、何时尝试重新连接。
   • 超时：可以为请求设置超时时间，如果某个处理超出了这个时间，代理会主动关闭连接，避免请求无限期挂起。

4. 可观测性：

   • Linkerd 默认生成非常丰富的黄金指标（RED指标：Rate, Errors, Duration）。
   • 它会自动收集所有服务间通信的以下数据：
     • 请求速率 (RPS)：每秒请求数。
     • 错误率：5xx 错误率。
     • 延迟分布 (P50, P95, P99)：请求处理时间的百分位数。
   • 这些数据通过 linkerd viz 插件（一个可选组件）聚合，并提供：
     • Web Dashboard：一个漂亮的界面，显示服务拓扑、每个服务的健康状态、延迟等。
     • Prometheus & Grafana：数据可以导出到标准的可观测性栈中。
     • linkerd tap：允许实时查看（抓包）流经网格的请求和响应，这对调试非常有用。

5. 故障注入与流量拆分：

   • 虽然不如 Istio 的 VirtualService 功能丰富，但 Linkerd 提供了流量拆分功能，用于金丝雀发布和 A/B 测试。
   • 你可以将一部分流量（10%）指向服务的一个新版本，观察其行为，而无需直接修改路由规则，这通过 ServiceProfile 资源和 TrafficSplit CRD（自定义资源定义）实现。

与 Istio 的主要区别

Linkerd 适合谁？

• 微服务数量中等（几十到几百个），但希望快速获得服务网格的核心价值（可观测性、安全、可靠性）的团队。
• 对性能敏感、资源预算有限的团队（每个 Pod 额外消耗的资源极少）。
• 希望零配置或极简配置就能开启安全的 mTLS 的团队。
• 团队规模不大，希望服务网格简单易用、运维成本低的团队。

不适合的场景：

• 需要非常复杂、细粒度的流量管理（如基于 URI、Header、Cookie 的路由，复杂的故障注入）。
• 需要多集群、多网络环境的强一致性策略管理。
• 对Envoy 生态有深度依赖的团队。

Linkerd 通过在 Pod 中部署一个 极轻量、基于 Rust 的代理，透明地拦截所有服务间流量，自动实现 mTLS 加密、动态负载均衡、指标监控、自动重试和熔断，并且这一切几乎不需要修改你的应用代码，它的核心理念是：简单、快速、安全。

标签： linkerd 服务网格