了解 Linkerd Service Mesh 架构

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

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

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

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

系列

中文手册(https://hacker-linner.com)

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 进行服务发现。

• https://github.com/linkerd/linkerd2-proxy-api

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

• 为什么 Linkerd 不使用 Envoy
  • https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/
• Linkerd 最先进的 Rust 代理 Linkerd2-proxy
  • https://linkerd.io/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/

Linkerd init 容器

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

• https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

公众号：黑客下午茶