Linkerd 2.x 不支持裸机 Linux 部署，必须运行在 Kubernetes 上；linkerd install 仅输出 YAML，需管道至 kubectl apply -f - 才部署，自动注入须先注解命名空间再部署应用，linkerd check 失败多因 DNS 或 RBAC 问题。
Linkerd 在 Linux 上不直接作为独立进程运行，它依赖 Kubernetes 环境；所谓“Linux 中安装 Linkerd”，实际是指在 Linux 主机上部署 Kubernetes 集群（如 MicroK8s、k3s 或 Kind），再在其上安装 Linkerd 控制平面和数据平面。跳过 Kubernetes 直接在裸机 Linux 上跑 Linkerd 1.x 的旧模式已不再推荐，且 Linkerd 2.x 官方完全不支持非 Kubernetes 场景。
linkerd install 命令只生成 YAML，不自动部署
执行 linkerd install 只是输出一组 Kubernetes 清单（YAML），不会调用 kubectl apply 自动创建资源。很多人卡在这一步，以为“没反应”就是失败。
- 必须显式管道到
kubectl apply -f -才真正部署：linkerd install | kubectl apply -f - - 若集群未配置默认上下文，需加
-n linkerd指定命名空间，否则资源可能被发到错误 namespace -
linkerd install --ha会启用高可用模式（3 副本 identity、destination 等），但会增加约 300MB 内存占用，小内存 VPS（如 1GB）慎用
linkerd.io/inject=enabled 注解必须作用于命名空间，不是 Deployment
自动注入依赖 Kubernetes 准入控制器（linkerd-proxy-injector），它只监听带 linkerd.io/inject 注解的 namespace 创建事件。对已有 Deployment 补注解无效，也不会触发重部署。
- 正确做法：先注解命名空间，再部署应用
kubectl annotate namespace default linkerd.io/inject=enabled - 已有 Pod 想补注入？必须重建：
kubectl rollout restart deployment -n default - 手动注入更可控：
kubectl get deploy myapp -o yaml | linkerd inject - | kubectl apply -f -—— 这条命令会把linkerd-proxy容器注入到 YAML 中再提交
linkerd check 失败常见于 DNS 和 RBAC，不是 Linkerd 本身问题
linkerd check 报错如 control plane can't communicate with Kubernetes API 或 can't resolve linkerd-identity.linkerd.svc.cluster.local，大概率是底层 Kubernetes 的 DNS（CoreDNS/NodeLocalDNS）未就绪，或 service account 权限不足。
- 先确认
kubectl get pods -A中所有 CoreDNS Pod 是Running状态 - 检查
linkerd-identity的 service account 是否绑定linkerd-identity-readerClusterRole - 在 MicroK8s 环境中，需提前启用
dns和storage插件：microk8s enable dns storage -
linkerd check --proxy专用于验证数据平面，必须等至少一个注入后的 Pod 启动完成再运行
最易被忽略的一点：Linkerd 的 proxy（基于 Rust 的 linkerd2-proxy）默认监听 localhost:4191 的 admin 接口，但该端口不对外暴露 —— 这意味着你无法从宿主机 curl 它做健康检查，也不能靠传统方式抓包调试流量。所有可观测性必须通过 linkerd viz 或 Prometheus 抓取指标，而不是直连 proxy。
