implementing-service-mesh

服务网格实现

目的

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

使用时机

在以下情况下调用此技能：

• “设置带 mTLS 的服务网格”
• “配置 Istio 流量路由”
• “实施金丝雀部署”
• “保护微服务通信”
• “为服务添加授权策略”
• “在不同版本之间拆分流量”
• “设置多集群服务网格”
• “配置 ambient 模式与 sidecar 模式”
• “设置熔断器配置”
• “启用分布式追踪”

服务网格选择

根据需求和限制进行选择。

Istio Ambient（大多数情况下推荐）：

• 使用 mTLS 时延迟开销为 8%（sidecar 模式为 166%）
• 企业级功能、多云支持、高级 L7 路由
• 无 sidecar 的 L4（ztunnel）+ 可选 L7（waypoint）

Linkerd（优先考虑简洁性）：

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

Cilium（原生 eBPF）：

• 延迟开销为 99%，在内核层强制执行
• 高级网络功能，设计上无需 sidecar
• 最适合 eBPF 基础设施，面向未来

有关详细的对比矩阵和架构权衡，请参阅 references/decision-tree.md。

核心概念

数据平面架构

Sidecar： 每个 Pod 配置一个代理，可精细控制 L7，开销较高
无 sidecar： 使用共享节点代理（Istio Ambient）或 eBPF（Cilium），开销较低

Istio Ambient 组件：

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

流量管理

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

安全模型

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

Istio 配置

Istio 使用自定义资源定义来管理流量和安全性。

VirtualService（路由）

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（流量策略）

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）

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

AuthorizationPolicy（访问控制）

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 配置

Linkerd 注重简洁性，并提供自动 mTLS。

HTTPRoute（流量拆分）

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（重试/超时）

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

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 配置

Cilium 使用 eBPF 在内核层强制执行策略。

CiliumNetworkPolicy（L3/L4/L7）

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 的出站流量控制

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。

安全实施

零信任架构

1. 启用严格 mTLS（加密所有流量）
2. 授权策略默认拒绝
3. 明确配置允许规则（最小权限）
4. 基于身份的访问控制
5. 审计日志记录

示例（Istio）：

# 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: {}

证书管理

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

有关 JWT 身份验证和外部授权（OPA），请参阅 references/security-patterns.md。

渐进式交付

金丝雀部署

通过监控逐步转移流量。

阶段：

1. 部署 v2，流量占比为 0%
2. 将 10% 的流量路由到 v2，并监控指标
3. 逐步增加：25% → 50% → 75% → 100%
4. 清理 v1 部署

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

蓝绿部署

即时切换，并可快速回滚。

流程：

1. 在蓝环境旁部署绿环境
2. 通过请求头路由测试绿环境
3. 即时切换到绿环境
4. 如有需要，回滚到蓝环境

自动回滚（Flagger）

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。

多集群网格

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

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

Istio 多主模式：

# 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 多集群：

# Link clusters
linkerd multicluster link --cluster-name cluster2 | \
  kubectl apply -f -

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

如需了解完整设置和跨集群模式，请参阅 references/multi-cluster.md。

安装

Istio Ambient Mode

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

Linkerd

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

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

故障排查

mTLS 问题

# 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

流量路由问题

# Istio: Analyze config
istioctl analyze -n production

# Linkerd: Tap traffic
linkerd tap deployment/backend -n production

# Cilium: Observe flows
hubble observe --namespace production

如需完整的调试指南和解决方案，请参阅 references/troubleshooting.md。

与其他技能集成

**kubernetes-operations：**集群设置、命名空间、RBAC **security-hardening：**容器安全、密钥管理 **infrastructure-as-code：**用于网格部署的 Terraform/Helm **building-ci-pipelines：**自动化金丝雀发布、集成测试 **performance-engineering：**延迟基准测试、优化

参考文件

• references/decision-tree.md - 服务网格的选择与比较
• references/istio-patterns.md - Istio 配置示例
• references/linkerd-patterns.md - Linkerd 模式和最佳实践
• references/cilium-patterns.md - Cilium eBPF 策略和 mTLS
• references/security-patterns.md - 零信任和授权
• references/progressive-delivery.md - 金丝雀、蓝绿、A/B 测试
• references/multi-cluster.md - 多集群设置和联邦
• references/troubleshooting.md - 常见问题和调试