Linkerd可在5分钟内完成部署，前提是严格按顺序执行：先装CLI并运行linkerd check--pre验证集群就绪（含API连通性、RBAC、CRD及EndpointSlice支持），再执行linkerd install与linkerd viz install，最后用linkerd check确认控制平面健康，否则90%失败源于跳过预检或注入时机错误。
Linkerd 能在 5 分钟内完成部署，但前提是集群满足基本条件且命令执行顺序不能错——跳过 linkerd check --pre 或忽略命名空间注解时机，90% 的失败都发生在这两步。
安装 Linkerd CLI 并验证集群就绪性
CLI 是唯一需要本地安装的组件，它不依赖集群状态，但后续所有操作都靠它驱动。别用包管理器混装多个版本，linkerd version 输出里出现 Server version: unavailable 是正常现象，说明控制平面还没装，不是错误。
真正关键的是预检：linkerd check --pre。它会检查 API server 连通性、RBAC 权限、CRD 支持（Kubernetes ≥1.21）、以及是否启用了 EndpointSlice 特性。任一检查失败，linkerd install 很可能卡在 linkerd-controller Pod 的 CrashLoopBackOff 状态。
- 常见报错：
unable to retrieve the complete list of server APIs→ kubectl 配置未指向目标集群 - GKE 私有集群需额外开通 master authorized networks
- Minikube 用户要确保启用
--extra-config=apiserver.feature-gates=EndpointSlice=true
部署控制平面并启用 Viz 扩展
linkerd install | kubectl apply -f - 这条命令本质是生成 YAML 清单并提交给 Kubernetes，它不等待资源就绪就返回。所以紧接着必须运行 linkerd check，而不是只看 kubectl get pods -n linkerd 是否全 Running——有些组件（如 linkerd-destination）可能 Running 但内部健康探针失败，linkerd check 才能暴露。
Viz 扩展（linkerd viz install）不是可选插件，它是查看黄金指标（success rate / p99 latency / RPS）的唯一入口。它依赖控制平面已就绪，所以必须在 linkerd check 通过后执行，否则 linkerd viz dashboard 会报 connection refused。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 不要手动修改
linkerd-viz命名空间的资源限制，它的默认配置已针对低开销优化 - 若集群禁用
ServiceAccount自动挂载，需为linkerd-viznamespace 显式添加automountServiceAccountToken: true
向应用注入数据平面（Sidecar）
注入不是“一次打补丁”，而是决定流量是否经过代理的开关。手动注入（linkerd inject）适合 CI/CD 流水线中对特定 Deployment 生效；自动注入（linkerd.io/inject=enabled 注解 namespace）适合长期网格化运维，但要注意：注解仅对新创建的 Pod 生效。
已有 Pod 不会因 namespace 注解而自动重载 sidecar。必须触发滚动更新，例如：kubectl rollout restart deploy/music-app。否则 kubectl get pods 看起来有两个容器，实际只有 init 容器启动了 proxy，主容器仍直连。
- 注入后检查：
kubectl get pod -o wide中的READY列应为2/2，不是1/2 - 如果看到
linkerd-proxy容器处于Init:0/1，大概率是linkerd-identity组件未就绪或证书签发超时 - 避免在
linkerd或linkerd-viz命名空间上开启自动注入——会导致控制平面自身被代理，引发循环依赖
确认 mTLS 和指标是否真实生效
Linkerd 默认启用 mTLS，但不会主动告诉你是否成功。验证方式很直接：linkerd stat deploy -n default。如果显示 MTLS 列为 disabled，说明至少有一端未注入，或者服务间通信走的是 ClusterIP 以外的路径（比如 NodePort 直连）。
黄金指标（success rate / latency）也不是“装完就出”。它只对 HTTP/gRPC 流量自动统计，纯 TCP 流量（如 MySQL、Redis）不会产生这些指标，linkerd stat 里对应服务会显示 -。此时需手动定义 ServiceProfile 或接受默认的 TCP 层统计（仅连接数和错误数）。
-
linkerd tap deploy/music-app-v1 -n default可实时捕获请求流，确认 proxy 是否真正在转发 - 如果
linkerd viz dashboard中某服务长期无数据，先检查该服务是否使用了非标准端口（如 8081），Linkerd 默认只抓取标注为http或grpc的端口
最常被跳过的细节：Viz 扩展的 metrics-api 服务默认只监听 ClusterIP，若想从集群外访问仪表盘，得改用 port-forward 或单独暴露 Ingress——直接改 Service 类型为 LoadBalancer 可能导致 TLS 证书不匹配。
