Linkerd Patterns

作者 wshobson46891e7e60da無授權條款收錄於 2026年10月8日更新於 2026年10月8日

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.

僅含說明DevOps & Cloud

AI 產生的概覽

提供 Kubernetes 上 Linkerd 服務網格的模式，涵蓋安裝、流量政策、mTLS 與多叢集設定。

功能: 此技能提供在 Kubernetes 上部署與維運 Linkerd 服務網格的參考模式與 YAML 範本。內容涵蓋網格安裝、命名空間與部署注入、含重試與逾時的 ServiceProfile、TrafficSplit 金絲雀路由、Server 與 ServerAuthorization 政策、HTTPRoute 路由以及多叢集連結。此外也包含監控與除錯指令以及最佳實務建議。
適用情境: 適用於設定 Linkerd、配置流量政策，或以最小額外負擔實作零信任網路的情境。也適用於金絲雀部署、依路由的指標、重試與逾時，以及多叢集服務網格相關工作。
執行需求: 需要 Kubernetes 叢集與 Linkerd CLI，並使用 kubectl 套用資訊清單。安裝 CLI 與取得 Linkerd 元件需要網路存取。此技能未附帶指令碼，僅包含指示與 YAML 範本。

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 │            ││  └─────┘    └─────┘    └─────┘            │└─────────────────────────────────────────────┘

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

2. Key Resources

Templates

Template 1: Mesh Installation

Use a CLI version compatible with the target cluster. The example uses Homebrew; for other systems, follow the official installation guide.

bash

# Install the CLI with Homebrewbrew install linkerdlinkerd version
# Validate clusterlinkerd check --pre
# Install CRDslinkerd install --crds | kubectl apply -f -
# Install control planelinkerd install | kubectl apply -f -
# Verify installationlinkerd check
# Install viz extension (optional)linkerd viz install | kubectl apply -f -

# Install the CLI with Homebrewbrew install linkerdlinkerd version
# Validate clusterlinkerd check --pre
# Install CRDslinkerd install --crds | kubectl apply -f -
# Install control planelinkerd install | kubectl apply -f -
# Verify installationlinkerd check
# Install viz extension (optional)linkerd viz install | kubectl apply -f -

Template 2: Inject Namespace

yaml

# Automatic injection for namespaceapiVersion: v1kind: Namespacemetadata:  name: my-app  annotations:    linkerd.io/inject: enabled---# Or inject specific deploymentapiVersion: apps/v1kind: Deploymentmetadata:  name: my-app  annotations:    linkerd.io/inject: enabledspec:  template:    metadata:      annotations:        linkerd.io/inject: enabled

# Automatic injection for namespaceapiVersion: v1kind: Namespacemetadata:  name: my-app  annotations:    linkerd.io/inject: enabled---# Or inject specific deploymentapiVersion: apps/v1kind: Deploymentmetadata:  name: my-app  annotations:    linkerd.io/inject: enabledspec:  template:    metadata:      annotations:        linkerd.io/inject: enabled

Template 3: Service Profile with Retries

yaml

apiVersion: linkerd.io/v1alpha2kind: ServiceProfilemetadata:  name: my-service.my-namespace.svc.cluster.local  namespace: my-namespacespec:  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

apiVersion: linkerd.io/v1alpha2kind: ServiceProfilemetadata:  name: my-service.my-namespace.svc.cluster.local  namespace: my-namespacespec:  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/v1alpha1kind: TrafficSplitmetadata:  name: my-service-canary  namespace: my-namespacespec:  service: my-service  backends:    - service: my-service-stable      weight: 900m # 90%    - service: my-service-canary      weight: 100m # 10%

apiVersion: split.smi-spec.io/v1alpha1kind: TrafficSplitmetadata:  name: my-service-canary  namespace: my-namespacespec:  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 serverapiVersion: policy.linkerd.io/v1beta1kind: Servermetadata:  name: my-service-http  namespace: my-namespacespec:  podSelector:    matchLabels:      app: my-service  port: http  proxyProtocol: HTTP/1---# Allow traffic from specific clientsapiVersion: policy.linkerd.io/v1beta1kind: ServerAuthorizationmetadata:  name: allow-frontend  namespace: my-namespacespec:  server:    name: my-service-http  client:    meshTLS:      serviceAccounts:        - name: frontend          namespace: my-namespace---# Allow unauthenticated traffic (e.g., from ingress)apiVersion: policy.linkerd.io/v1beta1kind: ServerAuthorizationmetadata:  name: allow-ingress  namespace: my-namespacespec:  server:    name: my-service-http  client:    unauthenticated: true    networks:      - cidr: 10.0.0.0/8

