Implement Linkerd Service Mesh Patterns

This skill covers production patterns for Linkerd, the lightweight, security-first service mesh for Kubernetes. It describes the control-plane/data-plane architecture (control plane components destiny, identity, proxy-inject; data plane sidecar proxies alongside each app container) and four key resources - ServiceProfile (per-route metrics, retries, timeouts), TrafficSplit (canary deployments, A/B testing), Server (server-side policy definitions), and ServerAuthorization (access-control policies). It provides seven templates: mesh installation (linkerd check --pre, installing CRDs and the control plane, verifying with linkerd check, the optional viz extension), namespace or deployment auto-injection via the linkerd.io/inject: enabled annotation, a ServiceProfile defining per-route retryability and a 5s timeout with a retry budget (retryRatio: 0.2, minRetriesPerSecond: 10, ttl: 10s), a TrafficSplit canary weighting 90% to stable and 10% to canary, a Server plus ServerAuthorization pair allowing mTLS-authenticated traffic from a named service account and separately allowing unauthenticated traffic from a CIDR range (e.g. an ingress), an HTTPRoute matching path prefix or a header for advanced version-based routing, and a multi-cluster setup linking clusters by name and API server address, exporting a service via the mirror.linkerd.io/exported=true label, and verifying cross-cluster connectivity. It lists monitoring commands (linkerd viz top, routes, stat, edges, dashboard) and debugging commands (linkerd check --proxy, proxy container logs, linkerd identity, linkerd viz tap), plus a Do's/Don'ts list: enable mTLS everywhere (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) - versus skipping linkerd check after changes, over-configuring past Linkerd's sensible defaults, ignoring ServiceProfiles, or forgetting per-route timeouts.

Use it for 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 multi-cluster service mesh. It does not apply outside Linkerd patterns - a different domain or tool is out of scope.

Inputs: the Kubernetes cluster and namespaces to mesh, the desired per-route retry/timeout policy, and any canary weighting or cross-cluster linking requirements. Outputs: an installed Linkerd control plane, injected namespaces/deployments, ServiceProfile/TrafficSplit/Server/ServerAuthorization/HTTPRoute manifests, and, for multi-cluster, linked clusters with exported services.

Linkerd's control plane and CLI (linkerd, linkerd viz, linkerd multicluster), the SMI split.smi-spec.io TrafficSplit API, policy.linkerd.io Server/ServerAuthorization/HTTPRoute resources, and Kubernetes namespace/deployment annotations for sidecar injection.

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%

Platform engineers running Linkerd on Kubernetes who need correct ServiceProfile retry/timeout configuration, canary TrafficSplits, authorization policy, and multi-cluster setup rather than trial-and-error YAML.