Implement Linkerd Service Mesh Patterns

Linkerd Patterns covers production patterns for Linkerd, a lightweight, security-first service mesh for Kubernetes, structured around a control plane (destiny, identity, proxy-inject) and a data plane of per-pod sidecar proxies. Four key resources are named: ServiceProfile for per-route metrics/retries/timeouts, TrafficSplit for canary deployments and A/B testing, Server for defining server-side policies, and ServerAuthorization for access control. Seven templates cover the full workflow: mesh installation (CLI install, downloading and reviewing the installer before executing it, linkerd check --pre, installing CRDs then the control plane, and optionally the viz extension); namespace or per-deployment automatic sidecar injection via the linkerd.io/inject annotation; a ServiceProfile defining per-route retry eligibility, timeouts, and a retry budget (retryRatio, minRetriesPerSecond, ttl); a TrafficSplit for weighted canary traffic:

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: my-service-canary
  namespace: my-namespace
spec:
  service: my-service
  backends:
    - service: my-service-stable
      weight: 900m  # 90%
    - service: my-service-canary
      weight: 100m  # 10%

a Server plus ServerAuthorization pair restricting traffic to specific mTLS service accounts or allowing unauthenticated ingress from a defined CIDR; an HTTPRoute for path- and header-based advanced routing to different backend versions; and a multi-cluster setup linking clusters and exporting services across them via the mirror.linkerd.io/exported label.

Use this skill when setting up a lightweight service mesh, implementing automatic mTLS, configuring traffic splits for canary deployments, setting up service profiles for per-route metrics, implementing retries and timeouts, or building a multi-cluster service mesh.

Given a Linkerd task, the skill outputs the matching YAML resource or CLI command sequence, plus monitoring commands (linkerd viz top/routes/stat/edges/dashboard for live traffic, per-route metrics, proxy status, service dependencies, and the web dashboard) and debugging commands (linkerd check --proxy for injection status, proxy logs via kubectl, linkerd identity for TLS debugging, and linkerd viz tap for live traffic inspection).

Built on Linkerd's control-plane/data-plane architecture and its CRDs (ServiceProfile, TrafficSplit via the SMI spec, Server and ServerAuthorization, HTTPRoute). Stated best practices: enable mTLS everywhere since it's automatic with Linkerd, use ServiceProfiles for per-route metrics and retries, set retry budgets to prevent retry storms, and monitor golden metrics (success rate, latency, throughput) - alongside four don'ts: don't skip linkerd check after changes, don't over-configure since Linkerd's defaults are sensible, don't ignore ServiceProfiles, and don't forget per-route timeouts.

Platform engineers running Linkerd on Kubernetes who need concrete, working YAML for mTLS authorization, canary traffic splits, retry/timeout policy, and multi-cluster setup, plus the monitoring and debugging commands to operate it in production.