linkerd-patterns

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

31,392 stars
Complexity: medium

About this skill

This skill empowers AI agents to guide users through the implementation of robust, production-grade patterns for Linkerd, the lightweight, security-first service mesh for Kubernetes. It provides structured instructions, best practices, and actionable steps to configure, secure, and optimize Linkerd deployments, ensuring high availability, advanced traffic management, and comprehensive observability. The skill can clarify goals, constraints, and required inputs, and generate detailed implementation playbooks. It is designed to assist with practical setup and verification, potentially involving system interactions via `curl | bash` operations as indicated by its security allowlist.

Best use case

Implementing, configuring, or troubleshooting Linkerd service mesh deployments, especially when needing to apply established production patterns, best practices, or generate specific configuration steps for Kubernetes.

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

Users will receive clear, actionable instructions and validated configurations for Linkerd, leading to a properly implemented and optimized service mesh according to production best practices. This includes practical steps for setup, management, and verification, potentially including `curl | bash` commands for execution.

Practical example

Example input

{"query": "Help me implement mTLS and traffic splitting for a new service named 'my-app' in namespace 'production' using Linkerd production patterns.", "context": "I'm deploying a new microservice and want to ensure secure communication and gradual rollout using Linkerd. Assume two versions of the service, 'my-app-v1' and 'my-app-v2'."}

Example output

{"response": "To implement mTLS and traffic splitting for your 'my-app' service in the 'production' namespace using Linkerd production patterns, here are the actionable steps:\n\n**1. Ensure mTLS is enforced:**\n   Linkerd automatically enforces mTLS for meshed pods. Verify your 'my-app' pods are injected with Linkerd proxy. If not, inject them:\n   ```bash\n   kubectl get deploy my-app -n production -o yaml | linkerd inject - | kubectl apply -f -\n   ```\n   To verify mTLS status for your pods:\n   ```bash\n   linkerd -n production check --proxy my-app\n   ```\n\n**2. Configure Traffic Split for Gradual Rollout:**\n   First, define a `ServiceProfile` for your `my-app` service if one doesn't exist. This helps Linkerd understand the service's API:\n   ```yaml\n   apiVersion: linkerd.io/v1alpha2\n   kind: ServiceProfile\n   metadata:\n     name: my-app.production.svc.cluster.local\n     namespace: production\n   spec:\n     routes:\n     - name: \"/\"\n       condition:\n         method: GET\n         pathRegex: /.*\n   ```\n   Apply this ServiceProfile:\n   ```bash\n   kubectl apply -f service-profile.yaml\n   ```\n\n   Now, define a `TrafficSplit` resource to direct traffic between your service versions (e.g., 90% to `my-app-v1` and 10% to `my-app-v2`):\n   ```yaml\n   apiVersion: split.smi-spec.io/v1alpha2\n   kind: TrafficSplit\n   metadata:\n     name: my-app-split\n     namespace: production\n   spec:\n     service: my-app\n     backends:\n     - service: my-app-v1\n       weight: 900 # Represents 90%\n     - service: my-app-v2\n       weight: 100 # Represents 10%\n   ```\n   Apply this TrafficSplit:\n   ```bash\n   kubectl apply -f traffic-split.yaml\n   ```\n\n**3. Verification:**\n   - Check the status of your `TrafficSplit`:\n     ```bash\n     kubectl get trafficsplit my-app-split -n production -o yaml\n     ```\n   - Observe traffic distribution using Linkerd's built-in dashboards (e.g., Grafana) or CLI:\n     ```bash\n     linkerd -n production stat deployments\n     ```\n\n**Further Steps:**\nIf you need to iterate on these patterns or require deeper examples, you can request 'show me the implementation playbook' to access `resources/implementation-playbook.md`."}

When to use this skill

  • Designing or deploying Linkerd in a production Kubernetes cluster.
  • Seeking best practices for traffic management, security, and observability within Linkerd.
  • Needing actionable, step-by-step guidance for Linkerd configuration.
  • Troubleshooting existing Linkerd installations by comparing against known patterns.

