PluginBench
Skill
Review
Audit score 70

linkerd-patterns

wshobson/agents

Lightweight, security-first service mesh patterns for Kubernetes with automatic mTLS and traffic control.

What is linkerd-patterns?

Implement Linkerd service mesh for Kubernetes deployments with automatic mutual TLS, traffic splitting, and per-route metrics. Use this skill when setting up a lightweight service mesh, configuring canary deployments, implementing zero-trust networking, or managing multi-cluster connectivity.

  • Install and configure Linkerd control plane and data plane proxies
  • Implement automatic mutual TLS encryption between services
  • Configure ServiceProfiles for per-route metrics, retries, and timeouts
  • Set up traffic splits for canary deployments and A/B testing
  • Define Server and ServerAuthorization policies for zero-trust access control
  • Enable multi-cluster service mesh with cross-cluster service discovery

How to install linkerd-patterns

npx skills add https://github.com/wshobson/agents --skill linkerd-patterns
Prerequisites
  • Kubernetes cluster (1.21+)
  • kubectl configured to access your cluster
  • Linkerd CLI installed via curl or package manager
Claude Code
Cursor
Windsurf
Cline

How to use linkerd-patterns

  1. 1.Install the Linkerd CLI and validate your cluster with linkerd check --pre
  2. 2.Apply CRDs and control plane components using linkerd install commands
  3. 3.Annotate namespaces or deployments with linkerd.io/inject: enabled for automatic proxy injection
  4. 4.Create ServiceProfile resources to define per-route metrics, retries, and timeouts
  5. 5.Configure TrafficSplit resources for canary deployments or A/B testing
  6. 6.Define Server and ServerAuthorization policies to enforce zero-trust access control
  7. 7.Monitor traffic with linkerd viz commands (top, routes, stat, tap) and the dashboard

Use cases

Good for
  • Deploy a lightweight service mesh with minimal resource overhead
  • Implement canary deployments by gradually shifting traffic between service versions
  • Set up automatic mTLS without application code changes
  • Configure per-route retry policies and timeouts for resilience
  • Establish zero-trust networking with fine-grained access policies
Who it's for
  • Platform engineers setting up service mesh infrastructure
  • DevOps teams implementing zero-trust networking
  • SREs managing multi-cluster Kubernetes deployments
  • Developers working with microservices requiring traffic control and observability

linkerd-patterns FAQ

What is the performance overhead of Linkerd?

Linkerd is designed for minimal overhead. The data plane proxies add ~1-2ms latency and use minimal CPU/memory. The control plane is lightweight compared to other service meshes.

Do I need to modify my application code to use Linkerd?

No. Linkerd works transparently by injecting sidecar proxies into your pods. Applications communicate normally; the proxies handle mTLS, metrics, and traffic control.

How does Linkerd handle retries?

ServiceProfiles define which routes are retryable and set retry budgets to prevent retry storms. Retries are configured per-route with conditions for which HTTP status codes trigger retries.

Can I use Linkerd with an existing ingress controller?

Yes. Linkerd works alongside ingress controllers. You can allow unauthenticated traffic from ingress using ServerAuthorization policies with unauthenticated: true.

How do I monitor Linkerd?

Use linkerd viz commands for live traffic views, per-route metrics, and service dependencies. The viz dashboard provides a web UI. Linkerd also exports Prometheus metrics for integration with existing monitoring.

Full instructions (SKILL.md)

Source of truth, from wshobson/agents.


name: linkerd-patterns description: Implement Linkerd service mesh patterns for lightweight, security-focused service mesh deployments. Use when setting up Linkerd, configuring traffic policies, or implementing zero-trust networking with minimal overhead.

Linkerd Patterns

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

When to Use This Skill

  • 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

ResourcePurpose
ServiceProfilePer-route metrics, retries, timeouts
TrafficSplitCanary deployments, A/B testing
ServerDefine server-side policies
ServerAuthorizationAccess control policies

Templates

Template 1: Mesh Installation

# Install CLI
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/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