架构

从较高的层次上看,Linkerd 由一个 控制平面(control plane) 和一个 数据平面(data plane) 组成。

控制平面是一组服务,提供对 Linkerd 整体的控制。

数据平面由在每个服务实例“旁边”运行的透明微代理(micro-proxies)组成,作为 Pod 中的 sidecar。 这些代理会自动处理进出服务的所有 TCP 流量,并与控制平面进行通信以进行配置。

Linkerd 还提供了一个 CLI,可用于与控制平面数据平面进行交互。

Linkerd's architecture
Linkerd’s architecture

CLI

Linkerd CLI 通常在集群外部运行(例如在您的本地机器上),用于与 Linkerd 交互。

控制平面(control plane)

Linkerd 控制平面是一组在专用 Kubernetes 命名空间(默认为 linkerd)中运行的服务。 控制平面有几个组件,列举如下。

目标服务(destination)

数据平面代理使用 destination 服务来确定其行为的各个方面。 它用于获取服务发现信息(即发送特定请求的位置和另一端预期的 TLS 身份); 获取有关允许哪些类型的请求的策略信息; 获取用于通知每条路由指标重试超时的服务配置文件信息;和更多其它有用信息。

身份服务(identity)

identity 服务充当 TLS 证书颁发机构, 接受来自代理的 CSR 并返回签名证书。 这些证书在代理初始化时颁发,用于代理到代理连接以实现 mTLS

代理注入器(proxy injector)

proxy injector 是一个 Kubernetes admission controller,它在每次创建 pod 时接收一个 webhook 请求。 此 injector 检查特定于 Linkerdannotationlinkerd.io/inject: enabled)的资源。 当该 annotation 存在时,injector 会改变 pod 的规范, 并将 proxy-initlinkerd-proxy 容器以及相关的启动时间配置添加到 pod 中。

数据平面(data plane)

Linkerd 数据平面包含超轻型微代理,这些微代理部署为应用程序 Pod 内的 sidecar 容器。 由于由 linkerd-init(或者,由 LinkerdCNI 插件)制定的 iptables 规则, 这些代理透明地拦截进出每个 podTCP 连接。

代理(Linkerd2-proxy)

Linkerd2-proxy 是一个用 Rust 编写的超轻、透明的微代理Linkerd2-proxy 专为 service mesh 用例而设计,并非设计为通用代理。

代理的功能包括:

  • HTTPHTTP/2 和任意 TCP 协议的透明、零配置代理。
  • HTTPTCP 流量的自动 Prometheus 指标导出。
  • 透明、零配置的 WebSocket 代理。
  • 自动、延迟感知、第 7 层负载平衡。
  • HTTP 流量的自动第 4 层负载平衡。
  • 自动 TLS
  • 按需诊断 Tap API
  • 还有更多。

代理支持通过 DNS目标 gRPC API 进行服务发现。

您可以在此处阅读有关这些微代理的更多信息:

Linkerd init 容器

linkerd-init 容器作为 Kubernetes init 容器 添加到每个网格 pod 中,该容器在任何其他容器启动之前运行。 它使用iptables 通过代理将所有 TCP 流量,路由到 Pod 和从 Pod 发出。