implementing-service-mesh

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Service Mesh Implementation

服务网格实现

Purpose

用途

Configure and deploy service mesh infrastructure for Kubernetes environments. Enable secure service-to-service communication with mutual TLS, implement traffic management policies, configure authorization controls, and set up progressive delivery strategies. Abstracts network complexity while providing observability, security, and resilience for microservices.

为Kubernetes环境配置并部署服务网格基础设施。通过双向TLS（mTLS）实现安全的服务间通信，实施流量管理策略，配置授权控制，并搭建渐进式交付策略。在为微服务提供可观测性、安全性和韧性的同时，抽象网络复杂度。

When to Use

适用场景

Invoke this skill when:

"Set up service mesh with mTLS"
"Configure Istio traffic routing"
"Implement canary deployments"
"Secure microservices communication"
"Add authorization policies to services"
"Traffic splitting between versions"
"Multi-cluster service mesh setup"
"Configure ambient mode vs sidecar"
"Set up circuit breaker configuration"
"Enable distributed tracing"

在以下场景中调用此技能：

"使用mTLS搭建服务网格"
"配置Istio流量路由"
"实现金丝雀部署"
"保障微服务通信安全"
"为服务添加授权策略"
"版本间流量拆分"
"多集群服务网格搭建"
"配置Ambient模式 vs 边车模式"
"设置断路器配置"
"启用分布式追踪"

Service Mesh Selection

服务网格选择

Choose based on requirements and constraints.

Istio Ambient (Recommended for most):

8% latency overhead with mTLS (vs 166% sidecar mode)
Enterprise features, multi-cloud, advanced L7 routing
Sidecar-less L4 (ztunnel) + optional L7 (waypoint)

Linkerd (Simplicity priority):

33% latency overhead (lowest sidecar)
Rust-based micro-proxy, automatic mTLS
Best for small-medium teams, easy adoption

Cilium (eBPF-native):

99% latency overhead, kernel-level enforcement
Advanced networking, sidecar-less by design
Best for eBPF infrastructure, future-proof

For detailed comparison matrix and architecture trade-offs, see

references/decision-tree.md

根据需求和约束条件进行选择。

Istio Ambient（大多数场景推荐）：

开启mTLS时仅8%的延迟开销（边车模式为166%）
企业级特性、多云支持、高级L7路由
无边车的L4（ztunnel）+ 可选L7（waypoint）

Linkerd（优先考虑简洁性）：

33%的延迟开销（边车模式中最低）
基于Rust的微代理，自动启用mTLS
最适合中小团队，易于采用

Cilium（基于eBPF）：

99%的延迟开销，内核级强制执行
高级网络能力，原生无边车设计
最适合eBPF基础设施，具备未来适应性

如需详细对比矩阵和架构权衡分析，请查看

references/decision-tree.md

。

Core Concepts

核心概念

Data Plane Architectures

数据平面架构

Sidecar: Proxy per pod, fine-grained L7 control, higher overhead Sidecar-less: Shared node proxies (Istio Ambient) or eBPF (Cilium), lower overhead

Istio Ambient Components:

ztunnel: Per-node L4 proxy for mTLS
waypoint: Optional per-namespace L7 proxy for HTTP routing

边车模式： 每个Pod对应一个代理，细粒度L7控制，开销较高 无边车模式： 共享节点代理（Istio Ambient）或eBPF（Cilium），开销较低

Istio Ambient组件：

ztunnel：每个节点的L4代理，用于mTLS
waypoint：可选的每个命名空间L7代理，用于HTTP路由

Traffic Management

流量管理

Routing: Path, header, weight-based traffic distribution Resilience: Retries, timeouts, circuit breakers, fault injection Load Balancing: Round robin, least connections, consistent hash

路由： 基于路径、请求头、权重的流量分发 韧性： 重试、超时、断路器、故障注入 负载均衡： 轮询、最少连接数、一致性哈希

Security Model

安全模型

mTLS: Automatic encryption, certificate rotation, zero app changes Modes: STRICT (reject plaintext), PERMISSIVE (accept both) Authorization: Default-deny, identity-based (not IP), L7 policies

mTLS： 自动加密、证书轮换、无需修改应用 模式： STRICT（拒绝明文流量）、PERMISSIVE（同时接受明文和加密流量） 授权： 默认拒绝、基于身份（而非IP）、L7策略

Istio Configuration

Istio配置

Istio uses Custom Resource Definitions for traffic management and security.

Istio使用自定义资源定义（CRD）进行流量管理和安全配置。

VirtualService (Routing)

VirtualService（路由）

yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-canary
spec:
  hosts:
  - backend
  http:
  - route:
    - destination:
        host: backend
        subset: v1
      weight: 90
    - destination:
        host: backend
        subset: v2
      weight: 10

yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-canary
spec:
  hosts:
  - backend
  http:
  - route:
    - destination:
        host: backend
        subset: v1
      weight: 90
    - destination:
        host: backend
        subset: v2
      weight: 10

DestinationRule (Traffic Policy)

