架构
从较高的层次上看,Linkerd
由一个 控制平面(control plane) 和一个 数据平面(data plane) 组成。
控制平面是一组服务,提供对 Linkerd
整体的控制。
数据平面由在每个服务实例“旁边”
运行的透明微代理(micro-proxies)组成,作为 Pod
中的 sidecar
。
这些代理会自动处理进出服务的所有 TCP
流量,并与控制平面进行通信以进行配置。
Linkerd
还提供了一个 CLI,可用于与控制平面
和数据平面
进行交互。

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
检查特定于 Linkerd
的 annotation
(linkerd.io/inject: enabled
)的资源。
当该 annotation
存在时,injector
会改变 pod
的规范,
并将 proxy-init
和 linkerd-proxy
容器以及相关的启动时间配置添加到 pod
中。
数据平面(data plane)
Linkerd 数据平面
包含超轻型微代理
,这些微代理
部署为应用程序 Pod
内的 sidecar
容器。
由于由 linkerd-init(或者,由 Linkerd
的 CNI 插件)制定的 iptables
规则,
这些代理透明地拦截进出
每个 pod
的 TCP
连接。
代理(Linkerd2-proxy)
Linkerd2-proxy
是一个用 Rust 编写的超轻、透明的微代理
。
Linkerd2-proxy
专为 service mesh
用例而设计,并非设计为通用代理。
代理的功能包括:
HTTP
、HTTP/2
和任意TCP
协议的透明、零配置代理。HTTP
和TCP
流量的自动Prometheus
指标导出。- 透明、零配置的
WebSocket
代理。 - 自动、延迟感知、第
7
层负载平衡。 - 非
HTTP
流量的自动第4
层负载平衡。 - 自动
TLS
。 - 按需诊断
Tap API
。 - 还有更多。
代理支持通过 DNS
和目标 gRPC API 进行服务发现。
您可以在此处阅读有关这些微代理的更多信息:
Linkerd init 容器
linkerd-init
容器作为
Kubernetes init 容器
添加到每个网格 pod
中,该容器在任何其他容器启动之前运行。
它使用iptables 通过代理将所有 TCP
流量,路由到 Pod
和从 Pod
发出。