# Define the serverapiVersion: policy.linkerd.io/v1beta1kind: Servermetadata:  name: my-service-http  namespace: my-namespacespec:  podSelector:    matchLabels:      app: my-service  port: http  proxyProtocol: HTTP/1---# Allow traffic from specific clientsapiVersion: policy.linkerd.io/v1beta1kind: ServerAuthorizationmetadata:  name: allow-frontend  namespace: my-namespacespec:  server:    name: my-service-http  client:    meshTLS:      serviceAccounts:        - name: frontend          namespace: my-namespace---# Allow unauthenticated traffic (e.g., from ingress)apiVersion: policy.linkerd.io/v1beta1kind: ServerAuthorizationmetadata:  name: allow-ingress  namespace: my-namespacespec:  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/v1beta2kind: HTTPRoutemetadata:  name: my-route  namespace: my-namespacespec:  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

apiVersion: policy.linkerd.io/v1beta2kind: HTTPRoutemetadata:  name: my-route  namespace: my-namespacespec:  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 credentialslinkerd multicluster install | kubectl apply -f -
# Link clusterslinkerd multicluster link --cluster-name west \  --api-server-address https://west.example.com:6443 \  | kubectl apply -f -
# Export a service to other clusterskubectl label svc/my-service mirror.linkerd.io/exported=true
# Verify cross-cluster connectivitylinkerd multicluster checklinkerd multicluster gateways

# On each cluster, install with cluster credentialslinkerd multicluster install | kubectl apply -f -
# Link clusterslinkerd multicluster link --cluster-name west \  --api-server-address https://west.example.com:6443 \  | kubectl apply -f -
# Export a service to other clusterskubectl label svc/my-service mirror.linkerd.io/exported=true
# Verify cross-cluster connectivitylinkerd multicluster checklinkerd multicluster gateways

Monitoring Commands

bash

# Live traffic viewlinkerd viz top deploy/my-app
# Per-route metricslinkerd viz routes deploy/my-app
# Check proxy statuslinkerd viz stat deploy -n my-namespace
# View service dependencieslinkerd viz edges deploy -n my-namespace
# Dashboardlinkerd viz dashboard

# Live traffic viewlinkerd viz top deploy/my-app
# Per-route metricslinkerd viz routes deploy/my-app
# Check proxy statuslinkerd viz stat deploy -n my-namespace
# View service dependencieslinkerd viz edges deploy -n my-namespace
# Dashboardlinkerd viz dashboard

Debugging

bash

# Check injection statuslinkerd check --proxy -n my-namespace
# View proxy logskubectl logs deploy/my-app -c linkerd-proxy
# Debug identity/TLSlinkerd identity -n my-namespace
# Tap traffic (live)linkerd viz tap deploy/my-app --to deploy/my-backend

# Check injection statuslinkerd check --proxy -n my-namespace
# View proxy logskubectl logs deploy/my-app -c linkerd-proxy
# Debug identity/TLSlinkerd 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

來源與署名

來源：wshobson/agents位於plugins/cloud-infrastructure/skills/linkerd-patterns提交46891e7

授權條款：無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架

Linkerd Patterns

Linkerd Patterns

When to Use This Skill

Core Concepts

1. Linkerd Architecture

2. Key Resources

Templates

Template 1: Mesh Installation

Template 2: Inject Namespace

Template 3: Service Profile with Retries

Template 4: Traffic Split (Canary)

Template 5: Server Authorization Policy

Template 6: HTTPRoute for Advanced Routing

Template 7: Multi-cluster Setup

Monitoring Commands

Debugging

Best Practices

Do's

Don'ts

來源與署名

更多來自 wshobson/agents 的技能

Uv Package Manager

Web Component Design

Python Type Safety

Visual Design Foundations

Responsive Design

Python Resource Management

更多DevOps & Cloud技能

M5 Onboard

Runbook

Incident Response

Deploy Checklist

Spanner Basics

Secops Cases

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