linkerd不能直接在裸机linux上运行，必须依托kubernetes环境；实际部署需先在linux主机搭建microk8s/k3s/kind等轻量集群，再安装linkerd控制平面与数据平面，且2.x版本官方完全不支持非kubernetes场景。
Linkerd 不能直接在裸机 Linux 上运行，它必须依托 Kubernetes 环境。所谓“Linux 部署 Linkerd”，本质是在 Linux 主机上先搭建一个轻量 Kubernetes 集群（如 MicroK8s、k3s 或 Kind），再在其上部署 Linkerd 控制平面与数据平面。Linkerd 2.x 官方已完全放弃对非 Kubernetes 场景的支持，Linkerd 1.x 虽可单机运行，但已停止维护且不推荐用于新项目。
准备兼容的 Kubernetes 环境
Linkerd 要求 Kubernetes 版本 ≥ 1.21，且需确保以下基础组件就绪：
- CoreDNS 或 NodeLocalDNS 正常运行（
kubectl get pods -n kube-system中状态为 Running） - RBAC 权限完整，特别是 service account 有足够权限绑定 ClusterRole
- 若用 MicroK8s，提前启用必要插件：
microk8s enable dns storage - 节点资源建议 ≥ 2 CPU / 2GB 内存；启用高可用（
--ha）会额外增加约 300MB 内存开销
安装 Linkerd 控制平面
linkerd install 命令只输出 YAML 清单，不会自动部署。常见误操作是执行后无反应，实则需手动应用：
- 标准部署：
linkerd install | kubectl apply -f - - 指定命名空间（避免资源错投）：
linkerd install -n linkerd | kubectl apply -f - - 生产环境启用高可用：
linkerd install --ha | kubectl apply -f -
部署后立即验证：linkerd check。若失败，90% 情况源于 DNS 解析异常（如无法访问 linkerd-identity.linkerd.svc.cluster.local）或 RBAC 权限缺失，而非 Linkerd 本身问题。
注入代理实现流量治理
服务网格能力依赖 Sidecar 代理注入。有两种方式，适用不同场景：
-
命名空间级自动注入：适用于新部署服务。先注解命名空间：
kubectl annotate namespace default linkerd.io/inject=enabled，再部署应用（Deployment 创建时触发注入） -
手动注入（推荐调试/灰度）：对已有 Deployment 注入更可控：
kubectl get deploy myapp -o yaml | linkerd inject - | kubectl apply -f - - 已有 Pod 补注入？必须重建：
kubectl rollout restart deployment -n default myapp
启用 mTLS 与基础策略控制
Linkerd 默认开启全链路 mTLS，无需额外配置即可加密东西向流量。安全治理的关键在于基于身份的访问控制：
- 确认 mTLS 状态：
linkerd viz authz查看服务间授权关系 - 限制服务调用权限：通过
ServerAuthorization资源定义谁可以访问谁。例如只允许frontend访问api：
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
name: api-access
namespace: default
spec:
server:
name: api-server
clients:
- meshTLS:
identities:
- "frontend@default.serviceaccount.identity.linkerd.cluster.local"该策略生效后，其他服务发起的请求将被拒绝，真正实现零信任通信。
