Skill

Implement Linkerd Service Mesh Patterns

Production Linkerd patterns - mTLS, ServiceProfiles, canary traffic splits, retries, and multi-cluster mesh setup.

Works with linkerdkubernetesgithub

91
Spark score
out of 100
Updated 17 days ago
Version 14.1.0

Add to Favorites

Why it matters

Streamline your Kubernetes deployments and enhance service reliability by implementing advanced Linkerd service mesh patterns. This asset provides guidance and templates for setting up and managing a secure, efficient service mesh.

Outcomes

What it gets done

01

Configure automatic mTLS for secure communication.

02

Implement traffic splitting for canary deployments and A/B testing.

03

Set up service profiles for per-route metrics, retries, and timeouts.

04

Establish multi-cluster service mesh connectivity.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-linkerd-patterns | bash

Overview

Linkerd Patterns

Production Linkerd service mesh patterns: installation, automatic mTLS, ServiceProfile retries/timeouts, TrafficSplit canary deployments, ServerAuthorization policy, HTTPRoute, and multi-cluster setup. Use when setting up a Linkerd service mesh, configuring mTLS, canary traffic splits, retry/timeout policy, or multi-cluster mesh.

What it does

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.

When to use - and when NOT to

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.

Inputs and outputs

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).

Integrations

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.

Who it's for

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.

Source README

Linkerd Patterns

Production patterns for Linkerd service mesh - the lightweight, security-first service mesh for Kubernetes.

Do not use this skill when

  • The task is unrelated to linkerd patterns
  • You need a different domain or tool outside this scope

Instructions

  • Clarify goals, constraints, and required inputs.
  • Apply relevant best practices and validate outcomes.
  • Provide actionable steps and verification.
  • If detailed examples are required, open resources/implementation-playbook.md.

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
  • Multi-cluster service mesh

Core Concepts

1. Linkerd Architecture

┌─────────────────────────────────────────────┐
│                Control Plane                 │
│  ┌─────────┐ ┌──────────┐ ┌──────────────┐ │
│  │ destiny │ │ identity │ │ proxy-inject │ │
│  └─────────┘ └──────────┘ └──────────────┘ │
└─────────────────────────────────────────────┘
                      │
┌─────────────────────────────────────────────┐
│                 Data Plane                   │
│  ┌─────┐    ┌─────┐    ┌─────┐             │
│  │proxy│────│proxy│────│proxy│             │
│  └─────┘    └─────┘    └─────┘             │
│     │           │           │               │
│  ┌──┴──┐    ┌──┴──┐    ┌──┴──┐            │
│  │ app │    │ app │    │ app │            │
│  └─────┘    └─────┘    └─────┘            │
└─────────────────────────────────────────────┘

2. Key Resources

Resource Purpose
ServiceProfile Per-route metrics, retries, timeouts
TrafficSplit Canary deployments, A/B testing
Server Define server-side policies
ServerAuthorization Access control policies

Templates

Template 1: Mesh Installation

### Install CLI
brew install linkerd

### Alternative: download the official installer, inspect it, then execute it
tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install -o "$tmpdir/linkerd-install.sh"
cat "$tmpdir/linkerd-install.sh"  # review the full installer before executing
sh "$tmpdir/linkerd-install.sh"

### Validate cluster
linkerd check --pre

### Install CRDs
linkerd install --crds | kubectl apply -f -

### Install control plane
linkerd install | kubectl apply -f -

### Verify installation
linkerd check

### Install viz extension (optional)
linkerd viz install | kubectl apply -f -

Template 2: Inject Namespace

### Automatic injection for namespace
apiVersion: v1
kind: Namespace
metadata:
  name: my-app
  annotations:
    linkerd.io/inject: enabled
---
### Or inject specific deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  annotations:
    linkerd.io/inject: enabled
spec:
  template:
    metadata:
      annotations:
        linkerd.io/inject: enabled

Template 3: Service Profile with Retries

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: my-service.my-namespace.svc.cluster.local
  namespace: my-namespace
spec:
  routes:
    - name: GET /api/users
      condition:
        method: GET
        pathRegex: /api/users
      responseClasses:
        - condition:
            status:
              min: 500
              max: 599
          isFailure: true
      isRetryable: true
    - name: POST /api/users
      condition:
        method: POST
        pathRegex: /api/users
      # POST not retryable by default
      isRetryable: false
    - name: GET /api/users/{id}
      condition:
        method: GET
        pathRegex: /api/users/[^/]+
      timeout: 5s
      isRetryable: true
  retryBudget:
    retryRatio: 0.2
    minRetriesPerSecond: 10
    ttl: 10s

Template 4: Traffic Split (Canary)

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%

Template 5: Server Authorization Policy

### Define the server
apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
  name: my-service-http
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      app: my-service
  port: http
  proxyProtocol: HTTP/1
---
### Allow traffic from specific clients
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  name: allow-frontend
  namespace: my-namespace
spec:
  server:
    name: my-service-http
  client:
    meshTLS:
      serviceAccounts:
        - name: frontend
          namespace: my-namespace
---
### Allow unauthenticated traffic (e.g., from ingress)
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  name: allow-ingress
  namespace: my-namespace
spec:
  server:
    name: my-service-http
  client:
    unauthenticated: true
    networks:
      - cidr: 10.0.0.0/8

Template 6: HTTPRoute for Advanced Routing

apiVersion: policy.linkerd.io/v1beta2
kind: HTTPRoute
metadata:
  name: my-route
  namespace: my-namespace
spec:
  parentRefs:
    - name: my-service
      kind: Service
      group: core
      port: 8080
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v2
        - headers:
            - name: x-api-version
              value: v2
      backendRefs:
        - name: my-service-v2
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: my-service-v1
          port: 8080

Template 7: Multi-cluster Setup

### On each cluster, install with cluster credentials
linkerd multicluster install | kubectl apply -f -

### Link clusters
linkerd multicluster link --cluster-name west \
  --api-server-address https://west.example.com:6443 \
  | kubectl apply -f -

### Export a service to other clusters
kubectl label svc/my-service mirror.linkerd.io/exported=true

### Verify cross-cluster connectivity
linkerd multicluster check
linkerd multicluster gateways

Monitoring Commands

### Live traffic view
linkerd viz top deploy/my-app

### Per-route metrics
linkerd viz routes deploy/my-app

### Check proxy status
linkerd viz stat deploy -n my-namespace

### View service dependencies
linkerd viz edges deploy -n my-namespace

### Dashboard
linkerd viz dashboard

Debugging

### Check injection status
linkerd check --proxy -n my-namespace

### View proxy logs
kubectl logs deploy/my-app -c linkerd-proxy

### Debug identity/TLS
linkerd identity -n my-namespace

### Tap traffic (live)
linkerd viz tap deploy/my-app --to deploy/my-backend

Best Practices

Do's

  • Enable mTLS everywhere - It's automatic with Linkerd
  • Use ServiceProfiles - Get per-route metrics and retries
  • Set retry budgets - Prevent retry storms
  • Monitor golden metrics - Success rate, latency, throughput

Don'ts

  • Don't skip check - Always run linkerd check after changes
  • Don't over-configure - Linkerd defaults are sensible
  • Don't ignore ServiceProfiles - They unlock advanced features
  • Don't forget timeouts - Set appropriate values per route

Resources

Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.