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

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

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 -

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

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

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%

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

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

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

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

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

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 从公开仓库中收录这些内容。

举报或申请下架