DestinationRule（流量策略）

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: backend-circuit-breaker
spec:
  host: backend
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: backend-circuit-breaker
spec:
  host: backend
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s

PeerAuthentication (mTLS)

PeerAuthentication（mTLS）

yaml

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

yaml

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

AuthorizationPolicy (Access Control)

AuthorizationPolicy（访问控制）

yaml

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/production/sa/frontend
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/*"]

For advanced patterns (fault injection, mirroring, gateways), see

references/istio-patterns.md

yaml

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/production/sa/frontend
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/*"]

如需高级模式（故障注入、流量镜像、网关），请查看

references/istio-patterns.md

。

Linkerd Configuration

Linkerd配置

Linkerd emphasizes simplicity with automatic mTLS.

Linkerd以简洁为核心，自动启用mTLS。

HTTPRoute (Traffic Splitting)

HTTPRoute（流量拆分）

yaml

apiVersion: policy.linkerd.io/v1beta2
kind: HTTPRoute
metadata:
  name: backend-canary
spec:
  parentRefs:
  - name: backend
    kind: Service
  rules:
  - backendRefs:
    - name: backend-v1
      port: 8080
      weight: 90
    - name: backend-v2
      port: 8080
      weight: 10

yaml

apiVersion: policy.linkerd.io/v1beta2
kind: HTTPRoute
metadata:
  name: backend-canary
spec:
  parentRefs:
  - name: backend
    kind: Service
  rules:
  - backendRefs:
    - name: backend-v1
      port: 8080
      weight: 90
    - name: backend-v2
      port: 8080
      weight: 10

ServiceProfile (Retries/Timeouts)

ServiceProfile（重试/超时）

yaml

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: backend.production.svc.cluster.local
spec:
  routes:
  - name: GET /api/data
    condition:
      method: GET
      pathRegex: /api/data
    timeout: 3s
    retryBudget:
      retryRatio: 0.2
      minRetriesPerSecond: 10

yaml

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: backend.production.svc.cluster.local
spec:
  routes:
  - name: GET /api/data
    condition:
      method: GET
      pathRegex: /api/data
    timeout: 3s
    retryBudget:
      retryRatio: 0.2
      minRetriesPerSecond: 10

AuthorizationPolicy

yaml

apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
spec:
  targetRef:
    kind: Server
    name: backend-api
  requiredAuthenticationRefs:
  - name: frontend-identity
    kind: MeshTLSAuthentication

For complete patterns and mTLS verification, see

references/linkerd-patterns.md

yaml

apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
spec:
  targetRef:
    kind: Server
    name: backend-api
  requiredAuthenticationRefs:
  - name: frontend-identity
    kind: MeshTLSAuthentication

如需完整模式和mTLS验证，请查看

references/linkerd-patterns.md

。

Cilium Configuration

Cilium配置

Cilium uses eBPF for kernel-level enforcement.

Cilium使用eBPF实现内核级强制执行。

CiliumNetworkPolicy (L3/L4/L7)

CiliumNetworkPolicy（L3/L4/L7）

yaml

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-access
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
      rules:
        http:
        - method: GET
          path: "/api/.*"

yaml

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-access
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
      rules:
        http:
        - method: GET
          path: "/api/.*"

DNS-Based Egress

yaml

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: external-api-access
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
  - toFQDNs:
    - matchName: "api.github.com"
    toPorts:
    - ports:
      - port: "443"

For mTLS with SPIRE and eBPF patterns, see

references/cilium-patterns.md

yaml

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: external-api-access
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
  - toFQDNs:
    - matchName: "api.github.com"
    toPorts:
    - ports:
      - port: "443"

如需基于SPIRE的mTLS和eBPF模式，请查看

references/cilium-patterns.md

。

Security Implementation

安全实现

Zero-Trust Architecture

零信任架构

Enable strict mTLS (encrypt all traffic)
Default-deny authorization policies
Explicit allow rules (least privilege)
Identity-based access control
Audit logging

Example (Istio):

yaml

undefined

启用严格mTLS（加密所有流量）
配置默认拒绝的授权策略
显式允许规则（最小权限原则）
基于身份的访问控制
审计日志

示例（Istio）：

yaml

undefined

Strict mTLS

apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata: name: strict-mtls namespace: production spec: mtls: mode: STRICT

Deny all by default

apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: deny-all namespace: production spec: {}

undefined

apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: deny-all namespace: production spec: {}

undefined

Certificate Management

证书管理

Automatic rotation (24h TTL default)
Zero-downtime updates
External CA integration (cert-manager)
SPIFFE/SPIRE for workload identity

For JWT authentication and external authorization (OPA), see

references/security-patterns.md

自动轮换（默认24小时TTL）
零停机更新
外部CA集成（cert-manager）
SPIFFE/SPIRE用于工作负载身份

如需JWT认证和外部授权（OPA），请查看

references/security-patterns.md

。

Progressive Delivery

渐进式交付

Canary Deployment

金丝雀部署

Gradually shift traffic with monitoring.

Stages:

Deploy v2 with 0% traffic
Route 10% to v2, monitor metrics
Increase: 25% → 50% → 75% → 100%
Cleanup v1 deployment

Monitor: Error rate, latency (P95/P99), throughput

结合监控逐步切换流量。

阶段：

部署v2，分配0%流量
将10%流量路由到v2，监控指标
逐步提升权重：25% → 50% → 75% → 100%
清理v1部署

监控指标： 错误率、延迟（P95/P99）、吞吐量

Blue/Green Deployment

蓝绿部署

Instant cutover with quick rollback.

Process:

Deploy green alongside blue
Test green with header routing
Instant cutover to green
Rollback to blue if needed

即时切换流量，支持快速回滚。

流程：

在蓝环境旁部署绿环境
通过请求头路由测试绿环境
即时切换到绿环境
若出现问题，回滚到蓝环境

Automated Rollback (Flagger)

自动回滚（Flagger）

yaml

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: backend
spec:
  targetRef:
    kind: Deployment
    name: backend
  service:
    port: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99

For A/B testing and detailed patterns, see

references/progressive-delivery.md

yaml

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: backend
spec:
  targetRef:
    kind: Deployment
    name: backend
  service:
    port: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99

如需A/B测试和详细模式，请查看

references/progressive-delivery.md

。

Multi-Cluster Mesh

多集群网格

Extend mesh across Kubernetes clusters.

Use Cases: HA, geo-distribution, compliance, DR

Istio Multi-Primary:

bash

undefined

将网格扩展到多个Kubernetes集群。

适用场景： 高可用、地域分布、合规、灾难恢复

Istio多主模式：

bash

undefined

Install on cluster 1

istioctl install --set values.global.meshID=mesh1
--set values.global.multiCluster.clusterName=cluster1

Exchange secrets for service discovery

istioctl x create-remote-secret --context=cluster2 |
kubectl apply -f - --context=cluster1


**Linkerd Multi-Cluster:**

```bash

istioctl x create-remote-secret --context=cluster2 |
kubectl apply -f - --context=cluster1


**Linkerd多集群：**

```bash

Link clusters

linkerd multicluster link --cluster-name cluster2 |
kubectl apply -f -

Export service

kubectl label svc/backend mirror.linkerd.io/exported=true


For complete setup and cross-cluster patterns, see `references/multi-cluster.md`.

kubectl label svc/backend mirror.linkerd.io/exported=true


如需完整搭建流程和跨集群模式，请查看`references/multi-cluster.md`。

Installation

安装

Istio Ambient Mode

Istio Ambient模式

bash

curl -L https://istio.io/downloadIstio | sh -
istioctl install --set profile=ambient -y
kubectl label namespace production istio.io/dataplane-mode=ambient

bash

curl -L https://istio.io/downloadIstio | sh -
istioctl install --set profile=ambient -y
kubectl label namespace production istio.io/dataplane-mode=ambient

Linkerd

bash

curl -sL https://run.linkerd.io/install-edge | sh
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
kubectl annotate namespace production linkerd.io/inject=enabled

bash

curl -sL https://run.linkerd.io/install-edge | sh
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
kubectl annotate namespace production linkerd.io/inject=enabled

Cilium

bash

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set meshMode=enabled \
  --set authentication.mutual.spire.enabled=true

bash

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set meshMode=enabled \
  --set authentication.mutual.spire.enabled=true

Troubleshooting

故障排查

mTLS Issues

mTLS问题

bash

undefined

bash

undefined

Istio: Check mTLS status

istioctl authn tls-check frontend.production.svc.cluster.local

Linkerd: Check edges

linkerd edges deployment/frontend -n production

Cilium: Check auth

cilium bpf auth list

undefined

cilium bpf auth list

undefined

Traffic Routing Issues

流量路由问题

bash

undefined

bash

undefined

Istio: Analyze config

istioctl analyze -n production

Linkerd: Tap traffic

linkerd tap deployment/backend -n production

Cilium: Observe flows

hubble observe --namespace production


For complete debugging guide and solutions, see `references/troubleshooting.md`.

hubble observe --namespace production


如需完整调试指南和解决方案，请查看`references/troubleshooting.md`。

Integration with Other Skills

—

kubernetes-operations: Cluster setup, namespaces, RBAC security-hardening: Container security, secret management infrastructure-as-code: Terraform/Helm for mesh deployment building-ci-pipelines: Automated canary, integration tests performance-engineering: Latency benchmarking, optimization

—

Reference Files

—

```
references/decision-tree.md
```
- Service mesh selection and comparison
```
references/istio-patterns.md
```
- Istio configuration examples
```
references/linkerd-patterns.md
```
- Linkerd patterns and best practices
```
references/cilium-patterns.md
```
- Cilium eBPF policies and mTLS
```
references/security-patterns.md
```
- Zero-trust and authorization
```
references/progressive-delivery.md
```
- Canary, blue/green, A/B testing
```
references/multi-cluster.md
```
- Multi-cluster setup and federation
```
references/troubleshooting.md
```
- Common issues and debugging

—