Linkerd 是专为 Kubernetes 设计的轻量级服务网格，它的控制平面组件少、资源开销低，数据平面采用 Rust 编写的 linkerd2-proxy 作为边车代理。与 Istio 相比，Linkerd 的部署流程更简洁，不依赖复杂的 CRD 体系，但依然具备 mTLS 加密、可观测性指标、流量拆分和重试等能力。本文从实际集群出发，演示如何通过 linkerd CLI 完成控制平面安装、业务 Pod 注入、指标查看以及卸载清理。
一、部署前准备：安装CLI并检查集群兼容性
Linkerd 官方推荐使用 linkerd CLI 作为主要安装工具，CLI 的版本需要与集群端控制平面版本匹配。首先应确认 kubectl 可以正常访问目标集群，然后在本地安装对应的 CLI 二进制文件。Linux 或 macOS 用户可以通过官方脚本安装，Windows 用户则直接下载可执行文件并放入 PATH 目录。
安装完成后，执行 linkerd version 可以查看客户端版本。如果此时尚未部署控制平面，输出中的 Server version 会显示不可用，这属于正常现象。随后需要运行 linkerd check --pre 进行部署前预检。预检会扫描 Kubernetes API 版本、RBAC 权限、节点资源、Webhook 端口等关键项，任何失败都必须在安装前解决。
# 查看 Kubernetes 版本，Linkerd 2.14 要求 Kubernetes 1.21+ kubectl version --short # 安装 linkerd CLI（以 Linux 为例） curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh export PATH=$PATH:$HOME/.linkerd2/bin linkerd version
常见预检错误包括集群版本过低、当前用户权限不足以及节点资源紧张。对于测试集群，可以使用最小资源规格；对于生产集群，建议提前预留至少 2 个 CPU 核心和 4GB 内存给控制平面，并为边车代理预留一定余量。
二、安装控制平面：证书、清单与高可用配置
Linkerd 控制平面由多个组件组成，其中 identity 服务负责为代理签发短期证书。CLI 在安装时会自动生成一组自签名证书作为信任锚，适合测试或开发环境。生产环境建议替换为 cert-manager 或企业 CA 签发的证书，这样可以避免自签名证书带来的信任链管理问题。
生成部署清单可以直接执行 linkerd install。该命令会输出完整的 Kubernetes YAML，可以重定向到文件进行审查后再应用，也可以直接通过管道交给 kubectl。如果需要控制平面具备高可用能力，可以追加 --ha 参数，这样会增加控制器副本数并配置 Pod 反亲和性。
linkerd install | kubectl apply -f - linkerd check
安装过程中，Webhook 可能因为网络或镜像拉取失败而无法启动。需要重点关注 linkerd-proxy-injector 和 linkerd-identity 这两个 Deployment 的状态。默认镜像从 cr.l5d.io 拉取，如果集群无法访问该仓库，可以配置镜像仓库镜像或采用离线安装方式。
kubectl -n linkerd get pods kubectl -n linkerd describe pod -l linkerd.io/control-plane-ns=linkerd linkerd check
如果 linkerd check 全部通过，说明控制平面已经健康运行。此时可以查看 linkerd 命名空间下的 Service，确认 linkerd-dst、linkerd-identity、linkerd-policy 等核心服务均处于正常状态。证书默认有效期为 365 天，在线状态下 CLI 会自动完成轮换，但需要保证控制平面始终可用。
三、注入数据平面：为业务工作负载启用Linkerd代理
控制平面安装完成后，业务 Pod 还需要注入 linkerd2-proxy 边车，流量才会经过代理并产生指标。注入方式有两种：命名空间注解自动注入和 linkerd inject 手动注入。推荐生产环境使用命名空间注解，因为它对 Deployment 无侵入，后续新增工作负载会自动完成注入。
kubectl annotate namespace default linkerd.io/inject=enabled kubectl rollout restart deployment your-app -n default
手动注入适用于临时测试或不想修改命名空间注解的场景。例如对已有的 Deployment 清单执行 linkerd inject -f app.yaml | kubectl apply -f -。注入完成后，Pod 会多出一个名为 linkerd-proxy 的容器，业务容器本身不会被修改。需要注意的是，运行中的 Pod 不会自动注入，必须通过滚动重启来触发。
注入成功后，可以使用 linkerd stat 查看流量统计。该命令从代理上报的指标中聚合请求成功率、RPS、延迟等数据，是验证服务网格是否生效的最快方式。
linkerd stat deploy -n default linkerd stat po -n default
输出中的 MESHED 列如果显示为 1/1 或 2/2，说明所有 Pod 都已被代理接管。如果看到 0/1，说明部分 Pod 未注入，通常是因为没有重启或命名空间注解未同步。为了更直观地观察网格状态，可以安装 viz 扩展，它提供 Web Dashboard 和 Grafana 图表。
linkerd viz install | kubectl apply -f - linkerd viz check linkerd viz dashboard
dashboard 命令会启动本地代理并通过浏览器打开控制台。生产环境需要配合 Ingress 或端口转发进行访问，不建议直接暴露公网。
四、常见问题排查与卸载清理
部署中第一个常见问题是 Pod 一直处于 Pending 或 CrashLoopBackOff。这通常是因为 sidecar 镜像拉取失败。可以查看 Pod 事件或 describe 输出，确认镜像名称是否来自 cr.l5d.io。如果集群无法访问该仓库，需要在安装时通过 --registry 参数指定镜像仓库，或者提前配置 registry mirror。
第二个常见问题是服务间调用出现 connection refused 或超时。可能是目标服务未被注入，也可能是端口协议不匹配。Linkerd 默认对 TCP 流量透明代理，但对于数据库等非标准协议端口，可以使用 ConfigMap 跳过代理，避免边车干扰数据库连接。
apiVersion: v1
kind: ConfigMap
metadata:
name: linkerd-config
namespace: linkerd
data:
values: |
proxy:
ignoreInboundPorts: "3306,6379"
ignoreOutboundPorts: "3306,6379"
卸载 Linkerd 时，必须先移除数据平面，再删除控制平面，否则会出现残留代理与 Webhook 冲突的问题。正确步骤是先给命名空间移除注入注解并重启业务负载，然后删除控制平面资源。
kubectl annotate namespace default linkerd.io/inject=disabled --overwrite kubectl rollout restart deployment your-app -n default linkerd install --ignore-cluster > /tmp/linkerd.yaml kubectl delete -f /tmp/linkerd.yaml kubectl delete namespace linkerd
完成上述操作后，集群会恢复到未安装服务网格的状态。生产环境还应额外关注证书替换、高可用控制平面以及边车资源限制。Linkerd 的 Rust 代理通常比 Envoy 更轻量，但在高吞吐场景下仍建议设置合理的 CPU 和内存 requests 与 limits。通过本文步骤，可以从空集群快速搭建起一个具备 mTLS 加密和可观测性能力的 Linkerd 服务网格。
Linkerd服务网格Kubernetes修改时间：2026-08-29 08:48:20