When not to use this skill

  • The task is unrelated to Linkerd patterns.
  • You need a different domain or tool outside this scope (e.g., configuring Istio or another service mesh).
  • The environment is not Kubernetes or does not utilize Linkerd.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/linkerd-patterns/SKILL.md --create-dirs "https://raw.githubusercontent.com/sickn33/antigravity-awesome-skills/main/plugins/antigravity-awesome-skills-claude/skills/linkerd-patterns/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/linkerd-patterns/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How linkerd-patterns Compares

Feature / Agentlinkerd-patternsStandard Approach
Platform SupportClaudeLimited / Varies
Context Awareness High Baseline
Installation ComplexitymediumN/A

Frequently Asked Questions

What does this skill do?

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

Which AI agents support this skill?

This skill is designed for Claude.

How difficult is it to install?

The installation complexity is rated as medium. You can find the installation instructions above.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

Related Guides

SKILL.md Source

<!-- security-allowlist: curl-pipe-bash -->

# 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

```bash
# 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

```yaml
# 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

```yaml
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)

```yaml
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

```yaml
# 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

```yaml
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

```bash
# 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

```bash
# 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

```bash
# 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

- [Linkerd Documentation](https://linkerd.io/2.14/overview/)
- [Service Profiles](https://linkerd.io/2.14/features/service-profiles/)
- [Authorization Policy](https://linkerd.io/2.14/features/server-policy/)

Related Skills

k8s-manifest-generator

31392
from sickn33/antigravity-awesome-skills

Step-by-step guidance for creating production-ready Kubernetes manifests including Deployments, Services, ConfigMaps, Secrets, and PersistentVolumeClaims.

DevOps ToolsClaude

deployment-validation-config-validate

31392
from sickn33/antigravity-awesome-skills

You are a configuration management expert specializing in validating, testing, and ensuring the correctness of application configurations. Create comprehensive validation schemas, implement configurat

DevOps ToolsClaude

bazel-build-optimization

31392
from sickn33/antigravity-awesome-skills

Optimize Bazel builds for large-scale monorepos. Use when configuring Bazel, implementing remote execution, or optimizing build performance for enterprise codebases.

DevOps ToolsClaude

nextjs-app-router-patterns

31392
from sickn33/antigravity-awesome-skills

Comprehensive patterns for Next.js 14+ App Router architecture, Server Components, and modern full-stack React development.

Web FrameworksClaude

n8n-workflow-patterns

31392
from sickn33/antigravity-awesome-skills

Proven architectural patterns for building n8n workflows.

Workflow AutomationClaude

memory-safety-patterns

31392
from sickn33/antigravity-awesome-skills

Cross-language patterns for memory-safe programming including RAII, ownership, smart pointers, and resource management.

Software DevelopmentClaude

hig-patterns

31392
from sickn33/antigravity-awesome-skills

Apple Human Interface Guidelines interaction and UX patterns.

User Interface DesignClaude

dotnet-backend-patterns

31392
from sickn33/antigravity-awesome-skills

Master C#/.NET patterns for building production-grade APIs, MCP servers, and enterprise backends with modern best practices (2024/2025).

Software DevelopmentClaude

ddd-tactical-patterns

31392
from sickn33/antigravity-awesome-skills

Apply DDD tactical patterns in code using entities, value objects, aggregates, repositories, and domain events with explicit invariants.

Software DevelopmentClaude

cdk-patterns

31392
from sickn33/antigravity-awesome-skills

Common AWS CDK patterns and constructs for building cloud infrastructure with TypeScript, Python, or Java. Use when designing reusable CDK stacks and L3 constructs.

Code GenerationClaude

cc-skill-frontend-patterns

31392
from sickn33/antigravity-awesome-skills

Frontend development patterns for React, Next.js, state management, performance optimization, and UI best practices.

Code GenerationClaude

cc-skill-backend-patterns

31392
from sickn33/antigravity-awesome-skills

Backend architecture patterns, API design, database optimization, and server-side best practices for Node.js, Express, and Next.js API routes.

Software DevelopmentClaude